Warum verwenden nicht mehr Organisationen Inside-to-Inside-NAT oder ähnliche Lösungen, um NAT-Haarnadeln zuzulassen?

Inside-to-Inside-NAT (auch NAT-Loopback genannt) behebt Haarnadel-NAT-Probleme beim Zugriff auf einen Webserver über die externe Schnittstelle eines ASA oder eines ähnlichen Geräts von Computern über die interne Schnittstelle. Dadurch wird verhindert, dass DNS-Administratoren eine doppelte interne DNS-Zone mit den entsprechenden RFC1918-Adressen für ihre Server verwalten müssen, die mit öffentlichen Adressen NATted sind. Ich bin kein Netzwerktechniker, daher fehlt mir möglicherweise etwas, aber es scheint ein Kinderspiel zu sein, dies zu konfigurieren und zu implementieren. Asymmetrisches Routing kann ein Problem sein, kann jedoch leicht gemildert werden.

Nach meiner Erfahrung bevorzugen Netzwerkadministratoren / -ingenieure, dass Systemleute nur Split-DNS ausführen, anstatt ihre Firewalls so zu konfigurieren, dass sie mit NAT-Haarnadeln richtig umgehen. Warum ist das?

Es gibt einige Gründe, warum ich es nicht tun würde:

• Warum sollten Sie die DMZ-Router und die Firewall besonders belasten, wenn dies nicht erforderlich ist? Die meisten unserer internen Dienste befinden sich nicht in der DMZ, sondern im allgemeinen Unternehmensbereich, mit Vertretungsdiensten in der DMZ für gelegentlichen Fernzugriff. Wenn Sie nat von innen nach innen ausführen, wird die DMZ stärker belastet, was in unserem Fall erheblich wäre.
• Wenn Sie DNAT + SNAT nicht ausführen, erhalten Sie asymettrisches Routing, dessen Richtigkeit bekanntermaßen schwierig ist. Sie SNAT also und verlieren die Quell-IP-Informationen. Es ist jedoch verdammt nützlich, Quell-IPs zu Zwecken der Fehlerbehebung mit Personen zu verknüpfen. Oder gelegentlich zu Nerfshooting-Zwecken bei Dummheit. "Hey, diese IP macht etwas Wackeliges auf nicht authentifiziertem Dienst X"

Natürlich kann es keine eindeutige Antwort darauf geben, aber ich könnte mir eine Reihe von Gründen vorstellen:

1. Eleganz: NAT ist anfangs nicht sehr elegant, aber aufgrund des eingeschränkten Adressraums von IPv4 eine Notwendigkeit. Wenn ich NAT vermeiden kann, werde ich es tun. Mit IPv6 ist das Problem auf jeden Fall behoben.
2. Komplexität: Insbesondere in Fällen, in denen nicht nur ein einziger "Core" -Router alle Sicherheitsgrenzen festlegt, können die Filterkonfigurationen sehr schwierig werden. Entweder das, oder Sie müssten die NAT-Regeln auf nahezu alle Router-Geräte verteilen und verwalten.
3. Hinweis: Überall dort, wo sich Firewall-Administratoren vom Rest des Server-Administratorteams unterscheiden, sind sie möglicherweise schwer zu erreichen. Um sicherzustellen, dass Änderungen nicht durch den Rückstand (oder die Abwesenheiten) des Firewall-Administrators verzögert werden, wird die Option ausgewählt, die Verantwortung im selben Team zu behalten
4. Portabilität und gängige Praxis: Die Verwendung von DNS-Ansichten ist "genau das, was jeder weiß", um dieses Problem zu lösen. Nicht jeder Boundary-Router würde Loopback-NAT auf einfache Weise unterstützen, und weniger Menschen wissen wahrscheinlich, wie sie es in Ihrer spezifischen Umgebung richtig einrichten. Bei der Behebung von Netzwerkproblemen müsste die Besatzung die NAT-Haarnadelkonfiguration und alle ihre Auswirkungen kennen - selbst wenn sie einem scheinbar nicht damit zusammenhängenden Problem nachjagt

Haftungsausschluss - Dies ist eine Antwort von Flamebait.

Ein häufiger Grund, aus dem ich denke, dass Lösungen wie diese vermieden werden, ist eine irrationale Angst / ein irrationaler Hass der Netzwerkingenieure vor NAT . Wenn Sie einige Diskussionsbeispiele dazu sehen möchten, sehen Sie sich diese an:

• http://packetpushers.net/show-86-connect-to-the-ipv6-internet-for-free-using-tunnelbroker-net/
• http://networkingnerd.net/2012/04/02/ipv6-nat-and-the-sme-a-response/ (Toms Blog scheint immer wieder heftige NAT / IPv6-Diskussionen anzulocken)
• http://libertysys.com.au/blog/nat-is-evil-but-not-bad (mein Blog)

Nach allem, was ich sagen kann, ist ein Großteil dieser Befürchtung auf die schlechten NAT-Implementierungen von Cisco zurückzuführen (in diesem Sinne ist dies möglicherweise nicht irrational), aber meiner Meinung nach ist der "klassische" Netzwerktechniker im Bereich NAT so gut ausgebildet schlechte "Weltanschauung, dass er oder sie offensichtliche Beispiele wie dieses nicht sehen kann, in denen es vollkommen sinnvoll ist und die Lösung tatsächlich vereinfacht.

Los geht's - stimmen Sie nach Herzenslust ab! :-)

Meine Vermutung ist:

1. Split DNS ist einfacher zu verstehen.
2. NAT Hairpin verbraucht Ressourcen auf dem Router, Split-DNS hingegen nicht.
3. Router haben möglicherweise Bandbreitenbeschränkungen, die Sie nicht durch ein Split-DNS-Setup erhalten.
4. Split-DNS ist immer leistungsfähiger, da Sie Routing- / NAT-Schritte vermeiden.

Auf der positiven Seite für Haarnadel NAT,

• Sobald es eingerichtet ist, funktioniert es einfach.
• Keine Probleme mit DNS-Caches für Laptops, die zwischen dem Arbeitsnetzwerk und dem öffentlichen Internet verschoben wurden.
• DNS für einen Server wird nur an einem Ort verwaltet.

Für ein kleines Netzwerk mit geringen Anforderungen an den Datenverkehr zu einem internen Server würde ich Haarnadel-NAT wählen. Für ein größeres Netzwerk mit vielen Verbindungen zum Server und wenn Bandbreite und Latenz wichtig sind, wählen Sie Split-DNS.

Aus meiner Sicht hat sich dies zwischen dem Übergang von Cisco Pix zu ASA ein wenig geändert. Verlor den aliasBefehl. Im Allgemeinen erfordert der Zugriff auf die externe Adresse über die interne Schnittstelle einer Cisco-Firewall einige Tricks. Siehe: Wie erreiche ich meinen internen Server über die externe IP?

Wir müssen jedoch nicht immer eine doppelte interne DNS-Zone verwalten. Der Cisco ASA kann DNS-Abfragen für externe Adressen an interne Adressen umleiten, wenn dies in der NAT-Anweisung konfiguriert ist. Ich bevorzuge es jedoch, eine interne Zone für die öffentliche DNS-Zone beizubehalten, um diese Granularität zu erreichen und dies an einem Ort zu verwalten, anstatt auf die Firewall zuzugreifen.

Normalerweise gibt es nur wenige Server, die dies in einer Umgebung erfordern (E-Mail, Web, einige öffentliche Dienste), sodass dies kein großes Problem darstellt.

Ich kann mir ein paar Gründe vorstellen:

1. Viele Organisationen haben DNS bereits aufgeteilt, weil sie nicht alle ihre internen DNS-Informationen in der Welt veröffentlichen möchten. Daher ist es nicht sehr aufwändig, die wenigen Server zu verwalten, die auch über eine öffentliche IP zugänglich sind.
2. Wenn ein Unternehmen und sein Netzwerk größer werden, trennen sie häufig die Systeme, die interne Mitarbeiter bedienen, von den Servern, die externe Mitarbeiter bedienen. Das Weiterleiten an externe Mitarbeiter zur internen Verwendung kann daher einen viel längeren Netzwerkpfad bedeuten.
3. Je weniger Änderungen zwischengeschaltete Geräte an Paketen vornehmen, desto besser sind Latenz, Reaktionszeit, Gerätelast und Fehlerbehebung.
4. (zugegebenermaßen sehr geringfügig) Es gibt Protokolle, bei denen NAT immer noch nicht funktioniert, wenn das NAT-Gerät nicht über die Header des Pakets hinausgeht und die darin enthaltenen Daten mit den neuen IP-Adressen ändert. Auch wenn es sich nur um ein institutionelles Gedächtnis handelt, ist es dennoch ein wichtiger Grund für die Menschen, es zu vermeiden, insbesondere wenn sie sich mit einem Protokoll befassen, bei dem sie sich nicht hundertprozentig sicher sind.

Wenn ich NAT-Loopback verwenden würde, wäre ich etwas besorgt darüber, wie das NAT-Gerät mit gefälschten Quelladressen umgehen wird. Wenn nicht überprüft wird, an welcher Schnittstelle das Paket eingegangen ist, kann ich interne Adressen aus dem WAN fälschen und Pakete mit internen Adressen an den Server senden. Ich konnte keine Antworten erhalten, kann den Server jedoch unter Verwendung einer internen Adresse gefährden.

Ich würde NAT-Loopback einrichten, den DMZ-Switch anschließen und Pakete mit gefälschten internen Quelladressen senden. Überprüfen Sie das Serverprotokoll, um festzustellen, ob sie empfangen wurden. Dann würde ich zum Coffee Shop gehen und sehen, ob mein ISP gefälschte Adressen blockiert. Wenn ich feststellen würde, dass mein NAT-Router die Quellschnittstelle nicht überprüft, würde ich wahrscheinlich keinen NAT-Loopback verwenden, selbst wenn mein ISP dies überprüft.