Netzwerkadressübersetzung

Netzwerkadressenübersetzung zwischen einem privaten Netzwerk und dem Internet ⓘ

Die Netzwerkadressübersetzung (Network Address Translation, NAT) ist eine Methode zur Abbildung eines IP-Adressraums in einen anderen, bei der die Netzwerkadressinformationen im IP-Header der Pakete während der Weiterleitung über ein Verkehrsleitgerät geändert werden. Ursprünglich wurde diese Technik eingesetzt, um zu vermeiden, dass jedem Host eine neue Adresse zugewiesen werden muss, wenn ein Netz verlegt wird oder wenn der vorgelagerte Internetdienstanbieter ausgetauscht wird, aber den Adressraum des Netzes nicht weiterleiten kann. Angesichts der Erschöpfung des IPv4-Adressraums ist es zu einem beliebten und wichtigen Instrument zur Erhaltung des globalen Adressraums geworden. Eine über das Internet routingfähige IP-Adresse eines NAT-Gateways kann für ein ganzes privates Netz verwendet werden. ⓘ

Da die Netzwerkadressübersetzung die IP-Adressinformationen in den Paketen verändert, können NAT-Implementierungen in ihrem spezifischen Verhalten in verschiedenen Adressierungsfällen und in ihren Auswirkungen auf den Netzwerkverkehr variieren. Die Besonderheiten des NAT-Verhaltens werden von den Herstellern der Geräte, die NAT-Implementierungen enthalten, in der Regel nicht dokumentiert. ⓘ

Grundlegendes NAT

Der einfachste Typ von NAT bietet eine Eins-zu-Eins-Übersetzung von IP-Adressen. RFC 2663 bezeichnet diese Art von NAT als Basic NAT; sie wird auch als One-to-One NAT bezeichnet. Bei dieser Art von NAT werden nur die IP-Adressen, die IP-Header-Prüfsumme und alle höherwertigen Prüfsummen, die die IP-Adresse enthalten, geändert. Basic NAT kann verwendet werden, um zwei IP-Netzwerke miteinander zu verbinden, die eine inkompatible Adressierung haben. ⓘ

One-to-many NAT

Abbildung von Netzwerkadressen ⓘ

Die meisten Netzwerkadressübersetzer bilden mehrere private Hosts auf eine öffentlich zugängliche IP-Adresse ab. In einer typischen Konfiguration verwendet ein lokales Netz eines der vorgesehenen privaten IP-Adress-Subnetze (RFC 1918). Ein Router in diesem Netz hat eine private Adresse in diesem Adressraum. Der Router ist außerdem mit einer öffentlichen Adresse, die in der Regel von einem Internet-Dienstanbieter zugewiesen wird, mit dem Internet verbunden. Bei der Übertragung des Datenverkehrs vom lokalen Netz zum Internet wird die Quelladresse in jedem Paket im laufenden Betrieb von einer privaten Adresse in die öffentliche Adresse übersetzt. Der Router verfolgt grundlegende Daten über jede aktive Verbindung (insbesondere die Zieladresse und den Port). Wenn eine Antwort an den Router zurückkehrt, verwendet er die während der ausgehenden Phase gespeicherten Daten zur Verbindungsverfolgung, um die private Adresse im internen Netz zu ermitteln, an die die Antwort weitergeleitet werden soll. ⓘ

Alle IP-Pakete haben eine Quell-IP-Adresse und eine Ziel-IP-Adresse. Bei Paketen, die vom privaten Netz zum öffentlichen Netz weitergeleitet werden, wird in der Regel die Quelladresse geändert, während bei Paketen, die vom öffentlichen Netz zurück zum privaten Netz geleitet werden, die Zieladresse geändert wird. Um Unklarheiten bei der Übersetzung der Antworten zu vermeiden, sind weitere Änderungen an den Paketen erforderlich. Der überwiegende Teil des Internet-Verkehrs verwendet das Transmission Control Protocol (TCP) oder das User Datagram Protocol (UDP). Bei diesen Protokollen werden die Portnummern so geändert, dass die Kombination aus IP-Adresse (im IP-Header) und Portnummer (im Transportschicht-Header) des zurückgesendeten Pakets eindeutig dem entsprechenden Ziel im privaten Netz zugeordnet werden kann. RFC 2663 verwendet den Begriff Network Address and Port Translation (NAPT) für diese Art von NAT. Andere Bezeichnungen sind Port Address Translation (PAT), IP-Masquerading, NAT Overload und Many-to-One NAT. Dies ist die gängigste Art von NAT und ist im allgemeinen Sprachgebrauch zum Synonym für den Begriff "NAT" geworden. ⓘ

Diese Methode ermöglicht die Kommunikation über den Router nur dann, wenn die Konversation ihren Ursprung im privaten Netz hat, da die ursprüngliche Übertragung die erforderlichen Informationen in den Übersetzungstabellen festlegt. Ein Webbrowser im maskierten Netz kann z. B. eine Website außerhalb des Netzes aufrufen, aber ein Webbrowser außerhalb kann keine Website aufrufen, die innerhalb des maskierten Netzes gehostet wird. Protokolle, die nicht auf TCP und UDP basieren, erfordern andere Übersetzungstechniken. ⓘ

Einer der zusätzlichen Vorteile von One-to-Many-NAT ist, dass es eine praktische Lösung für die Erschöpfung der IPv4-Adressen darstellt. Selbst große Netze können über eine einzige öffentliche IP-Adresse mit dem Internet verbunden werden. ⓘ

Methoden der Übersetzung

Die Übersetzung von Netzwerkadressen und Ports kann auf verschiedene Weise erfolgen. Einige Anwendungen, die IP-Adressinformationen verwenden, müssen möglicherweise die externe Adresse eines Netzwerkadressübersetzers ermitteln. Dies ist die Adresse, die von den Kommunikationspartnern im externen Netz erkannt wird. Darüber hinaus kann es erforderlich sein, die Art der verwendeten Zuordnung zu untersuchen und zu kategorisieren, beispielsweise wenn ein direkter Kommunikationspfad zwischen zwei Clients eingerichtet werden soll, die sich beide hinter separaten NAT-Gateways befinden. ⓘ

Zu diesem Zweck wurde 2003 in RFC 3489 ein Protokoll namens Simple Traversal of UDP over NATs (STUN) spezifiziert. Es klassifizierte NAT-Implementierungen als Full-Cone-NAT, (adress)-beschränktes Cone-NAT, portbeschränktes Cone-NAT oder symmetrisches NAT und schlug eine Methode vor, um ein Gerät entsprechend zu testen. Diese Verfahren wurden jedoch inzwischen aus dem Standardstatus gestrichen, da die Methoden nicht ausreichen, um viele Geräte korrekt zu bewerten. Mit RFC 5389 wurden 2008 neue Methoden standardisiert und das Akronym STUN steht nun für den neuen Titel der Spezifikation: Session Traversal Utilities für NAT. ⓘ

Klassifizierung von NAT-Implementierungen ⓘ
Full-Cone-NAT, auch bekannt als One-to-One-NAT Sobald eine interne Adresse (iAddr:iPort) auf eine externe Adresse (eAddr:ePort) abgebildet ist, werden alle Pakete von iAddr:iPort über eAddr:ePort gesendet. Jeder externe Host kann Pakete an iAddr:iPort senden, indem er Pakete an eAddr:ePort sendet.
(Adress)-beschränktes-Kegel-NAT Sobald eine interne Adresse (iAddr:iPort) auf eine externe Adresse (eAddr:ePort) abgebildet ist, werden alle Pakete von iAddr:iPort über eAddr:ePort gesendet. Ein externer Host (hAddr:any) kann nur dann Pakete an iAddr:iPort senden, indem er Pakete an eAddr:ePort sendet, wenn iAddr:iPort zuvor ein Paket an hAddr:any gesendet hat. "Any" bedeutet, dass die Portnummer keine Rolle spielt.
Port-restricted cone NAT Wie ein adressbeschränktes cone NAT, aber die Beschränkung umfasst Portnummern. Sobald eine interne Adresse (iAddr:iPort) auf eine externe Adresse (eAddr:ePort) abgebildet ist, werden alle Pakete von iAddr:iPort über eAddr:ePort gesendet. Ein externer Host (hAddr:hPort) kann nur dann Pakete an iAddr:iPort senden, indem er Pakete an eAddr:ePort sendet, wenn iAddr:iPort zuvor ein Paket an hAddr:hPort gesendet hat.
Symmetrisches NAT Die Kombination aus einer internen IP-Adresse und einer Ziel-IP-Adresse und einem Port wird auf eine einzige externe Quell-IP-Adresse und einen Port abgebildet; wenn derselbe interne Host ein Paket mit derselben Quelladresse und demselben Port, aber an ein anderes Ziel sendet, wird eine andere Abbildung verwendet. Nur ein externer Host, der ein Paket von einem internen Host empfängt, kann ein Paket zurücksenden.

Viele NAT-Implementierungen kombinieren diese Typen, so dass es besser ist, sich auf spezifisches individuelles NAT-Verhalten zu beziehen, anstatt die Terminologie Cone/Symmetric zu verwenden. RFC 4787 versucht, die Verwirrung durch die Einführung einer standardisierten Terminologie für beobachtete Verhaltensweisen zu verringern. Für den ersten Aufzählungspunkt in jeder Zeile der obigen Tabelle würde der RFC Full-Cone-, Restricted-Cone- und Port-Restricted-Cone-NATs als endpunktunabhängiges Mapping charakterisieren, während er ein symmetrisches NAT als adress- und portabhängiges Mapping charakterisieren würde. Für den zweiten Aufzählungspunkt in jeder Zeile der obigen Tabelle würde RFC 4787 auch Full-Cone NAT mit einer endpunktunabhängigen Filterung, Restricted-Cone NAT mit einer adressabhängigen Filterung, Port-Restricted Cone NAT mit einer adress- und portabhängigen Filterung und Symmetric NAT entweder mit einer adressabhängigen Filterung oder einer adress- und portabhängigen Filterung kennzeichnen. Andere Klassifizierungen des NAT-Verhaltens, die im RFC erwähnt werden, beinhalten, ob Ports erhalten bleiben, wann und wie Mappings aufgefrischt werden, ob externe Mappings von internen Hosts verwendet werden können (d.h. das Hairpinning-Verhalten) und den Grad des Determinismus, den NATs bei der Anwendung all dieser Regeln aufweisen. Insbesondere kombinieren die meisten NATs symmetrisches NAT für ausgehende Verbindungen mit statischem Port-Mapping, bei dem eingehende Pakete, die an die externe Adresse und den Port adressiert sind, an eine bestimmte interne Adresse und einen bestimmten Port umgeleitet werden. ⓘ

Art von NAT und NAT-Traversal, Rolle der Port-Erhaltung für TCP

Das NAT-Traversal-Problem tritt auf, wenn Peers hinter verschiedenen NATs versuchen, miteinander zu kommunizieren. Eine Möglichkeit, dieses Problem zu lösen, ist die Verwendung von Portweiterleitung. Eine andere Möglichkeit ist die Verwendung verschiedener NAT-Traversal-Techniken. Die beliebteste Technik zur Umgehung von TCP-NAT ist TCP Hole Punching. ⓘ

Beim TCP Hole Punching muss das NAT dem Port Preservation Design für TCP folgen. Für eine bestimmte ausgehende TCP-Kommunikation werden auf beiden Seiten des NAT die gleichen Portnummern verwendet. Die Erhaltung der NAT-Ports für ausgehende TCP-Verbindungen ist für die Überwindung von TCP-NAT von entscheidender Bedeutung, da unter TCP ein Port jeweils nur für eine Kommunikation verwendet werden kann, so dass Programme verschiedene TCP-Sockets für jede TCP-Kommunikation an ephemere Ports binden, was eine NAT-Portvorhersage für TCP unmöglich macht. ⓘ

Für UDP hingegen brauchen NATs keine Ports zu erhalten. In der Tat können mehrere UDP-Kommunikationen (jede mit einem anderen Endpunkt) über denselben Quellport erfolgen, und Anwendungen verwenden normalerweise denselben UDP-Socket, um Pakete an verschiedene Hosts zu senden. Dies macht die Portvorhersage einfach, da es sich bei jedem Paket um denselben Quellport handelt. ⓘ

Darüber hinaus ermöglicht die Port-Erhaltung in NAT für TCP P2P-Protokollen eine geringere Komplexität und geringere Latenzzeiten, da keine dritte Partei (wie STUN) zur Ermittlung des NAT-Ports eingesetzt werden muss, da die Anwendung selbst den NAT-Port bereits kennt. ⓘ

Wenn jedoch zwei interne Hosts versuchen, mit demselben externen Host über dieselbe Portnummer zu kommunizieren, kann das NAT versuchen, eine andere externe IP-Adresse für die zweite Verbindung zu verwenden, oder es kann erforderlich sein, auf die Port-Erhaltung zu verzichten und den Port neu zuzuordnen. ⓘ

Im Jahr 2006 nutzten etwa 70 % der Clients in P2P-Netzwerken irgendeine Form von NAT. ⓘ

Umsetzung

Aufbau einer bidirektionalen Kommunikation

Bei bidirektionalem NAT kann die Sitzung sowohl von innerhalb als auch von außerhalb des Netzes aufgebaut werden. ⓘ

Jedes TCP- und UDP-Paket enthält eine Quellportnummer und eine Zielportnummer. Jedes dieser Pakete ist in ein IP-Paket eingekapselt, dessen IP-Header eine Quell- und eine Ziel-IP-Adresse enthält. Das Dreiergespann IP-Adresse/Protokoll/Portnummer definiert eine Zuordnung zu einem Netzwerk-Socket. ⓘ

Für öffentlich zugängliche Dienste wie Web- und Mailserver ist die Portnummer wichtig. So wird z. B. Port 80 über einen Socket mit der Webserver-Software verbunden und Port 25 mit dem SMTP-Daemon eines Mailservers. Wichtig ist auch die IP-Adresse eines öffentlichen Servers, die ähnlich wie eine Postanschrift oder eine Telefonnummer weltweit einmalig ist. Sowohl die IP-Adresse als auch die Portnummer müssen allen Hosts, die erfolgreich kommunizieren wollen, korrekt bekannt sein. ⓘ

Private IP-Adressen, wie sie in RFC 1918 beschrieben sind, können nur in privaten Netzen verwendet werden, die nicht direkt mit dem Internet verbunden sind. Ports sind Endpunkte der Kommunikation, die nur für diesen Host gelten, so dass eine Verbindung über das NAT-Gerät durch die kombinierte Zuordnung von Port und IP-Adresse aufrechterhalten wird. Eine private Adresse auf der Innenseite des NAT wird einer externen öffentlichen Adresse zugeordnet. Die Port-Adressübersetzung (PAT) löst Konflikte, die entstehen, wenn mehrere Hosts die gleiche Quell-Portnummer verwenden, um gleichzeitig verschiedene externe Verbindungen herzustellen. ⓘ

Analogie zur Telefonnummern-Erweiterung

Ein NAT-Gerät ist vergleichbar mit einer Telefonanlage in einem Büro, die eine öffentliche Telefonnummer und mehrere Nebenstellen hat. Aus dem Büro ausgehende Telefonanrufe scheinen alle von derselben Telefonnummer zu kommen. Ein eingehender Anruf, bei dem keine Durchwahl angegeben ist, kann jedoch nicht automatisch an eine Person innerhalb des Büros weitergeleitet werden. In diesem Szenario ist das Büro ein privates LAN, die Haupttelefonnummer ist die öffentliche IP-Adresse, und die einzelnen Nebenstellen sind eindeutige Portnummern. ⓘ

Übersetzungsprozess

Bei NAT enthalten alle an externe Hosts gesendeten Mitteilungen die externen IP-Adressen und Portinformationen des NAT-Geräts anstelle der internen Host-IP-Adressen oder Portnummern. NAT übersetzt nur die IP-Adressen und Ports der internen Hosts und verbirgt den wahren Endpunkt eines internen Hosts in einem privaten Netz. ⓘ

Wenn ein Computer im privaten (internen) Netz ein IP-Paket an das externe Netz sendet, ersetzt das NAT-Gerät die interne Quell-IP-Adresse im Header des Pakets durch die externe IP-Adresse des NAT-Geräts. PAT kann dann der Verbindung eine Portnummer aus einem Pool verfügbarer Ports zuweisen, indem es diese Portnummer in das Feld für den Quellport einfügt. Das Paket wird dann an das externe Netz weitergeleitet. Das NAT-Gerät erstellt dann einen Eintrag in einer Übersetzungstabelle, der die interne IP-Adresse, den ursprünglichen Quellport und den übersetzten Quellport enthält. Nachfolgende Pakete mit derselben internen Quell-IP-Adresse und Port-Nummer werden in dieselbe externe Quell-IP-Adresse und Port-Nummer übersetzt. Der Computer, der ein Paket empfängt, das NAT durchlaufen hat, stellt eine Verbindung zu dem Port und der IP-Adresse her, die in dem geänderten Paket angegeben sind, ohne zu wissen, dass die gelieferte Adresse übersetzt wurde. ⓘ

Beim Empfang eines Pakets aus dem externen Netz durchsucht das NAT-Gerät die Übersetzungstabelle anhand des Zielports in der Kopfzeile des Pakets. Wird eine Übereinstimmung gefunden, werden die Ziel-IP-Adresse und die Portnummer durch die in der Tabelle gefundenen Werte ersetzt, und das Paket wird an das interne Netz weitergeleitet. Andernfalls, wenn die Zielportnummer des eingehenden Pakets nicht in der Übersetzungstabelle gefunden wird, wird das Paket verworfen oder zurückgewiesen, da das PAT-Gerät nicht weiß, wohin es gesendet werden soll. ⓘ

Sichtbarkeit des Betriebs

Der NAT-Betrieb ist normalerweise sowohl für die internen als auch für die externen Hosts transparent. Das NAT-Gerät kann als Standard-Gateway für den internen Host fungieren, der in der Regel die wahre IP-Adresse und den TCP- oder UDP-Port des externen Hosts kennt. Der externe Host kennt jedoch nur die öffentliche IP-Adresse des NAT-Geräts und den speziellen Port, der für die Kommunikation im Namen eines bestimmten internen Hosts verwendet wird. ⓘ

Anwendungen

Routing: Die Netzwerkadressübersetzung kann verwendet werden, um die Überschneidung von IP-Adressen zu verringern. Adressüberschneidungen treten auf, wenn Hosts in verschiedenen Netzen mit demselben IP-Adressraum versuchen, denselben Zielhost zu erreichen. Meistens handelt es sich dabei um eine Fehlkonfiguration, die aus der Zusammenlegung zweier Netzwerke oder Subnetze resultieren kann, insbesondere bei der Verwendung der RFC 1918-Adressierung für private Netzwerke. Der Zielhost erfährt Datenverkehr, der scheinbar aus demselben Netz kommt, und zwischengeschaltete Router haben keine Möglichkeit festzustellen, wohin der Antwortverkehr gesendet werden soll. Die Lösung besteht entweder in einer Neunummerierung, um Überschneidungen zu vermeiden, oder in einer Netzwerkadressübersetzung. ⓘ

Lastausgleich: In Client-Server-Anwendungen leiten Lastverteiler Client-Anfragen an eine Reihe von Server-Computern weiter, um die Arbeitslast der einzelnen Server zu verwalten. Die Netzwerkadressübersetzung kann verwendet werden, um eine repräsentative IP-Adresse des Server-Clusters bestimmten Hosts zuzuordnen, die die Anfrage bedienen. ⓘ

Probleme und Einschränkungen

Hosts hinter NAT-fähigen Routern haben keine durchgehende Konnektivität und können nicht an einigen Internetprotokollen teilnehmen. Dienste, die die Initiierung von TCP-Verbindungen aus dem äußeren Netz erfordern oder die zustandslose Protokolle wie UDP verwenden, können gestört werden. Wenn der NAT-Router keine besonderen Anstrengungen unternimmt, um solche Protokolle zu unterstützen, können eingehende Pakete ihr Ziel nicht erreichen. Einige Protokolle können eine NAT-Instanz zwischen teilnehmenden Hosts (z. B. FTP im "passiven Modus") unterbringen, manchmal mit Hilfe eines Gateways auf Anwendungsebene (siehe unten), versagen aber, wenn beide Systeme durch NAT vom Internet getrennt sind. Die Verwendung von NAT erschwert auch Tunneling-Protokolle wie IPsec, da NAT Werte in den Headern verändert, die die Integritätsprüfungen von IPsec und anderen Tunneling-Protokollen stören. ⓘ

Die Ende-zu-Ende-Konnektivität ist ein Grundprinzip des Internet, das beispielsweise vom Internet Architecture Board unterstützt wird. In den aktuellen Dokumenten zur Internet-Architektur wird festgestellt, dass NAT eine Verletzung des End-to-End-Prinzips darstellt, dass NAT aber bei sorgfältiger Planung eine wichtige Rolle spielt. Die Verwendung von IPv6-NAT ist wesentlich problematischer, und viele IPv6-Architekten sind der Meinung, dass IPv6 die Notwendigkeit von NAT beseitigen sollte. ⓘ

Eine Implementierung, die nur die Ports verfolgt, kann durch interne Anwendungen, die mehrere gleichzeitige Verbindungen nutzen, wie z. B. eine HTTP-Anfrage für eine Webseite mit vielen eingebetteten Objekten, schnell erschöpft sein. Dieses Problem kann entschärft werden, indem neben dem Port auch die Ziel-IP-Adresse verfolgt wird, so dass ein einziger lokaler Port von vielen entfernten Hosts genutzt wird. Diese zusätzliche Verfolgung erhöht die Komplexität der Implementierung und die Rechenressourcen auf dem Übersetzungsgerät. ⓘ

Da die internen Adressen alle hinter einer öffentlich zugänglichen Adresse verborgen sind, ist es für externe Hosts unmöglich, direkt eine Verbindung zu einem bestimmten internen Host zu initiieren. Anwendungen wie VOIP, Videokonferenzen und andere Peer-to-Peer-Anwendungen müssen NAT-Traversal-Techniken verwenden, um zu funktionieren. ⓘ

Fragmentierung und Prüfsummen

Reines NAT, das nur mit IP arbeitet, kann Protokolle mit Nutzdaten, die Informationen über IP enthalten, wie z. B. ICMP, korrekt parsen oder nicht. Dies hängt davon ab, ob die Nutzdaten von einem Host auf der Innen- oder Außenseite der Übersetzung interpretiert werden. Grundlegende Protokolle wie TCP und UDP können nicht richtig funktionieren, wenn NAT nicht über die Netzwerkschicht hinaus tätig wird. ⓘ

IP-Pakete haben eine Prüfsumme in jedem Paketkopf, die eine Fehlererkennung nur für den Kopf ermöglicht. IP-Datagramme können fragmentiert werden, und ein NAT muss diese Fragmente wieder zusammensetzen, um eine korrekte Neuberechnung der Prüfsummen auf höherer Ebene und eine korrekte Nachverfolgung, welche Pakete zu welcher Verbindung gehören, zu ermöglichen. ⓘ

TCP und UDP haben eine Prüfsumme, die alle übertragenen Daten abdeckt, sowie den TCP- oder UDP-Header und einen Pseudo-Header, der die Quell- und Ziel-IP-Adresse des Pakets enthält, das den TCP- oder UDP-Header trägt. Damit ein Ursprungs-NAT TCP oder UDP erfolgreich weiterleiten kann, muss er die TCP- oder UDP-Header-Prüfsumme auf der Grundlage der übersetzten IP-Adressen und nicht der Originaladressen neu berechnen und diese Prüfsumme in den TCP- oder UDP-Header des ersten Pakets der fragmentierten Gruppe von Paketen einfügen. ⓘ

Alternativ kann der Ursprungshost eine Pfad-MTU-Ermittlung durchführen, um die Paketgröße zu bestimmen, die ohne Fragmentierung übertragen werden kann, und dann das "Don't Fragment"-Bit (DF) in das entsprechende Paket-Header-Feld setzen. Dies ist nur eine Einweglösung, da der antwortende Host Pakete beliebiger Größe senden kann, die vor Erreichen der NAT fragmentiert werden können. ⓘ

DNAT

Destination Network Address Translation (DNAT) ist eine Technik zur transparenten Änderung der Ziel-IP-Adresse eines weitergeleiteten Pakets und zur Durchführung der umgekehrten Funktion für alle Antworten. Jeder Router, der sich zwischen zwei Endpunkten befindet, kann diese Umwandlung des Pakets vornehmen. ⓘ

DNAT wird häufig verwendet, um einen Dienst, der sich in einem privaten Netz befindet, unter einer öffentlich zugänglichen IP-Adresse zu veröffentlichen. Diese Verwendung von DNAT wird auch als Port-Forwarding oder DMZ bezeichnet, wenn sie für einen ganzen Server verwendet wird, der dem WAN ausgesetzt wird, was einer unverteidigten militärischen demilitarisierten Zone (DMZ) entspricht. ⓘ

SNAT

Die Bedeutung des Begriffs SNAT variiert je nach Anbieter:

Quell-NAT ist eine gängige Erweiterung und stellt das Gegenstück zu Ziel-NAT (DNAT) dar. Damit wird One-to-Many-NAT beschrieben; NAT für ausgehende Verbindungen zu öffentlichen Diensten.
stateful NAT wird von Cisco Systems verwendet
statisches NAT wird von WatchGuard verwendet
sicheres NAT wird von F5 Networks und von Microsoft (in Bezug auf den ISA Server) verwendet ⓘ

Secure Network Address Translation (SNAT) ist Teil von Microsofts Internet Security and Acceleration Server und ist eine Erweiterung des in Microsoft Windows Server integrierten NAT-Treibers. Er bietet Verbindungsverfolgung und Filterung für die zusätzlichen Netzwerkverbindungen, die für die Protokolle FTP, ICMP, H.323 und PPTP benötigt werden, sowie die Möglichkeit, einen transparenten HTTP-Proxy-Server zu konfigurieren. ⓘ

Dynamische Netzwerkadressübersetzung

So funktioniert dynamisches NAT. ⓘ

Dynamisches NAT ist, genau wie statisches NAT, in kleineren Netzwerken nicht üblich, sondern findet sich in größeren Unternehmen mit komplexen Netzwerken. Während statisches NAT eine Eins-zu-eins-Zuordnung von internen zu öffentlichen statischen IP-Adressen bietet, verwendet dynamisches NAT eine Gruppe von öffentlichen IP-Adressen. ⓘ

NAT-Hairpinning

NAT-Hairpinning, auch bekannt als NAT-Loopback oder NAT-Reflection, ist eine Funktion in vielen Consumer-Routern, bei der ein Rechner im LAN über die externe IP-Adresse des LAN/Routers auf einen anderen Rechner im LAN zugreifen kann (wobei der Router eine Portweiterleitung eingerichtet hat, um Anfragen an den entsprechenden Rechner im LAN weiterzuleiten). Dieser Begriff wird offiziell in RFC 5128 von 2008 beschrieben. ⓘ

Im Folgenden wird ein Beispielnetz beschrieben:

Öffentliche Adresse: 203.0.113.1. Dies ist die Adresse der WAN-Schnittstelle des Routers.
Interne Adresse des Routers: 192.168.1.1
Adresse des Servers: 192.168.1.2
Adresse eines lokalen Computers: 192.168.1.100 ⓘ

Wenn ein Paket von einem Computer auf 192.168.1.100 an 203.0.113.1 gesendet wird, würde das Paket normalerweise an das Standard-Gateway (den Router) weitergeleitet. Ein Router mit der NAT-Loopback-Funktion erkennt, dass 203.0.113.1 die Adresse seiner WAN-Schnittstelle ist, und behandelt das Paket so, als käme es von dieser Schnittstelle. Er bestimmt das Ziel für dieses Paket anhand der DNAT-Regeln (Portweiterleitung) für das Ziel. Wenn die Daten an Port 80 gesendet wurden und eine DNAT-Regel für Port 80 existiert, die an 192.168.1.2 gerichtet ist, dann empfängt der Host an dieser Adresse das Paket. ⓘ

Ist keine entsprechende DNAT-Regel vorhanden, verwirft der Router das Paket. Es kann eine ICMP Destination Unreachable-Antwort gesendet werden. Wenn DNAT-Regeln vorhanden waren, ist die Adressübersetzung immer noch in Kraft; der Router schreibt die Quell-IP-Adresse im Paket immer noch um. Der lokale Computer (192.168.1.100) sendet das Paket als von 192.168.1.100 kommend, aber der Server (192.168.1.2) empfängt es als von 203.0.113.1 kommend. Wenn der Server antwortet, ist der Vorgang identisch mit dem eines externen Absenders. Somit ist eine Zwei-Wege-Kommunikation zwischen Hosts innerhalb des LAN-Netzes über die öffentliche IP-Adresse möglich. ⓘ

NAT bei IPv6

Die Übersetzung von Netzwerkadressen wird in IPv6 in der Regel nicht verwendet, da eines der Entwicklungsziele von IPv6 darin besteht, die durchgängige Netzkonnektivität wiederherzustellen. Ein NAT-Loopback wird in der Regel nicht benötigt. Der große Adressraum von IPv6 macht es überflüssig, Adressen zu sparen, und jedem Gerät kann eine eindeutige, global routbare Adresse zugewiesen werden. Dennoch kann die Verwendung eindeutiger lokaler Adressen in Kombination mit Network Prefix Translation zu ähnlichen Ergebnissen führen. ⓘ

Von NAT betroffene Anwendungen

Einige Protokolle der Anwendungsschicht (z. B. FTP und SIP) senden explizite Netzwerkadressen innerhalb ihrer Anwendungsdaten. FTP im aktiven Modus verwendet beispielsweise getrennte Verbindungen für den Kontrollverkehr (Befehle) und für den Datenverkehr (Dateiinhalte). Bei der Anforderung einer Dateiübertragung identifiziert der anfordernde Host die entsprechende Datenverbindung anhand der Adressen der Netzwerk- und Transportschicht. Befindet sich der anfragende Host hinter einer einfachen NAT-Firewall, werden die vom Server empfangenen Informationen durch die Übersetzung der IP-Adresse und/oder der TCP-Portnummer ungültig. Das Session Initiation Protocol (SIP) steuert viele Voice over IP (VoIP)-Anrufe und leidet unter demselben Problem. SIP und SDP können mehrere Ports verwenden, um eine Verbindung aufzubauen und einen Sprachstrom über RTP zu übertragen. IP-Adressen und Portnummern sind in den Nutzdaten kodiert und müssen vor dem Durchqueren von NATs bekannt sein. Ohne spezielle Techniken, wie z. B. STUN, ist das Verhalten von NAT nicht vorhersehbar und die Kommunikation kann fehlschlagen. ⓘ

Application Layer Gateway (ALG)-Software oder -Hardware kann diese Probleme beheben. Ein ALG-Softwaremodul, das auf einem NAT-Firewall-Gerät läuft, aktualisiert alle durch die Adressübersetzung ungültig gewordenen Nutzdaten. ALGs müssen das Protokoll der höheren Schicht verstehen, das sie reparieren müssen, und so erfordert jedes Protokoll mit diesem Problem ein separates ALG. Auf vielen Linux-Systemen gibt es beispielsweise Kernel-Module namens Connection Tracker, die zur Implementierung von ALGs dienen. ALG funktioniert jedoch nicht, wenn der Kontrollkanal verschlüsselt ist (z. B. FTPS). ⓘ

Eine andere mögliche Lösung für dieses Problem ist die Verwendung von NAT-Traversal-Techniken unter Verwendung von Protokollen wie STUN oder ICE oder von proprietären Ansätzen in einem Session Border Controller. NAT-Traversal ist sowohl bei TCP- als auch bei UDP-basierten Anwendungen möglich, aber die UDP-basierte Technik ist einfacher, wird besser verstanden und ist besser mit bestehenden NATs kompatibel. In jedem Fall muss das High-Level-Protokoll mit Blick auf NAT-Traversal entwickelt werden und funktioniert nicht zuverlässig über symmetrische NATs oder andere schlecht funktionierende Legacy-NATs. ⓘ

Andere Möglichkeiten sind UPnP Internet Gateway Device Protocol, NAT-PMP (NAT Port Mapping Protocol) oder Port Control Protocol (PCP), die jedoch voraussetzen, dass das NAT-Gerät dieses Protokoll implementiert. ⓘ

Die meisten traditionellen Client-Server-Protokolle (mit Ausnahme von FTP) senden jedoch keine Schicht-3-Kontaktinformationen und erfordern keine besondere Behandlung durch NATs. Tatsächlich ist die Vermeidung von NAT-Komplikationen heute praktisch eine Voraussetzung für die Entwicklung neuer Protokolle der höheren Schicht (z. B. die Verwendung von SFTP anstelle von FTP). ⓘ

NATs können auch Probleme verursachen, wenn IPsec-Verschlüsselung angewendet wird und wenn sich mehrere Geräte wie SIP-Telefone hinter einem NAT befinden. Telefone, die ihre Signalisierung mit IPsec verschlüsseln, kapseln die Portinformationen in ein verschlüsseltes Paket ein, was bedeutet, dass NA(P)T-Geräte nicht auf den Port zugreifen und ihn übersetzen können. In diesen Fällen schalten die NA(P)T-Geräte auf einfachen NAT-Betrieb um. Das bedeutet, dass der gesamte zum NAT zurückkehrende Verkehr auf einen Client abgebildet wird, wodurch der Dienst für mehr als einen Client "hinter" dem NAT ausfällt. Für dieses Problem gibt es mehrere Lösungen: zum einen die Verwendung von TLS, das auf Ebene 4 des OSI-Referenzmodells arbeitet und die Portnummer nicht maskiert; zum anderen die Kapselung von IPsec in UDP - letzteres ist die von TISPAN gewählte Lösung, um ein sicheres NAT-Traversal zu erreichen, oder ein NAT mit "IPsec Passthru"-Unterstützung. ⓘ

Interactive Connectivity Establishment ist eine NAT-Traversal-Technik, die nicht auf ALG-Unterstützung angewiesen ist. ⓘ

Die von Dan Kaminsky am 8. Juli 2008 bekannt gegebene DNS-Protokollschwachstelle ist indirekt von der NAT-Port-Zuordnung betroffen. Um DNS-Cache-Poisoning zu vermeiden, sollten die UDP-Quellportnummern ausgehender DNS-Anfragen von einem DNS-Server hinter einer Firewall, die NAT implementiert, möglichst nicht übersetzt werden. Die empfohlene Abhilfemaßnahme für die DNS-Schwachstelle besteht darin, dass alle DNS-Server im Cache randomisierte UDP-Quellports verwenden. Wenn die NAT-Funktion die UDP-Quellports de-randomisiert, wird der DNS-Server angreifbar. ⓘ

Beispiele für NAT-Software

Internetverbindungsfreigabe (ICS): NAT- und DHCP-Implementierung, die in Windows-Desktop-Betriebssystemen enthalten ist
IPFilter: enthalten in (Open)Solaris, FreeBSD und NetBSD, verfügbar für viele andere Unix-ähnliche Betriebssysteme
ipfirewall (ipfw): FreeBSD-eigener Paketfilter
Netfilter mit iptables/nftables: der Linux-Paketfilter
NPF: NetBSD-eigener Paketfilter
PF: OpenBSD-eigener Paketfilter
Routing and Remote Access Service: Routing-Implementierung, die in Windows Server-Betriebssystemen enthalten ist
WinGate: Routing-Implementierung eines Drittanbieters für Windows ⓘ

NAT-Typen

NAT wird in Source-NAT (SNAT; deutsch: „Quellen-NAT“) und Destination-NAT (DNAT; deutsch: „Ziel-NAT“) unterschieden. Beim Source-NAT wird die Adresse des verbindungsaufbauenden Computers (Quelle) umgeschrieben. Beim Destination-NAT ist es die Adresse des angesprochenen Computers (Ziel), die umgeschrieben wird. ⓘ

Funktionsweise

NAT-Router, NAT-Session und NAT-Table

Ein moderner Router mit NAT-Funktion ist zustandsbehaftet und wird daher auch als stateful bezeichnet. Beim stateful firewalling werden für jede seitens eines Clients angefragte Verbindung die zugehörigen Verbindungsinformationen (unter anderem IP-Adressen, Protokoll / Ports und Timeouts) in einer Session-Table (siehe netfilter - connection-tracking) gespeichert. Anhand der gespeicherten Informationen kann der NAT-Router dann das jeweilige Antwort-Datenpaket dem richtigen Client wieder zuordnen. Nach Ablauf einer Session wird ihr Eintrag aus der Session-Table gelöscht. Die Anzahl der Sessions, die ein NAT-Router gleichzeitig offen halten kann, ist durch seinen Arbeitsspeicher begrenzt, 10.000 Sessions belegen nur etwa 3 MB. ⓘ

Destination NAT

Bei jedem Verbindungsaufbau durch den Client wird die Ziel-IP-Adresse durch die des eigentlichen Empfängers im LAN ersetzt. Außerdem wird der Zielport durch einen freien Port des Routers ersetzt, der dadurch belegt wird. Diese Zuordnung wird in der NAT-Table des Routers gespeichert. ⓘ

Quelle	Ziel	Quelle	Ziel
öffentliches Netz (WAN)		lokales Netz (LAN) ⓘ
170.0.0.1:1001	171.4.2.1:80	170.0.0.1:1001	192.168.0.2:80
170.0.0.1:1001	171.4.2.1:22	170.0.0.1:1001	192.168.0.3:22
170.0.0.1:1001	171.4.2.1:81	170.0.0.1:1001	192.168.0.3:81

Siehe auch

Portweiterleitung
Windows-Internetverbindungsfreigabe
NAT64, Übersetzung zwischen zwei Protokollfamilien
Network Address Port Translation ⓘ

Spezifikationen

RFC 2663. – IP Network Address Translator (NAT) Terminology and Considerations. [Errata: RFC 2663]. August 1999. (englisch).
RFC 2766. – Network Address Translation – Protocol Translation (NAT-PT). Februar 2000. (Aktualisiert durch RFC 3152 – Historisch – englisch).
RFC 3022. – Traditional IP Network Address Translator (Traditional NAT). [Errata: RFC 3022]. Januar 2001. (Löst RFC 1631 ab – englisch). ⓘ