Netzwerkadressübersetzung

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Network Address Translation)

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

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

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.

Verwendung von NAT

Verwendung von Source-NAT

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 wird auch Masquerading bzw. Masquerade[2] genannt, was 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 (neue) Quell-Adresse explizit angegeben werden muss.

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. Durch das Maskieren der Quell-IP-Adresse können tatsächlich die internen Rechner nicht mehr von außen direkt angesprochen werden, was aber eher als Nebeneffekt zu betrachten ist, da es weder Sicherheitsinfrastruktur ersetzt noch zur Trennung von Netzen vorgesehen ist.

Verwendung von Destination-NAT

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 als „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-Traversal bzw. NAT-T.

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

Source NAT

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 Beispiel

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 seines (privaten) Netzes senden, beispielsweise an einen Telnet-Server irgendwo entfernt im Internet, so funktioniert der Kommunikationsprozess (vereinfacht dargestellt) wie folgt: Zuerst ermittelt die Station über DNS die Ziel-IP des Telnet-Servers, und über die Routing-Tabelle 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 49152) 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 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.

ö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

Kategorisierung

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:

Datei:Full Cone NAT.svg 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. Full Cone NAT ist auch unter der Bezeichnung englisch port forwarding bekannt.
Datei:Restricted Cone NAT.svg 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 und dabei der gleiche Zielport verwendet wird.
Datei:Port Restricted Cone NAT.svg Im Port 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 und dabei der gleiche Zielport und der gleiche Quellport verwendet wird.
Datei:Symmetric NAT.svg Im Symmetric-NAT-Szenario wird jede einzelne Verbindung mit einem unterschiedlichen Quellport ausgeführt, die Beschränkungen sind wie bei Restricted Cone NAT-Szenario. Dadurch dass jede Verbindung einen eigenen Quellport zugewiesen bekommt ist eine Initiierung von Verbindungen durch externe Hosts nach Intern nicht oder kaum möglich.

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.

Vorteile

  • 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]

Nachteile

  • 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-Traversal

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 Router 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 auch

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).

Weblinks

Einzelnachweise

  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). Mai 1994. (Internet Engineering Task Force – englisch).
  5. ↑ M. Holdrege, P. Srisuresh: RFC 3027. – Protocol Complications with the IP Network Address Translator. Januar 2001. (englisch).
  6. ↑ Tony Hain: RFC 2993. – Architectural Implications of NAT. (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
Abgerufen von „https://de.wikiup.org/index.php?title=Netzwerkadressübersetzung&oldid=226497823“