3. Frage zum Port-Fprwarding mit C++

Frage zum Port-Fprwarding mit C++

  • C

    Belli schrieb:

    Wo aber soll die herkommen, wenn 'die Adresse' hinter einer Firewall sitzt?

    Die Antwort wird einfach geschickt. Sie ist keine direkte Reaktion auf eine Anfrage, sondern muss natürlich ausgelöst werden. Die Anfrage dient nur dazu, den Router auf eine Antwort einzustellen.

    0
  • B

    Also:

    cooky451 schrieb:

    Ist er doch. Sende ein UDP Paket an eine Adresse und warte auf die Antwort.

    ich sende ein UDP Paket an eine Adresse, und dann

    cooky451 schrieb:

    Die Antwort wird einfach geschickt. Sie ist keine direkte Reaktion auf eine Anfrage, sondern muss natürlich ausgelöst werden.

    das kann doch nur dann funktionieren, wenn das von irgendwem - im Fall von Skype macht das der Skype-Server - gesteuert wird, denn mein Router wird eine 'Antwort' ja nur dann durchlassen, wenn sie von der Adresse kommt, an die ich mein UDP-Paket gesendet habe, und diese Adresse muss erst mal meine IP/Port wissen, und wann der richtige Zeitpunkt gekommen ist, um mir eine 'Antwort' zu senden.

    Ich bleibe also dabei: In diesem Fall braucht man erst mal irgendwo einen Server, auf den die Beteiligten connecten können; dieser kümmert sich dann über die bestehenden Verbindungen zu den beiden darum, dass die nötigen Informationen (IP/Port, Zeitpunkt) zur Verfügung stehen.

    Hier
    http://www.heise.de/security/artikel/Wie-Skype-Co-Firewalls-umgehen-270856.html
    ist ganz gut beschrieben, wie Skype es macht.

    Beachte:
    "Eine wichtige Aufgabe beim Gesprächsaufbau mit Skype übernimmt ein Vermittlungsserver, mit dem beide Kommunikationspartner in ständigem Kontakt stehen."

    Es ist letztendlich keine Lösung, die geeignet ist, dem TE das Port-Forwarding zu ersparen.

    0
  • C

    Belli schrieb:

    Ich bleibe also dabei: In diesem Fall braucht man erst mal irgendwo einen Server, auf den die Beteiligten connecten können; dieser kümmert sich dann über die bestehenden Verbindungen zu den beiden darum, dass die nötigen Informationen (IP/Port, Zeitpunkt) zur Verfügung stehen.

    Angenommen man möchte ein Spiel übers Netz spielen, aber jemand der eigentlich keine Ahnung von Routern hat, bzw. vielleicht nicht einmal Zugriff auf diesen hat, soll hosten, da sein Rechner am schnellsten ist. Dann wäre das die optimale Lösung und man braucht keinen Server dazwischen.

    0
  • B

    cooky451 schrieb:

    Angenommen man möchte ein Spiel übers Netz spielen, aber jemand der eigentlich keine Ahnung von Routern hat, bzw. vielleicht nicht einmal Zugriff auf diesen hat, soll hosten, da sein Rechner am schnellsten ist. Dann wäre das die optimale Lösung und man braucht keinen Server dazwischen.

    Dann skizzier doch mal kurz, wie das gehen soll?
    Der Host wartet auf Anfragen, auf die er Antworten schickt. Okay.
    Da er aber hinter einem Router hängt, bekommt er gar keine Anfragen, was also nun?

    cooky451 schrieb:

    Die Antwort wird einfach geschickt. Sie ist keine direkte Reaktion auf eine Anfrage, sondern muss natürlich ausgelöst werden. Die Anfrage dient nur dazu, den Router auf eine Antwort einzustellen.

    An wen wird die Antwort denn einfach geschickt? Woher hat der Host die Adressen, an die die 'Antworten' geschickt werden müssen? Und wodurch werden sie 'ausgelöst'?

    0
  • C

    ICQBoy1: Hey, lass mal zocken!
    ICQBoy2: Ok! Meine IP: 123.123.123.123
    ICQBoy1: Meine IP: 321.321.321.321
    ICQBoy2: Hab geschickt, Port offen.
    ICQBoy1: Verbindung steht!

    0
  • B

    cooky451 schrieb:

    ICQBoy1:
    ICQBoy2:

    Aha, aber da hast Du gleich zwei Server ...
    Die IP's müssen ja nicht nur festgestellt und übermittelt werden, sondern auch noch eingetippt ...

    Wie gesagt, ohne Server wird das nix. Da ändert auch die Tatsache nichts dran, dass Du nun Server aus Fleisch und Blut einsetzt.

    0
  • C

    Hä? Wenn ich jetzt in meinen Browser eine IP eingebe um auf Google zu kommen, bin ich deshalb doch kein Server 😕

    0
  • B

    Richtig, der Server sitzt ja auch bei Google und wartet auf Anfragen, die er beantwortet. In Deinem Beispiel würdest Du zuerst bei Google anrufen, Deine IP/Port durchgeben, dann Deine Anfrage starten, und Dein Telefonpartner bei Google würde jetzt Deine IP/Port - Daten in seine Software eintippen und so ein 'Antwort'-Paket erzeugen.

    Btw.
    Wenn ich ein UDP-Paket verschicke, und mein Router also weiß, dass ich auf eine Antwort des von mir adressierten Rechners warte - wie lange würde er eine Antwort akzeptieren? Ich kann mir nicht vorstellen, dass er unbegrenzt lange warten würde, oder doch?

    0
  • I

    Es geht folgendermaßen: beide Clients wissen die IPs des jeweils anderen Router und schicken jetzt (mehr oder weniger gleichzeitig beginnend) fortlaufend UPD-Packete an den anderen Router. Beide Router registrieren jetzt, dass UDP-Packete an einen Server (den andere Router) verschickt werden und erwarten eine Antwort. Und diese kommt ja vom anderen Client. Also bekommen beide Clients eine UDP-Verbindung, obwohl sie beide hinter einem NAT sitzen.
    Ich meine dann ist es auch möglich, eien TCP-Verbindung aufzubauen, dazu weiß ich jetzt aber nichts genaueres.

    0
  • C

    Belli schrieb:

    Richtig, der Server sitzt ja auch bei Google und wartet auf Anfragen, die er beantwortet. In Deinem Beispiel würdest Du zuerst bei Google anrufen, Deine IP/Port durchgeben, dann Deine Anfrage starten, und Dein Telefonpartner bei Google würde jetzt Deine IP/Port - Daten in seine Software eintippen und so ein 'Antwort'-Paket erzeugen.

    Ich meine du kannst auch jeden und alles als Server bezeichnen der auf Informationen wartet, aber das hat doch reichlich wenig mit der Praxis zu tun.

    Ich meine dann ist es auch möglich, eien TCP-Verbindung aufzubauen, dazu weiß ich jetzt aber nichts genaueres.

    Wär mal eine lustige Idee, dürfte aber recht aufwändig sein. Das erste Problem ist der 3-Way-Handshake. Mit der vorgefertigten connect() Funktion wird ein SYN gesendet und ein SYN/ACK erwartet. Die connect() Funktion der Gegenseite kann aber kein SYN/ACK liefern. Wenn überhaupt, dann braucht man dafür dann RAW Sockets, was halt wesentlich aufwändiger ist. (Und auch da muss man noch die "Sequence number" beachten etc. pp.)

    0
  • B

    cooky451 schrieb:

    Belli schrieb:

    Richtig, der Server sitzt ja auch bei Google und wartet auf Anfragen, die er beantwortet. In Deinem Beispiel würdest Du zuerst bei Google anrufen, Deine IP/Port durchgeben, dann Deine Anfrage starten, und Dein Telefonpartner bei Google würde jetzt Deine IP/Port - Daten in seine Software eintippen und so ein 'Antwort'-Paket erzeugen.

    Ich meine du kannst auch jeden und alles als Server bezeichnen der auf Informationen wartet, aber das hat doch reichlich wenig mit der Praxis zu tun.

    Aha ...
    soviel ich weiß, ist es aber weit verbreitet, solche Programme, die zum Beispiel Deine Anfrage an google entgegennehmen, Webserver zu nennen.
    Im übrigen bezeichne ich nicht alles, was auf Informationen wartet, als Server, sondern alles, was Dienste anbietet, indem es auf Anfragen wartet, die es dann bestimmungsgemäß beantwortet, zB Webserver, Gameserver, etc.

    Meinem bescheidenen Informationsstand gemäß ist das auch sehr wohl gängige Praxis. Vielleicht sagst Du mal, was Deiner Meinung nach der Unterschied zwischen einem Server und einem Client ist, bzw. was Du unter einem Server verstehst?

    0
  • C

    Belli schrieb:

    zB Webserver, Gameserver, etc.

    Belli schrieb:

    Telefonpartner

    Belli schrieb:

    Vielleicht sagst Du mal, was Deiner Meinung nach der Unterschied zwischen einem Server und einem Client ist, bzw. was Du unter einem Server verstehst?

    Zwei Erklärungen, wenn eine Zutrifft ist das Programm ein Server:
    1. Ein Programm das dauerhaft auf eine Anfrage von außen wartet (z.B. listen()), dann eine feste Verbindung herstellt (z.B. accept()). (Webserver)
    2. Ein Programm das in irgendeiner Weise die Verwaltung mehrer Clienten übernimmt. (Gameserver)

    Das artet aber eh in Definitionswischerei (schönes Wort) aus, von mir aus sag halt zu allem was bind() aufruft oder irgendwie auf Informationen wartet Server, das ändert aber nichts daran, dass man so ohne einen Port öffnen zu müssen eine Verbindung bekommt. (Und ohne einen Server mieten zu müssen, der das Ganze verwaltet.)

    0
  • *

    Also kann man abschließend sagen, dass eine solche Verbindung ohne externen Server und ohne Port-Forwarding nicht möglich ist auf TCP-Ebene?

    0
  • C

    −BootLag−-BootLag- schrieb:

    Also kann man abschließend sagen, dass eine solche Verbindung ohne externen Server und ohne Port-Forwarding nicht möglich ist auf TCP-Ebene?

    Nicht ohne Gefrickel mit Raw-Sockets.

    0
  • ?

    cooky451 schrieb:

    −BootLag−-BootLag- schrieb:

    Also kann man abschließend sagen, dass eine solche Verbindung ohne externen Server und ohne Port-Forwarding nicht möglich ist auf TCP-Ebene?

    Nicht ohne Gefrickel mit Raw-Sockets.

    Magst du mal skizzieren, wie das mit Raw Sockets und eben ohne einen Dritten funktionieren soll? So ganz hab ich das noch nicht verstanden.

    0
  • C

    fdfdg schrieb:

    Magst du mal skizzieren, wie das mit Raw Sockets und eben ohne einen Dritten funktionieren soll? So ganz hab ich das noch nicht verstanden.

    Nope 🙂
    Falls das überhaupt funktionieren sollte, wird man wohl TCP fast komplett nachbauen dürfen, und das ist mir dann doch zu viel Aufwand.

    0
  • *

    Ich habe mir diese geniale Idee von Skype noch einmal genau angesehen.
    (http://www.heise.de/security/artikel/Wie-Skype-Co-Firewalls-umgehen-270856.html)
    Das Verfahren erinnert mich an das ARP, was die Software Cain & Abel im Netzwerk nutzt, um lokale PC´s auszuspionieren. Allerdings liefert die Software auch TCP-Pakete, weshalb ich davon ausgehe, dass dieses Prinzip nicht nur für UDP sondern auch für TCP funktionieren muss...
    Hat jemand eine Idee, wie das geht?

    0
  • R

    Wenn ich richtig Informiert bin, kann dieses Prinzip funktionieren, muss aber nicht. Bei restrictiver implementierten Firewalls funkt es nicht.

    Skype funktioniert dann aber trotzdem. Im Schlimmsten Fall fungiert Skype auf deinem Rechner dann 100% Passiv (alles muss von innen getriggert werden)

    und ein "aktiver" Client (der von aussen initiert werden kann, seine Ports also forwarded) spielt den Vermittler (mit dem hasst du ne staendige verbindung), wenn 2 passive Clients miteinander telefonieren wollen.
    Skype scannt also wie doof wie sich dein rechner verhaelt und checkt, wie du dich nach aussen verhaelst, und legt dann fest, ob du ein rein passiver, oder aktiver client bist.
    Im hintergrund pflegt und updated es listen von aktiven und passiven Clients. Bei der Installation holst dir von nem "Master ne initiale Clientliste" von denen bekommst wieder andere clients .. usw. So baut sich quasi nen dichtes netz auf ohne viel eigene Infrastruktur. Und auf der suche nach nem bestimmten client fragst du dich also auch durch ...

    Deswegen mögen die Datenschützer und auch die Behörden Skype ned allzu besonders.
    Die Datenschuetzer, weil du als aktiver client Gespraeche von unbekannten routen koenntest(fatal wenn man keine flatrate hat) , und verbindungen zu rechnern aufbaust, mit denen normal nix am hut hasst und die dich auch ned kennen ... und die Behörden, weil der Weg eines Gespraeches ned vorherbestimmbar ist ... und man so auch nix mitschneiden kann ...

    Ciao ...

    0
Anmelden zum Antworten