mobileMacs

Als Mitte der 90er Jahre der Zugang zum Netz populärer wurde, erdachten ein paar Linux-Hacker eine pfiffige Lösung, um mehreren Computer mit nur einer IP-Adresse Zugang zum Internet zu geben: Network Address Translation wurde dann schnell zum Gold-Standard für Heim und Büro. Entsprechend unterstützen heutzutage alle Router NAT.

Funktionsweise

NAT funktioniert nach einem einfachen Prinzip: im eigenen Netzwerk verwendet man einen von drei reservierten privaten IP-Adressbereichen (10/8, 172.16/12, and 192.168/16). Ein Router (oder Gateway, wie man möchte) in diesem Netzwerk übernimmt nun die Funktion der Weiterleitung der Pakete, die für Hosts im Internet gedacht sind. Üblicherweise, aber nicht notwendigerweise, ist dieser Router auch für die Adressvergabe via DHCP und eben auch für die Netzwerk-Adressumsetzung (NAT) zuständig.

Ein Rechner im privaten Netzwerk schickt nun also seine Internet-Pakete über diesen Router. Die Absendeadresse dieser Pakete enthält dementsprechend eine Adresse aus den oben erwähnten Netzen. Diese sind aber im Internet nicht routingfähig, da sie eben nicht für Internet-Hosts vergeben werden dürfen. Der NAT-Router ersetzt nun also diese Absendeadressen durch die vom ISP (meist via PPP oder PPPoE) zugeteilte öffentliche Adresse und merkt sich zudem in einer Tabelle, dass hier demnächst mit einer Antwort zu rechnen ist. Dazu vermerkt der NAT-Router zusätzlich noch den Port, von dem aus das Paket geschickt wurde (das identifiziert die sendende Applikation) und wartet ab. Das ausgehende Paket hat nun einen gänzlich neuen Port verpasst bekommen, an dem man den Tabelleneintrag identifizieren kan

Kurze Zeit später kommt die Antwort und anhand des Zielports findet der NAT-Router den Eintrag in der Tabelle. Dort steht die eigentliche Zieladresse aus dem privaten Netzwerk nebst dem ursprünglich als Absender verwendeten Port. Diese beiden Werte werden nun wieder ersetzt und das Paket wird auf dem internen Netzwerk entsprechend versendet. Der Rechner erhält wie gewünscht seine Daten aus dem Internet ohne von dem doppelten Datentausch etwas mitzubekommen. Deswegen muss die Software für NAT nicht angepasst werden, was für den Durchbruch von NAT ganz wichtig war.

Überläufer

So weit, so gut. Doch gibt es hier einige kleine Probleme, die häufig nicht bedacht werden und bei frühen NAT-Implementierungen ein Problem waren. Das betrifft vor allem die oben bereits angesprochene Umsetztabelle.

Ist die Internetaktivität im privaten Netz sehr groß, senden also viele unterschiedliche Hosts und Programme Daten, dann kann das dazu führen, dass die Tabelle des Routers zu groß wird und neue Verbindungen nicht mehr gespeichert werden können. Da Router nicht selten recht kleine Embedded-Systeme mit wenig RAM sind, wurde dies anfangs nicht immer bedacht. Können keine Einträge mehr vorgenommen werden, werden auch die Antwortpakete nicht mehr zugeordnet und die Anfragen erhalten keine Rückmeldungen mehr: Programme warten auf ihre Daten, erhalten aber keine. Die Verbindungen frieren ein, obwohl der Internetzugang eigentlich wunderbar funktioniert.

Dabei können die Symptome schwanken, je nach dem, wie der Router mit solchen Überläufen umgeht. Neuen Verbindungen wird unter Umständen Vorrang gegeben, da alte Verbindungen ggf. nicht mehr aufgenommen werden und der Eintrag als nicht mehr notwendig betrachtet wird. Bei sehr hohem Datenaufkommen kann aber auch der älteste Eintrag noch recht neu sein und so kommt keine einzige Verbindung mehr zustande, da alle neueren Verbindungen die eben noch gestarteten überlagern und selber wieder von ihren Nachfolgern überschrieben werden. In diesem Fall geht überhaupt nichts mehr, obwohl der Router brav alle Pakete nach außen schickt und auch alle Antworten zurückkommen. Ein totales Desaster.

Die Strategie, alte Einträge bei Nichtaktivität herauszuwerfen ist aber auch sonst eine schlechte Idee, denn es gibt durchaus viele Verbindungen, die lange brachliegen, aber mit guten Grund. Ein gutes Beispiel sind SSH-Sessions. Hier loggt man sich auf einem Rechner ein und startet auf der Kommandozeile irgendein Programm, dass ein paar Stunden benötigt (ein Übersetzungsvorgang, eine Berechnung , ein Batchprozess oder was auch immer). Erst nach Ablauf meldet sich das Programm wieder. Wenn der NAT-Router wegen Nichtaktivität den Eintrag aus der Tabelle geworfen hat, brechen die Verbindungen ab. Das Ergebnis geht verloren. Im Falle von SSH kann man sich wehren, indem man seine SSH-Verbindung entsprechend mit ServerAlive konfiguriert. Aber es gibt auch andere Beispiele, wo zu kurze Timeouts stören (Chats, Datenbankverbindungen und ähnliches).

Inkontinenzen

Ein Nebeneffekt von NAT ist, dass Verbindungen von außen in der Regel blockiert werden. Das schafft einen bestimmten Sicherheitspuffer, doch sollte man NAT nicht als Sicherheitstechnologie begreifen. Schon das Beispiel mit der Tabelle oben zeigt, dass diverse Klimmzüge nötig sind, um NAT wirklich durchlässig genug zu machen und diese Durchlässigkeit ist by design bidirektional. Das bietet auch viel Raum für Sicherheitslöcher und daher sollte man bei besonders schützenswerten Infrastrukturen schon auch Gedanken um eine zusätzliche Firewall machen.

NAT orientiert sich sehr am klassischen Client/Server-Ansatz und geht vor allem davon aus, dass das private Netzwerk vor allem Clients betreibt. Das mag häufig der Fall sein, doch gibt es zunehmend den Bedarf, auch von zu Hause Serverdienste anzubieten (Fernzugriff via SSH oder Apple Remote Desktop, File Server, Web Server etc.) und komplexe Protokolle für Internettelefonie, Chat-Dateitransfer oder BitTorrent benötigen möglichst dynamische, bidirektionale Kommunikation. NAT ist nicht für P2P gemacht und daher sind hier weitere Maßnahmen nötig. In einem Folgeartikel werde ich auch auf NAT Traversal eingehen, dass diese Probleme addressiert.

Richtig schlimm wird es mit NAT, wenn Protokolle Informationen über Absendeadresse und Absenderport direkt im Protkoll unterbringen. Dies ist der Fall bei FTP, SIP und vielen anderen Protokollen, die eigentlich für den Betrieb im NAT-freien Internet gemacht sind. Vor allem Telefonie-Protokolle sind hier betroffen. NAT-Implementierungen müssen aktiv in den Protokollstrom eingreifen und tauschen Informationen in der Payload der Datenpakete, um die Protokolle überhaupt zum Laufen zu bringen. Dies mag auf den ersten Blick elegant klingen, greift aber nicht bei verschlüsselter Kommunikation bzw. verhindert diese und ist in bestimmten Situation technisch sogar nicht möglich bzw. nicht zuverlässig.

Manche Probleme entstehen auch erst, wenn mehrere NATs hintereinander geschaltet werden. Das passiert schnell, z.b. wenn man in einem mit NAT arbeitenden WLAN via Internet Sharing einem anderen Rechner via Ethernet oder Firewire Internetzugang spendet. Dann arbeitet ein zweites NAT auf dem eigenen Rechner und setzt die Adressen bereits einmal um, damit sie danach von dem WLAN-NAT noch ein weiteres Mal umgesetzt zu werden. Das funktioniert zwar, aber schafft neue Probleme für Traversal-Protokolle, denn selten verhalten sich zwei NAT-Implementierungen identisch.

Port Mapping

Nahezu alle Router (einschliesslich der AirPort-Modelle) bieten heute die Möglichkeit, ein sogenanntes “Port Mapping” einzustellen. Das erlaubt, Dienste auf einem Rechner hinter dem NAT anzubieten und die Anfragen aus dem Internet durch eine fest eingestellte Zuordnung auf diesen Rechner weiterzuleiten. Das funktioniert so weit ganz gut und straigtforward. Allerdings unterliegt man hier einigen Einschränkungen, da der Rechner dann seine IP-Adresse nicht mehr ändern darf. Das Netzwerk-Kontrollfeld bietet da mit der Einstellung “DHCP mit manueller Adresse” die nötige Voraussetzung, so dass man alle anderen Werte auch noch dynamisch beziehen kann. Bei den AirPort-Modellen ist das Port Mapping leicht über das AirPort Utility einzustellen.

Mehr Informationen zu NAT und wie man es so umbiegen kann, dass man damit glücklich wird, im nächsten Teil der Serie.