Diskussion:Hole Punching (Rechnernetz)

keine-quellen-tag

tut en:Hole Punching als quelle nicht reichen? -- 80.171.24.173 16:58 28. Jan 2008

Nein, Wikipedia kann nicht als Quelle für Wikipedia dienen. Der dort zitierte Originalartikel ist allerdings eine gute Quelle. Ich führe den mal unter Literatur auf und entferne den Baustein. --j ?! 17:06, 28. Jan. 2008 (CET)

Nur für UDP, nicht für TCP

So weit ich weiß geht "Hole Punching" nur für UDP, aber nicht für TCP. Es wäre schön das zu erwähnen. MfG, Thomas Güttler (nicht signierter Beitrag von 89.246.166.50 (Diskussion) 07:27, 6. Mai 2015 (CEST))

Soweit erledigt --2A01:C22:C83B:4800:E1CE:68:771D:ED79 17:20, 16. Jul. 2020 (CEST)

• Ich weiss nicht, es gibt einen Artikel en:TCP hole punching und en:ICMP hole punching, der Artikel hier beschäftigt sich "nur" mit UDP. -- A1000 (Diskussion) 16:36, 11. Aug. 2020 (CEST)

erledigtErledigt TCP ergänzt. --Matthäus Wander 13:38, 30. Jul. 2023 (CEST)

"Die Firewall"

Das Szenario "Alice und Bob" trifft nichz ganz die korrekte Beschreibung des Hole-Punching.

Tatsächlich hat man im Internet kaskadierte Firewalls/NATs (Router, ISP, Tunneln IPv4 via IPv6, ...) und es passiert nicht, dass wie beschrieben ein UDP-Packet bei der Firewall des Gegenübers ankommt und dort initial beblockt wird, sondern: Es gibt initial gar kein Routing für diese Verbindung. Die Routing-Regeln zwischen lokalem Netzwerk und dem gemeinsamen öffentlichen Netzwerk werden durch das Senden von Packeten an einen öffentlich sichtbaren Vermittlungsserver (STUN) hergestellt. Genau mit den Addressen/Ports, die der Vermittlungsserver sieht, sind Alice und Bob aus dem öffentlichen Netz per UDP erreichbar. In dem Moment, wo Alice Bobs öffentliche Addresse erfährt, sind alle Firewalls schon offen für die direkte Kommunikation.

Alice braucht ihre öffentliche (dynamische) Adresse nicht zu kennen, es genügt wenn sie Bobs Adresse/Port vom Austauschserver erhält.

Eventuell sollte man den Artikel überarbeiten, weil zahlreiche Foren über den Verweis auf dieses Alice-Bob-Szenario stolpern.

Action127

In dem Szenario eines Heimrouters befinden sich Firewall und NAT auf demselben Gerät, oder genauer gesagt: NAT setzt einen zustandsbehafteten Paketfilter voraus. "Die Firewall" ist hier evtl. irreführend.

Ein offener Port zum Vermittlungsserver reicht in der Mehrheit der Fälle nicht aus, denn es hängt von der Portzuordnung und Filterung des NAT-Routers ab. Laut dieser Quelle (Seite 96) zeigen nur 20% der getesten Fälle ein endpunkt-unabhängiges Filterverhalten auf, d.h. in 80% der Fälle wird über den offenen Port zum Vermittlungsserver keine Kommunikation zu Dritten zustande kommen. --Matthäus Wander 13:53, 30. Jul. 2023 (CEST)

Firewall im engeren Sinn ist Filterverhalten und im Kontext relevant. Mein Punkt ist, dass das Routing (schon vom Rechner zum Router) dynamisch erstellt wird und die Endpunkte erst per Mediator-Kommunikation zu Teilnehmern des öffentlichen Netzes werden. Innerhalb dessen wird eine optionale Adresstranslation adaptiert, falls der Router die Verbindung überhaupt zuläßt: Ist mir nicht klar, wo ^Holzapfel Router-Typen unterscheidet.

Was in meinem Kommentar oben nicht stimmt, ist dass mit der Mediator-Kommunikation der Router schon offen ist für die P2P-Kommunuikation; das Szenario im Artikel ist also korrekt, aber im allgemeinen Kontext der Erstellung einer P2P-Kommunikation lediglich der letzte Schritt. --Action127 (Diskussion) 13:42, 29. Jun. 2024 (CEST)

Was du beschreibst, wird in der Literatur als Network Address Translation bezeichnet, nicht als "dynamisch erstelltes Routing". --Matthäus Wander 14:39, 29. Jun. 2024 (CEST)

IP Adresse von Bob

Im Text sind widersprüchliche Angaben zur IP Adresse von Bob:

"Bobs Client schickt nun ein UDP Paket von seiner IP(1.1.1.1) mit dem ausgehenden Port 50000 an Alice (2.2.2.2:49000)."

"hier allerdings von Bobs IP-Adresse 2.2.2.2 von Port 50000"

Gruß JÖ --141.71.155.195 12:39, 29. Nov. 2022 (CET)

Ich finde die textuelle Beschreibung schwierig nachzuvollziehen. Eine Grafik wäre schön. --Matthäus Wander 13:54, 30. Jul. 2023 (CEST)

Tunneling

Es handelt sich um einen Spezialfall des Tunneling.

Das ist nicht korrekt. Bei Hole Punching findet keine Kapselung in einem anderen Protokoll statt und somit ist es auch kein Tunneling. Hole Punching ist eine Technik zum Öffnen von Ports in einem zustandsbehafteten Paketfilter. --Matthäus Wander 00:58, 30. Jul. 2023 (CEST)

erledigtErledigt entfernt --Matthäus Wander 13:54, 30. Jul. 2023 (CEST)