Network Address Translation

Der ursprüngliche Entwurf der Internet-Protokolle sah kein NAT vor. Er ging von “intelligenten” Endgeräten und einem “dummen” Netz aus, das lediglich wusste, wie es Datenpakete von A nach B transportieren kann. Die Endgeräte kümmerten sich um die Kontrolle der Datenströme und alle anderen Aspekte bis auf die Auswahl der Transportwege.

Diese Trennung der Zuständigkeiten trug einen wesentlichen Teil zur Entwicklung des Internet bei, weil sich Netz und Endgeräte auf ihren Teil konzentrieren und davon ausgehen konnten, dass der jeweils andere Teil seine Aufgabe erfüllt. Durch die globale Adressierung war gewährleistet, dass prinzipiell jedes Endgerät mit jedem anderen kommunizieren konnte.

Dieses Prinzip der Trennung von “dummem” Netz und “intelligenten” Endgeräten wurde im Laufe der Zeit auf verschiedene Art aufgebrochen. Während die Versuche seitens der Endgeräte, die Datenpfade durch Source-Routing zu kontrollieren, keine große Verbreitung fanden, sind im Netz immer mehr Funktionen dazugekommen, die das Netz “intelligenter” und damit schlechter vorhersehbar für die Endgeräte machen.

Eine Art das Netz “intelligenter” zu machen sind Middle-Boxes, die den Datenverkehr inspizieren, manipulieren und aussondern. Zu den Manipulationen zählt unter anderem die Netzwerk-Adressumsetzung, die einen schwerwiegenden Eingriff in die Datagramme darstellt.

Sende ich in einem Netz ohne Middle-Box ein Datagramm von Rechner A nach Rechner B, so kann ich damit rechnen, dass dieses Datagramm genauso beim Ziel ankommt, wie ich es abschicke. Lediglich die TTL wird vermindert und bei IPv4 die Prüfsumme mit der geänderten TTL neu berechnet.

Der Empfänger des Datagramms kann daraus selbst den Absender erkennen und seine Antwort direkt an diesen adressieren. Bei einer Zwei-Wege-Kommunikation ist damit immer klar, wer mit wem kommuniziert.

Sobald NAT dazu kommt, weiss manchmal die eine Seite, manchmal die andere und manchmal beide nicht, mit wem sie kommunizieren.

Das ist bei einer einfachen TCP-Verbindung, wie zum Beispiel beim Übertragen einer Datei via HTTP, unkritisch.

Es gibt jedoch Protokolle, die die Adressinformationen auswerten und verwenden. Sei es, wie bei FTP und TFTP, um eine weitere Verbindung mit einem anderen Port zur Datenübertragung zu öffnen. Oder dass die Nachricht inklusive der Adresse kryptographisch gesichert werden soll, wie bei IPsec. Im ersten Fall kann die NAT-Box durch Beobachten des Datenstroms die nötigen Umsetzungen für die zusätzliche Verbindung einrichten. IPsec hingegen funktioniert nicht über NAT, da die verschlüsselten Daten sich auf die unveränderten Adressen und Ports beziehen. In diesem Fall musste nachträglich eine Variante für IPsec via NAT geschaffen werden.

ICMP-Fehlermeldungen gelangen bei manchen NAT-Boxen nicht zum Absender der auslösenden Nachricht. Damit erschwert NAT dem Netzwerk-Administrator die Arbeit, weil er die umgesetzten Adressen bei seinen Analysen kennen und in Betracht ziehen muss.

Dem Nutzer des Endknotens erschwert es die Arbeit im Fehlerfall dadurch, dass er nicht weiß, an wen er sich wenden soll, beziehungsweise dadurch, dass er dem Mitarbeiter beim Support Adressen nennt, mit denen dieser nichts anfangen kann.

NAT wird nach verschiedenen Kriterien unterschieden. Ändern sich nur die IP-Adressen oder die Ports oder beides? Betrachte ich nur die Richtung, dann kann ich zwischen Source-NAT (SNAT) und Destination-NAT (DNAT) unterscheiden. Eine weitere Unterscheidung berücksichtigt, ob Adressen eineindeutig umgesetzt werden oder mehrere Adressen auf eine andere Adresse (Masquerading). Beim Masquerading macht es einen Unterschied, ob der gleiche Port bei verschiedenen Verbindungen desselben Netzknotens auf den selben oder einen anderen Port umgesetzt wird.

Insbesondere verhindert Masquerading die direkte Adressierbarkeit von Endgeräten. Während das in vielen Fällen gewünscht ist, weil zum Beispiel interne Rechner nicht direkt von extern angegriffen werden können, erschwert es die Arbeit mit Peer-to-Peer-Protokollen, zum Beispiel für VoIP oder Videotelefonie, die auf geringe Latenzen angewiesen sind.

In diesem Bereich haben sich daher verschiedene Verfahren etabliert, die sich mit dem Hole-Punching bei NAT-Boxen beschäftigen, dem automatischen Öffnen von Verbindungen zur direkten Kommunikation von zwei Rechnern, die sich beide hinter NAT-Boxen befinden. Diese Verfahren benötigen einen Rendezvous-Server, über den die Endgeräte die nötigen Informationen zum Partner bekommen und natürlich kooperierende NAT-Boxen.

Zwar könnten die beiden Endgeräte gleich über den Rendezvous-Server kommunizieren, anstelle sich mit den Eigenarten der beteiligten NAT-Boxen herumzuschlagen. Für die direkte Verbindung spricht jedoch zum einen die Latenz, die in den meisten Fällen kleiner ist als über die beiden Verbindungen zum Rendezvous-Server, der alle Datagramme umsetzen müsste. Außerdem ist es eine Frage der Vertraulichkeit, ob ich alle meine Daten über den Server schicken will, oder lieber direkt.

Ein weiteres Problem beim Hole-Punching stellt das Hair-Pinning dar, das auftritt, wenn zwei Rechner hinter derselben NAT-Box eine direkte Verbindung aufnehmen wollen. In diesem Fall teilt der Rendezvous-Server beiden Clients die gleiche NAT-Adresse mit und diese versuchen über die NAT-Box eine Verbindung in das private Netz zurück aufzubauen. Damit das funktioniert, muss es von der NAT-Box unterstützt werden. Sollten mehrere NAT-Boxen kaskadiert sein, muss zumindest die dem Rendezvous-Server zunächst gelegene NAT-Box Hair-Pinning unterstützen. RFC 2663, RFC 3022 und RFC 3303 gehen auf diese Aspekte ein.

Aus dem vorgenannten ist sicher zu erkennen, dass ich NAT eher für ein Übel als für einen Segen halte. Wenn es sich beim Entwurf des Netzes vermeiden lässt, würde ich auf jeden Fall darauf verzichten. Allgemein spricht nur die Knappheit der Adressen bei IPv4 für NAT. Konkret ist NAT notwendig, wenn zwei Netzbereiche mit überlappender Adressvergabe, zum Beispiel mit Adressen nach RFC 1918, verbunden werden sollen oder wenn ein Netzbereich mit Adressen nach RFC 1918 an das Internet angeschlossen werden soll.

Zwar gibt es einige, die den Standpunkt vertreten, dass NAT einen gewissen Schutz bietet, weil das Netz dahinter nicht von außen adressiert und somit das Netz auch ohne Firewall geschützt wäre. Doch kann NAT keine durchdachte und mit Hilfe einer Firewall durchgesetzte Policy ersetzen. Ist die Firewall einmal im Betrieb ist der zusätzliche Nutzen durch NAT nur noch marginal.

Demgegenüber steht die zusätzliche Rechenzeit, die für NAT aufgewendet werden muss. Setze ich NAT ein, muss der NAT-Router für jedes Datagramm das umgesetzt werden soll, in einer Tabelle nachschauen und die Adressen, Ports und Prüfsummen modifizieren. Ist die CPU des NAT-Routers nicht leistungsfähig genug, kann der mögliche Durchsatz erheblich sinken. In einem konkreten Fall hatte ich Unterschiede von mehr als 30 Prozent im maximalen Durchsatz mit und ohne NAT gemessen.