NAT oder !NAT bei IPv6

Die ganze Diskussion um das für und wieder von NAT ist nichts Neues. „Damals“ wurde NAT benötigt um den raschen Aufbrauch von IPv4 Adressen Einhalt zu gebieten. Aber die Problemlawine die damit losgetreten wurde, konnte zu der Zeit noch keiner erahnen. NAT hat rein gar nichts mit Sicherheit zu tun. Auch wenn es einige immer wieder als Sicherheitsfunktion anführen. Es war, ist und bleibt eine Krücke, die jedem Admin das Leben schwer macht.

Das häufigste Argument für NAT ist die angebliche Sicherheit. Egal wie oft dies einige Hersteller als Sicherheits-Feature gebetsmühlenartig immer wieder anpreisen, gibt es nur eine Antwort. Die kurze und eindeutige Antwort auf die Frage, ob NAT ein Security-Feature ist, ein ganz klares NEIN! Dazu braucht man sich nur mal vor Augen zu führen, was NAT wirklich macht. Es tauscht lediglich die Quell-IP aus. In dem Moment, in dem ein Host sich über NAT mit einem anderen System verbindet, ist er voll erreichbar. An dieser Tatsache ändert NAT rein gar nichts.

Das NAT bei IPv4 benötigt wird ist jedem klar, es ist auch gut zu wissen, dass man es nun auch unter IPv6 verwenden könnte. Aber will man dies wirklich und auf echte Ende-zu-Ende Verbindungen verzichten? Ein einfaches Beispiel sind eigene Services. Jeder der diese anbietet kennt den Konfigurationsaufwand bei den Firewall-Richtlinien, Forwards und NAT-Regeln. Dazu kommen noch die Split-DNS Zonen die ebenfalls verwaltet werden müssen. Hier ist es dann abhängig, von welcher Seite ein DNS wie antwortet, damit es aus dem LAN und von extern überhaupt möglich ist, das System in der DMZ zu erreichen.

Hat man dazu noch viele Dienste die https nutzen, dann gehen einem sehr schnell die offiziellen IPv4 Adressen aus. Ob OWA oder Outlook-Anywhere, Citrix, Intranet, Portale, Shop- oder andere Bestellsysteme. Alle nutzen https und brauchen jeweils eine IP. Jeder der solche Systeme administriert kennt den Aufwand eine technisch saubere Lösung zu implementieren. Administratoren die für VPN-Verbindungen verantwortlich sind, haben ebenfalls mit NAT ihre Probleme. Besonders dann, wenn es darum geht IPsec Clients anzubinden. Hier gab und gibt es die diversesten Lösungen. Aber diese sind in dem meisten Fällen herstellerspezifisch und alles nur um die Probleme die durch NAT entstehen irgendwie zu kompensieren.

Diese ganzen Probleme war auch der Grund dafür, dass es für IPv6 kein NAT geben sollte. Es kommt zwar immer mal anders als gedacht, aber nur weil es da ist, muss man es ja auch nicht verwenden. Vor allem dann, wenn man aus den ganzen Problemen unter IPv4 seine Lehren gezogen hat. Man sollte auch nie nie sagen, es wird sicherlich in der einen oder andere Konstellation einen sehr guten Grund für NAT geben, nur sollte es vermieden werden wo es nur geht.

Ein häufiges Argument, was immer von den NAT-Befürwortern angeführt wird, ist, dass man so die internen Strukturen verstecken kann. Aber all diejenigen haben sich wahrscheinlich noch nie ihren eigenen Mail-Header angesehen, wo sie schon seit Jahren ihre internen IP und Domänen aller Welt mitteilen. Bei den Infos in einem Mail-Header ist die IP Adresse wohl das geringste Problem.