Einleitung
Dieses Dokument beschreibt die Notwendigkeit von Session Traversal Utilities für NAT-Server (STUN), die Arten von Network Address Translation (NAT)-Konfigurationen in Bezug auf STUN-Server, wie NAT ein Problem in dieser Konfiguration verursacht und die Lösung.
Hintergrundinformationen
NAT-Geräte dienen in erster Linie dazu, Geräten mit privaten IP-Adressen in einem LAN die Kommunikation mit Geräten in öffentlichen Adressräumen, z. B. dem Internet, zu ermöglichen. Obwohl NAT-Geräte internen Hosts ermöglichen sollen, sich mit dem öffentlichen Raum zu verbinden, bietet NAT bei Point-to-Point (P2P)-Anwendungen wie VoIP, Gaming, WebRTC und Filesharing, bei denen die Endbenutzer sowohl als Client als auch als Server agieren müssen, um eine bidirektionale End-to-End-Kommunikation aufrechtzuerhalten, Schwierigkeiten beim Aufbau dieser UDP-Verbindungen. Damit diese Anwendungen funktionieren, sind in der Regel NAT-Überbrückungstechniken erforderlich.
NAT-Traversal erforderlich
Sprach- und Videokommunikation in Echtzeit über das Internet sind heute Standard bei einer Reihe beliebter Instant Messaging-Geräte, die VoIP-Anrufe unterstützen. Eine große Hürde bei der anfänglichen Einführung von VoIP war die Tatsache, dass die meisten PCs oder andere Geräte hinter Firewalls sitzen und private IP-Adressen verwenden. Mehrere private Adressen (IP-Adresse und Port) im Netzwerk werden einer einzigen öffentlichen Adresse durch eine Firewall mit NAT zugeordnet. Das Endgerät kennt jedoch seine öffentliche Adresse nicht und kann daher keinen Sprachdatenverkehr von der Gegenstelle über die private Adresse empfangen, die es in seiner VoIP-Kommunikation ankündigt.
Unilateral Self-Address Fixing (UNSAF)-Prozesse sind Prozesse, bei denen ein Ursprungsendpunkt versucht, die Adresse (und den Port) zu bestimmen oder zu fixieren, über die er einem anderen Endpunkt bekannt ist - beispielsweise, um Adressdaten im Protokollaustausch verwenden zu können oder um eine öffentliche Adresse anzukündigen, von der er Verbindungen empfängt.
Bei den hier diskutierten P2P-Verbindungen handelt es sich somit um UNSAF-Prozesse. Eine gängige Methode für P2P-Anwendungen, Peering-Sitzungen einzurichten und NAT-freundlich zu bleiben, ist die Verwendung eines öffentlich adressierbaren Rendezvous-Servers für Registrierungs- und Peer-Discovery-Zwecke.
Session Traversal-Dienstprogramme für NAT
Gemäß RFC 5389 stellt STUN ein Tool bereit, das NATs verarbeitet. Es bietet einem Endpunkt die Möglichkeit, die von einem NAT-Gerät zugewiesene IP-Adresse und den zugewiesenen Port zu bestimmen, die mit der privaten IP-Adresse und dem Port übereinstimmen. Sie bietet einem Endpunkt auch die Möglichkeit, eine NAT-Bindung am Leben zu erhalten.
Arten von NAT-Implementierungen
Es wurde beobachtet, dass die NAT-Behandlung von UDP bei den einzelnen Implementierungen unterschiedlich ist. Bei den Implementierungen wurden die folgenden vier Behandlungen beobachtet:
Full Cone: Ein Full-Kegel-NAT ist ein NAT, bei dem alle Anfragen von derselben internen IP-Adresse und demselben Port derselben externen IP-Adresse und demselben externen Port zugeordnet werden. Darüber hinaus kann jeder externe Host ein Paket an den internen Host senden, und dieser sendet ein Paket an die zugeordnete externe Adresse.
Restricted Cone (Eingeschränkter Kegel): Eine NAT mit eingeschränktem Kegel ist eine Anforderung, bei der alle Anforderungen von derselben internen IP-Adresse und demselben Port derselben externen IP-Adresse und demselben externen Port zugeordnet werden. Im Gegensatz zu einer Full-Kegel-NAT kann ein externer Host (mit der IP-Adresse X) ein Paket nur dann an den internen Host senden, wenn der interne Host zuvor ein Paket an die IP-Adresse X gesendet hatte.
Port Restricted Cone: Ein Port Restricted Kegel NAT ist wie ein Restricted Kegel NAT, aber die Einschränkung umfasst Portnummern. Insbesondere kann ein externer Host ein Paket mit der Quell-IP-Adresse X und dem Quell-Port P nur dann an den internen Host senden, wenn der interne Host zuvor ein Paket an die IP-Adresse X und den Port P gesendet hat.
Symmetrisch: Eine symmetrische NAT besteht darin, dass alle Anforderungen von derselben internen IP-Adresse und demselben Port an eine bestimmte Ziel-IP-Adresse und einen bestimmten Port derselben externen IP-Adresse und demselben externen Port zugeordnet sind. Wenn derselbe Host ein Paket mit derselben Quelladresse und demselben Port, jedoch an ein anderes Ziel sendet, wird eine andere Zuordnung verwendet. Außerdem kann nur der externe Host, der ein Paket empfängt, ein UDP-Paket zurück an den internen Host senden.
Betrachten wir eine Topologie, in der die Quelle (A, Pa) (wobei A die IP-Adresse und Pa der Quell-Port ist) über ein NAT-Gerät mit dem Ziel (B, Pb) und (C, PC) kommuniziert.
Typ der NAT-Implementierung |
Öffentliche Quelle für (B, Pb) |
Öffentliche Quelle für (C, PC) |
Kann das Ziel (z. B. (B, Pb) ) Datenverkehr an (A, Pa) senden? |
Voller Ton |
(X1,PX1) |
(X1,PX1) |
Ja |
Restricted Cone |
(X1,Px1) |
(X1,Px1) |
Nur wenn (A, Pa) den Datenverkehr zuerst an B gesendet hat |
Port Restricted Cone |
(X1,Px1) |
(X1,Px1) |
Nur wenn (A, Pa) den Datenverkehr zuerst an (B, Pb) gesendet hat |
Symmetrisch |
(X1,Px1) |
(X2, Px2) |
Nur wenn (A, Pa) den Datenverkehr zuerst an (B, Pb) gesendet hat |
Probleme mit NAT Traversal und Symmetric NAT
STUN-Server reagieren auf STUN-Bindungsanfragen, die von STUN-Clients gesendet werden, und stellen die öffentliche IP/Port des Clients bereit. Nun wird diese Adresse/Port-Kombination vom STUN-Client in seiner Peer-to-Peer-Kommunikationssignalisierung verwendet. Da der Endhost jedoch dieselbe private Adresse/denselben privaten Port verwendet (nehmen wir an, dass die öffentliche IP/der öffentliche Port gebunden ist, die in der STUN-Antwort angegeben ist), übersetzt das NAT-Gerät sie in dieselbe IP, aber einen anderen Port, wenn eine symmetrische NAT-Implementierung verwendet wird. Dadurch wird die UDP-Kommunikation unterbrochen, da die Signalisierung die Verbindung basierend auf dem vorherigen Port hergestellt hatte.
Die NAT-Implementierung der Cisco IOS® Router bei der Ausführung der PAT ist standardmäßig symmetrisch. Daher werden bei diesen Routern, die NAT ausführen, UDP-Verbindungsprobleme erwartet.
Die NAT-Implementierung der Cisco IOS-XE-Router bei der PAT-Ausführung ist jedoch nicht symmetrisch. Wenn Sie zwei verschiedene Streams mit derselben Quell-IP und demselben Port, aber an verschiedene Ziele senden, wird die Quelle innerhalb der globalen IP-Adresse und des Ports mit derselben NATED versehen.
Die Lösung des Problems
Aus dieser Beschreibung wird deutlich, dass das Problem behoben werden kann, wenn Sie eine endpunktunabhängige Zuordnung durchführen.
Gemäß RCFC 4787: Mit Endpoint-Independent Mapping (EIM) verwendet die NAT die Port-Zuordnung für nachfolgende Pakete, die von derselben internen IP-Adresse und demselben Port (X:x) an eine beliebige externe IP-Adresse und einen beliebigen Port gesendet werden.
Wenn der Endhost auf einem Client die Befehle nc -p 23456 10.0.0.4 4000 und nc -p 23456 10.0.0.5 50000 ausführt, werden die Ergebnisse der NAT-Übersetzungen bei Verwendung von EIM:
Pro Inside global Inside local Outside local Outside global
tcp 10.0.0.1:23456 192.168.0.2:23456 10.0.0.4:40000 10.0.0.4:40000
tcp 10.0.0.1:23456 192.168.0.2:23456 10.0.0.5:50000 10.0.0.5:50000
Hier können Sie sehen, dass verschiedene Datenverkehrsflüsse, die dieselbe Quelladresse und denselben Port haben, in dieselbe Adresse/denselben Port umgewandelt werden, unabhängig vom Zielport bzw. von der Zieladresse.
Auf Cisco IOS-Routern können Sie mit dem Befehl ip nat service enable-sym-port die Endpunkt-unabhängige Portzuweisung aktivieren.
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/15-mt/nat-15-mt-book/iadnat-fpg-port-alloc.html
Zusammenfassung
Die Cisco IOS NAT-Implementierung ist standardmäßig symmetrisch, wenn Sie Port Address Translation (PAT) verwenden. Sie kann Probleme verursachen, wenn P2P-UDP-Datenverkehr weitergeleitet wird, für den Server wie STUN für NAT-Traversal erforderlich sind. Damit dies funktioniert, müssen Sie EIM auf dem NAT-Gerät explizit konfigurieren.