DMZ-Subnetz: zu NAT oder nicht zu NAT?

Ich möchte eine DMZ hinter einem Cisco ASA einrichten, die eine große Anzahl von HTTP-Front-End-Load-Balancern und SSL-Offload-Diensten enthält - über 100 IPs, die sich auf eine kleinere Anzahl von Hosts konzentrieren.

In der Vergangenheit habe ich alle Hosts auf privaten RFC1918-IPs gespeichert und statische Zuordnungen (IP-by-IP) für jeden Dienst hinzugefügt, den ich normalerweise in einer DMZ verfügbar mache. Dies ist ärgerlich geworden, da wir damit begonnen haben, zusätzliche DMZ-IPs so schnell hinzuzufügen, dass es ärgerlich wird, jede einzeln einzurichten. Ich möchte es so ändern, dass ein gesamtes DMZ-Subnetz so eingerichtet wird, dass HTTP und HTTPS von außen -> dmz - zugelassen werden, sodass die Load Balancer bei Bedarf einfach neue IPs abrufen können, ohne die ASA-Konfiguration jedes Mal zu aktualisieren.

Was ich mich jetzt frage, ist, ob es sinnvoll ist, die DMZ in einem RFC1918-Subnetz zu haben und ein statisches NAT im gesamten Subnetz zu verwenden, oder ob ich die DMZ einfach meine Zuweisung externer IPs direkt lassen und mich ausschließlich darauf verlassen sollte Zugriffslisten und Identitäts-NAT / NAT-Ausnahme.

Einige grobe ASCII-Kunstwerke:

Beispiel für die Verwendung direkter externer IP-Adressen:
  Internet ---> ASA ---> Intern (10.1.0.0/16)
                  |
                  + -----> DMZ (1.2.3.0/24)

Beispiel für die Verwendung von NAT-IP-Adressen:
  Internet ---> ASA ---> Intern (10.1.0.0/16)
                  |
     (1.2.3.0/24) + -----> DMZ (10.99.0.0/24)

Der Vorteil, den ich bei der Verwendung der NAT-Adresse sehe, ist die Portabilität. Ich muss meine interne DMZ nicht neu nummerieren, wenn sich mein Upstream-Anbieter und meine Zuordnung ändern. Der Nachteil ist die Komplexität - jetzt muss ich mich mit internen und externen IP-Adressen in meinem eigenen Netzwerk usw. befassen. Welches Setup funktioniert Ihrer Erfahrung nach besser?

Es gibt Gründe, in beide Richtungen zu gehen, die Sie und andere erwähnt haben.

Eine Abstraktionsebene (eine Art Wortspiel) in Form von statischem 1: 1-NAT ist eine nette Sache, da Sie interne Hosts wahrscheinlich nicht neu nummerieren müssen, wenn sich Ihr WAN-IP-Block ändert. Die Komplexität und Nuancen, die NAT für den Paketfluss durch einen ASA einführt, können jedoch im Vergleich zu einfachen Routing- und ACL-Überprüfungen problematisch sein.

Mein persönlicher Standpunkt ist, dass NAT hier ist, um bei IPv4 zu bleiben. Für IPv4-Stacks auf Hosts habe ich keine Bedenken hinsichtlich statischer NAT-Funktion in der Upstream-Firewall. Für IPv6-Stacks auf Hosts jedoch kein NAT. Auf dem ASA können sowohl IPv4 als auch IPv6 nebeneinander ausgeführt werden, mit NAT für IPv4 und herkömmlichem Routing für IPv6.

Es gibt noch einen weiteren Grund, warum Sie sich für statisches NAT entscheiden sollten, und es befasst sich mit Wachstum. Der ASA unterstützt keine secondary IP-Adressen auf Schnittstellen . Angenommen, Ihr Upstream weist Ihnen eine / 26 zu, die direkt an die externe Schnittstelle Ihres ASA weitergeleitet wird. Sie konfigurieren die dmz-Schnittstelle Ihres ASA mit der ersten Host-IP im IP-Subnetz, sodass Sie 64 - 2 - 1 = 61 gültige Host-IPs im Subnetz haben, die von Ihren Servern verwendet werden können.

Wenn Sie alle 61 verbleibenden Host-IPs verwenden und mehr benötigen, gehen Sie zum Upstream und sagen, hey, ich brauche eine andere / 26. Sie geben es Ihnen und leiten es erneut direkt an die externe IP Ihres ASA weiter. Sie können die erste Host-IP im zweiten Block nicht secondarywie bei IOS der dmz-Schnittstelle Ihres ASA als IP-Adresse zuweisen . Dies lässt Ihnen einige Optionen -

• Erstellen Sie eine weitere Schnittstelle dmz2 auf dem ASA (nicht wünschenswert)
• Geben Sie die / 26 zurück, fragen Sie nach einer / 25 und nummerieren Sie sie intern neu (nicht wünschenswert).
• Führen Sie statisches NAT durch (was wir in diesem Beispiel ablehnen)

Nehmen Sie als nächstes dasselbe Paradigma - diesmal mit statischem 1: 1-NAT außerhalb von <-> dmz von Anfang an. Wir verwenden alle verfügbaren IPs in unseren ersten / 26 statischen 1: 1-NATs. Wir bitten um eine Sekunde / 26 -

• Sie können die Upstream-Route direkt an Ihre ASA außerhalb der IP-Schnittstelle direkt anfordern. Dadurch sparen Sie einige Adressen, da der Upstream keine Adresse im Block als secondaryIP-Adresse auf seinem Gerät zuweisen muss, um als Gateway verwendet zu werden du wirst es nicht brauchen. Beachten Sie, dass die meisten Anbieter die ersten 3 Host-IP-Adressen als Teil von VRRP / HSRP verwenden, um Ihre Nutzbarkeit zu reduzieren.
• Wenn Sie nicht direkt an den Block weiterleiten möchten, führt der Upstream normalerweise die zweite Hälfte der vorherigen Option aus. Die ASA-Proxy-ARPs (wie es wahrscheinlich bei Ihrem ersten Block der Fall ist, je nachdem, wie es eingerichtet ist) für lokal gelieferten Datenverkehr für die IPs in der Broadcast-Domäne, zu der die externe Schnittstelle gehört.

Lektion: Wenn Sie bereits einen öffentlichen IP-Block auf Ihrer externen Schnittstelle haben, fordern Sie immer an, dass nachfolgende Blöcke direkt an Ihre externe Schnittstellen-IP weitergeleitet werden. Dies gibt Ihnen zusätzliche verwendbare IPs und Sie können immer noch statisches NAT einwandfrei.

Egal, ob direkt geroutet oder ASA-Proxy-Arp - mit statischem 1: 1-NAT können Sie das zweite / 26 verwenden, ohne sich mit dem dmz-Subnetz herumschlagen zu müssen. Sobald Sie aus Ihrem dmz-Subnetz herausgewachsen sind, müssen Sie einige Anpassungen vornehmen - aber es gibt wieder eine Abstraktionsebene, und Sie müssen nicht auf der WAN-Seite herumspielen.

Endgültige Antwort: Es kommt darauf an, aber mit IPv4 neige ich in Ihrem Fall zu NAT.

Ich würde nicht NAT. Es gibt keinen wirklichen Wert dafür. Die lästige Arbeit beim Umnummerieren besteht nicht darin, Adressen hinzuzufügen / zu entfernen, sondern sich mit all dem Mist zu befassen, der sie umgibt, wie dem Übergang von DNS.