Hauptmenü öffnen

Netzwerkadressübersetzung

Netzwerkprotokoll

Netzwerkadressübersetzung[1] (englisch Network Address Translation, kurz NAT) ist in Rechnernetzen der Sammelbegriff bei Änderungen von Adressen im IP header von IP-Paketen (Layer-3 des ISO-OSI-Modells).

NAT (genauer SNAT) ermöglicht unter anderem die gleichzeitige Verwendung einer öffentlichen Adresse (vgl. private IP-Adressen) durch mehrere Hosts. Üblicherweise übernimmt der Router im Netzwerk das SNAT, der die Verbindung zum Internet herstellt (daher ist in der Regel dieser Router das Default-Gateway eines Hosts).

Inhaltsverzeichnis

NAT-TypenBearbeiten

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.

Verwendung von NATBearbeiten

Verwendung von Source-NATBearbeiten

Am meisten findet Source-NAT Anwendung aufgrund der Knappheit öffentlicher IPv4-Adressen und der Tendenz, immer mehr Haushalte (in denen private Subnetze verwendet werden) mit dem Internet zu verbinden. Die spezielle Form der SNAT-Übersetzung wird auch Masquerading bzw. Masquerade[2] genannt, die vor allem bei Einwahlverbindungen genutzt wird. Beim Maskieren wird automatisch durch einen Algorithmus die Absender-Adresse des Pakets in die IP-Adresse des Interfaces geändert, auf dem das Paket den Router verlässt, während beim SNAT die Quell-Adresse beliebig festgelegt werden kann.

Gerade in privaten oder möglichst preisgünstig ausgeführten Netzinstallationen wird Source-NAT als eine Art Sicherheitsmerkmal und zur Trennung von internen und externen Netzen eingesetzt. Dabei erfüllt NAT oberflächlich tatsächlich diesen Anspruch, ersetzt aber weder Sicherheitsinfrastruktur noch weitere Maßnahmen zur Trennung von Netzen.

Verwendung von Destination-NATBearbeiten

Destination-NAT wird verwendet, um das Ziel eines IP-Pakets zu ändern. Am häufigsten findet DNAT Verwendung beim Ändern der öffentlichen IP eines Internet-Anschlusses in die private IP-Adresse eines Servers im privaten Subnetz. Diese Methode ist auch unter "Port-Forwarding" in Verbindung mit UDP / TCP - Verbindungen bekannt. DNAT kann daher auch dazu genutzt werden, um mehrere, unterschiedliche Serverdienste, die auf verschiedenen Computern betrieben werden, unter einer einzigen (öffentlichen) IP-Adresse anzubieten. Siehe zur Abgrenzung von DNAT auch NAT-T.

FunktionsweiseBearbeiten

NAT-Router, NAT-Session und NAT-TableBearbeiten

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.[3]

Source NATBearbeiten

Bei jedem Verbindungsaufbau durch einen internen Client wird die interne Quell-IP-Adresse durch die öffentliche IP-Adresse des Routers ersetzt. Außerdem wird der Quellport des internen Clients durch einen freien Port des Routers ersetzt, falls der Ursprungsport belegt ist. Diese Zuordnung wird in der Session-Table (NAT-Table) des Routers gespeichert. Anhand der gespeicherten Informationen kann der NAT-Router dann das jeweilige Antwort-Datenpaket dem richtigen Client wieder zuordnen. Der Vorgang wird als PAT (Port and Address Translation) bezeichnet.

lokales Netz (LAN) öffentliches Netz (WAN)
Quelle Ziel Router
===== = =====>
NAT
Quelle Ziel
192.168.0.2:49701 170.0.0.1:80 205.0.0.2:49701 170.0.0.1:80
192.168.0.3:50387 170.0.0.1:80 205.0.0.2:50387 170.0.0.1:80
192.168.0.4:49152 170.0.0.1:23 205.0.0.2:49152 170.0.0.1:23

Source-NAT und IP-Routing am BeispielBearbeiten

In diesem Beispiel nutzt das private Netz die IP-Adressen 192.168.0.0/24. Zwischen diesem Netz und dem öffentlichen Internet befindet sich ein Source-NAT-Router mit der öffentlichen Adresse 205.0.0.2/32.

Allgemein ist immer dann ein Routing erforderlich, wenn Absender und Empfänger in verschiedenen Netzen liegen. Möchte eine über einen Source-NAT-Router angebundene Station ein Paket an einen Empfänger außerhalb ihres privaten Netzes senden, beispielsweise an einen Telnet-Server irgendwo entfernt im Internet, so funktioniert der Kommunikationsprozess (vereinfacht dargestellt) wie folgt: Zuerst ermittelt die Station den für das gewünschte Ziel nächstgelegenen Router (siehe Routingtabelle), das sei hier der Source-NAT-Router, dann ermittelt die Station per ARP dessen MAC-Adresse und baut ein Paket wie folgt zusammen: Es erhält als Ziel-MAC-Adresse die MAC-Adresse des Source-NAT-Routers, die Ziel-IP-Adresse des Empfängers (hier 170.0.0.1), die Ziel-Portadresse 23 für den Telnet-Server sowie die MAC- und IP-Adresse des Absenders (hier 192.168.0.4) und einen Absenderport (irgendeinen freien high dynamic Port) für die gerade anfragende Telnet-Sitzung sowie andere Daten. Der Source-NAT-Router empfängt und verarbeitet das Paket, weil es an seine MAC-Adresse gerichtet ist. Bei der Verarbeitung im Router wird das Paket in abgeänderter Form weitergeleitet: der Router ermittelt anhand der Empfänger-IP-Adresse den nächsten Router, ermittelt per ARP dessen MAC-Adresse und baut das Paket wie folgt um: Es erhält nun abweichend die MAC-Adresse des nächsten Routers, die Ziel-IP-Adresse des Empfängers (170.0.0.1), Ziel-Port 23 sowie die öffentliche MAC- und IP-Adresse des Source-NAT-Routers (205.0.0.2), einen gerade freien Absender-Port aus dem Reservoir des Routers (hier 4806) und die Nutzdaten, die gleich bleiben. Diese Zuordnung der ursprünglichen Absenderadresse und des Ports (192.168.0.4:49152) zum jetzt enthaltenen Adress-Tupel (205.0.0.2:49152) wird im Router solange gespeichert, bis die Telnet-Sitzung abläuft oder beendet wird. Durch NAT wird das Paket auf Schicht 3 (IP) also wesentlich verändert.

Bei der Bearbeitung in nachfolgenden IP-Routern wird das Paket lediglich auf Schicht 2 verändert: Der Router ermittelt den nächsten Router, ermittelt per ARP dessen MAC-Adresse und baut das Paket wie folgt um: Es erhält nun abweichend als Ziel-MAC-Adresse die MAC-Adresse des nächsten Routers und die Absender-MAC-Adresse wird gegen die eigene ausgetauscht. Die IP-Adresse des Empfängers (170.0.0.1), Ziel-Port 23 sowie die Absender-IP-Adresse des Source-NAT-Routers (205.0.0.2), dessen Absender-Port 49152 und die Nutzdaten bleiben erhalten. Das bedeutet: Auf Schicht 3 (IP) wird das Paket hier nicht verändert. Dieser Vorgang wiederholt sich, bis ein letzter Router die Zielstation in einem direkt angeschlossenen Netz findet; dann setzt sich das Paket wie folgt zusammen: Es erhält als Absender-MAC-Adresse die des letzten Routers, als Ziel die MAC-Adresse der Zielstation, die IP-Adresse des Empfängers (= Zielstation, 170.0.0.1), Ziel-Port 23 sowie die IP-Adresse des Absender-Source-NAT-Routers (205.0.0.2), dessen Absender-Port 49152 und natürlich Nutzdaten.

Nach erfolgreicher Verarbeitung durch den Telnet-Server wird die Antwort dann wie folgt zusammengestellt: MAC-Adresse des für den Rückweg zuständigen Routers (wobei Hin- und Rückroute nicht unbedingt identisch sein müssen), die IP-Adresse des anfragenden Source-NAT-Routers (205.0.0.2), die Ziel-Portadresse 49152 sowie die MAC- und IP-Adresse des Telnet-Servers (170.0.0.1) und dessen Absenderport 23, sowie Antwort-Daten (Payload). Nachdem alle Router durchlaufen wurden, wird daraus schließlich im Source-NAT-Router (205.0.0.2): MAC-Adresse und IP-Adresse des anfragenden Rechners (hier 192.168.0.4), und dessen Portadresse 49152 sowie die MAC des Source-NAT-Routers und IP-Adresse des Telnet-Servers (170.0.0.1) und dessen Absenderport 23, sowie Antwort-Daten. Wird diese Telnet-Sitzung beendet, wird auch Port 49152 wieder freigegeben.

Destination NATBearbeiten

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.

öffentliches Netz (WAN) lokales Netz (LAN)
Quelle Ziel Router
===== = =====>
NAT
Quelle Ziel
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

KategorisierungBearbeiten

RFC 3489, der das Protokoll STUN zur Traversierung von NAT-Gateways beschreibt, ordnete diese in vier verschiedene Klassen ein, die auch außerhalb des Kontexts von STUN gerne zur Klassifizierung verwendet werden:

  Im Full Cone NAT-Szenario setzt ein Gateway interne Adressen und Ports nach einem statischen Muster in eine externe Adresse und deren Ports um. Es erlaubt insbesondere auch, dass so externe Hosts über die externe Adresse des NAT-Gateways Verbindungen zu internen Hosts aufbauen.
  Im Restricted Cone NAT-Szenario erlaubt das Gateway die Kontaktaufnahme eines externen mit einem internen Host nur, wenn diesem Verbindungsversuch eine Kontaktaufnahme dieses internen Hosts mit dem externen Host vorausging.
  Das Port Restricted Cone NAT-Szenario schränkt diese Erlaubnis der Kontaktaufnahme zusätzlich auf nur den externen Port ein, über den die vorausgehende umgekehrte Kontaktaufnahme stattfand.
  Im Symmetric-NAT-Szenario ist eine Initiierung von Verbindungen durch externe Hosts nach Intern nicht oder kaum möglich, da diese im Allgemeinen nicht abschätzen können, über welche von mehreren externen Adressen des Gateways Verbindungen zu (oder von) einem Internen Host abgewickelt bzw. erwartet werden.

Diese prototypischen Grundszenarien bilden in modernen NAT-Systemen allerdings oft nur noch Anhaltspunkte zur Klassifizierung punktuellen Verhaltens der Gateways. Diese benutzen teilweise Mischformen der klassischen Ansätze zur Adressumsetzung oder wechseln dynamisch zwischen zwei oder mehreren Verhaltensmustern. RFC 3489 ist durch RFC 5389 ersetzt worden, der diese Kategorisierung nicht mehr versucht.

VorteileBearbeiten

  • NAT hilft die Verknappung der IPv4 Adressen zu entschleunigen. Dies geschieht durch die Ersetzung mehrerer Adressen für mehrere Endsysteme durch eine einzige IP-Adresse.[4]
  • IP-Adressen eines Netzes können vor einem anderen Netz verborgen werden. Somit kann NAT zur Verbesserung der Privatsphäre eingesetzt werden.[4]
  • Dieselben IP-Adressbereiche können von mehreren abgeschlossenen privaten Netzwerken verwendet werden, ohne dass es zu Adresskollisionen kommt, da nach außen nur die IP-Adresse des NAT-Routers sichtbar ist.[4]

NachteileBearbeiten

  • Ein Problem an NAT ist, dass die saubere Zuordnung „1 Host mit eindeutiger IP-Adresse“ nicht eingehalten wird.[4] Durch die Umschreibung von Protokoll-Headern, die einem Man-in-the-middle-Angriff ähnelt, haben so insbesondere ältere Protokolle und Verschlüsselungsverfahren auf Netzwerk- und Transportebene durch diesen Designbruch Probleme (zum Beispiel. IPsec-AH). Protokollkomplikationen durch NAT werden in RFC 3027 beschrieben.[5]
  • Ebenso leiden insbesondere Netzwerkdienste, die Out-of-Band-Signalisierung und Rückkanäle einsetzen, etwa IP-Telefonie-Protokolle, unter Komplikationen durch NAT-Gateways.
  • Das Ende-zu-Ende Prinzip[6] wird verletzt, indem der NAT-Router das IP Paket bzw. TCP-Segment verändert, ohne dass er selbst der verschickende Host ist.

NAT-TraversalBearbeiten

Network Address Translation bricht das Gebot der Ende-zu-Ende-Konnektivität. Daher benötigen Anwendungen, die sich typischerweise von Host zu Host verbinden (zum Beispiel bei Peer-to-Peer- und IP-Telefonie-Anwendungen oder VPN-Verbindungen) NAT-Durchdringungstechniken. Es existieren mehrere Techniken, von denen keine universell anwendbar ist. Viele Techniken benötigen die Hilfe eines für beide Parteien direkt öffentlich zugänglichen Servers. Manche Methoden nutzen einen solchen Server nur für den Verbindungsaufbau, andere leiten allen Verkehr der Verbindung über diesen Hilfs-Server.

Die meisten Methoden umgehen damit oft Unternehmens-Sicherheitsrichtlinien, weswegen in Unternehmensnetzwerken Techniken bevorzugt werden, die sich ausdrücklich kooperativ mit NAT und Firewalls verhalten und administrative Eingriffe an der NAT-Übergabestelle erlauben. Die Standards Realm-Specific IP[7] und Middlebox Communication (MIDCOM)[8] finden aber kaum Anwendung.

SOCKS, das älteste Protokoll zur NAT-Durchdringung, ist weit verbreitet, findet aber immer weniger Anwendung. Bei SOCKS baut der Client eine Verbindung zum SOCKS-Gateway auf (dieser ist meistens direkt mit dem Internet verbunden), so dass die Kommunikation für den Kommunikationspartner so wirkt, als würde sie direkt vom SOCKS-Gateway stammen.

Bei Heimanwendungen wird Universal Plug and Play (UPnP) genutzt, was eine dynamische Konfiguration eines port-forwardings durch den Client selbst ermöglicht.

NAT-T findet am häufigsten Gebrauch bei IPsec-VPN, wenn Encapsulating-Security-Payload-Pakete an Internet-Anschlüssen mit NATenden Routern genutzt wird. Dabei werden die ESP-Pakete in UDP/4500 Pakete gepackt. Einige Routern unterstützen auch ESP-pass-through, so dass die ESP-Pakete direkt an das VPN-Gateway durchgereicht werden können und auf NAT-T verzichtet wird.

Ein weiteres Beispiel für ein NAT-Traversal-Protokoll ist STUN, das eine hohe Bedeutung bei VoIP hat.

Siehe auchBearbeiten

SpezifikationenBearbeiten

  • RFC 2663 IP Network Address Translator (NAT) Terminology and Considerations (englisch)
  • RFC 2766 Network Address Translation - Protocol Translation (NAT-PT) (englisch)
  • RFC 3022 Traditional IP Network Address Translator (Traditional NAT) (englisch)

WeblinksBearbeiten

EinzelnachweiseBearbeiten

  1. Grundlegendes zur Netzwerkadressübersetzung. Microsoft, abgerufen am 9. Dezember 2015.
  2. Olaf Kirch, Terry Dawson: Linux – Wegweiser für Netzwerker. 2. Auflage. O’Reilly, 2001, ISBN 3-89721-135-1, Kapitel 11 – IP-Masquerade und die Umsetzung von Netzwerkadressen (deutsch und englisch online – Originaltitel: Linux Network Administrator's Guide. Übersetzt von Peter Klicman und Ingo Marks).
  3. Network Address Translation (NAT) FAQ. Cisco Systems.
  4. a b c d RFC 1631 - The IP Network Address Translator (NAT). Internet Engineering Task Force. Mai 1994.
  5. RFC 3027 - Protocol Complications with the IP Network Address Translator. Internet Engineering Task Force. Januar 2001.
  6. Tony Hain <tonyhain@microsoft.com>: Architectural Implications of NAT. Abgerufen am 20. Dezember 2018 (englisch).
  7. RFC 3102, RFC 3103, RFC 3104
  8. ietf.org (Memento des Originals vom 5. Juni 2011 im Internet Archive)   Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.ietf.org