Normalerweise behält ein NAT den öffentlichen Endpunkt eines lokalen Endpunkts für alle Pakete, die von ihm kommen, bei, wodurch UDP Hole Punching problemlos möglich ist. Einige NATs ordnen den lokalen Endpunkt jedoch für jeden Host, an den ein Paket gesendet wird, einem anderen öffentlichen Endpunkt zu, wodurch UDP Hole Punching nicht möglich ist.
Die einzige Möglichkeit, herkömmliches UDP-Punching durchzuführen, besteht darin, den Remote-Endpunkt zu erraten. Da es jedoch mehr als 65.000 Ports gibt, ist diese Methode nicht sehr zuverlässig. Ich habe gelesen, dass Anwendungen wie Skype – die wissentlich über praktisch jede Art von NAT kommunizieren können – dafür ein Relay verwenden. Hier sind meine Fragen:
Ein Relay ist einfach ein Socket, der eingehende Daten von einem Socket zu einem anderen Socket überträgt, richtig? Gibt es andere Möglichkeiten, UDP Hole Punching durch unartige NATs durchzuführen, ohne entweder wilde Vermutungen anzustellen oder ein Relay zu verwenden (was dann nicht mehr wirklich „Hole Punching“ ist)?
Antwort1
Der Begriff „nicht gut funktionierende NATs“ ist falsch. Jedes NAT-Gerät, das PAT (Port Address Translation) verwendet, um mehrere private Adressen zu einer einzigen öffentlichen Adresse zusammenzufassen, wird Quellports neu zuordnen. Dies ist der Begriff „Portadresse“ in PAT.
Es wäre unmöglich, dass zwei interne Geräte dieselbe Quelladresse für dasselbe Ziel verwenden und erwarten, dass der Quellport nach NATting derselbe bleibt. Außerdem ist es nicht förderlich für die Sicherheit, wenn versucht wird, den Quellport bei der Zielansteuerung mehrerer Ziele konsistent zu halten. Dies ist also im Allgemeinen kein Ziel, das Firewalls bei ihrem Design verfolgen.
Das hilft hier natürlich nicht weiter, da Sie den Quellport einer Verbindung wissen möchten, ohne tatsächlich Pakete von dieser Quelle zu empfangen. Ein Relay ist die naheliegende Option, wenn die Endpunkte über einen Dritten kommunizieren (ja, ein Relay überträgt nur Pakete zwischen Sockets, wie Sie vorschlagen – die Implementierung ist innerhalb von Skype-Servern wahrscheinlich weitaus komplexer, aber im Prinzip ist es dasselbe).
Es ist schwer vorstellbar, dass dies auf andere Weise geschehen könnte, da die Endpunkte nichts von den während der Übertragung stattfindenden Übersetzungen wissen und daher nicht einmal über einen Nebenkanal irgendeiner Art mitteilen könnten, welcher ihr Quellport ist (z. B. indem sie den Port nur bei einem zentralen Server registrieren, aber direkt kommunizieren).