1:1 NAT vs. Subnetting
-
Hallo zusammen,
ich bin gerade dabei die Firewall und den damit verbundenen Netzaufbau neu zu planen. Die Ausgangslage sieht aktuell wie folgt aus, dass wir ein /24er Netz von unserem Provider auf die WAN Adresse der Firewall geroutet bekommen. In der Firewall gibt es letztlich diverse DMZ's für die jeweiligen Kunden sowie eigene Netze fürs Management, interne Systeme und so weiter. Mein Vorgänger der das System betreut und initial eingerichtet hatte, hat letztlich komplett mit 1:1 NAT und privaten IP-Adressen gearbeitet. Jetzt bin ich allerdings hin und her gerissen, ob ich das Konzept mit 1:1 NAT und privaten IP-Adressen beibehalten soll oder das /24er Netz in diverse Subnetze für die DMZ's unterteilen soll und die Server Public IP's bekommen. Die anderen Netze, bei denen die Server nicht von außen erreichbar sein müssen, würde natürlich weiterhin private IP's bekommen.
Beide Varianten haben Ihre Vor- und Nachteile. Allerdings gerade die NAT Reflaction bzw. Split DNS finde ich nicht gerade ansprechend. Daher mal die frage in die Runde wie ihr das bei eueren DMZ's so handhabt.
Viele Grüße
-
Ahoi,
weshalb Split DNS? Das ist nur notwendig wenn du keine NAT Reflection nutzen kannst. Ansonsten funktioniert die Reflection gut, bislang waren alle damit verbundenen Probleme lediglich falsche Regelsätze.
Ich hatte diese Antipathie gegen 1:1 NAT auch, allerdings ist unser aktuelles Setup auch so aufgesetzt und konnte auch nicht geändert werden, so dass ich mich durchbeißen musste. Es hat letztendlich mehr Vorteile als Nachteile. Wenn du intern nicht darauf angewiesen bist, dass bspw. Entwickler auf die DMZs zugreifen müssen, ist NAT Reflection kaum notwendig. Ansonsten funktioniert sie wie gesagt auch so ganz gut.Letztendlich wird das Problem sein, dass du nur das /24er Netz hast (was viel sein mag oder auch nicht, kommt auf dich an). Der nächste Punkt ist, dass in solch einem Setup die Firewall redundant sein sollte. Am Besten macht sich da ein CARP Setup. Das führt aber dazu, dass du allein für das CARP Setup in jedem Netz was du auflegst DREI IPs brauchst, nur für die Firewall (mit pfSense 2.2 soll sich das Dank CARP Verbesserungen ändern, dann ist es nur noch eine). Das heißt, wenn du dich in die Subnetting Hölle begiebst, wirfst du grundsätzlich für jeden Kunden, der einen kleinen Teil davon geroutet bekommt, schonmal mindestens 3-5 IPs weg (2 wegen Subnetting, 1 wegen VIP / FW, 2 ggf. wegen CARP IPs der einzelnen Geräte). Von deinen 255 IPs wird das dann ganz flott abwärts gehen.
Dazu kommt, dass - so du für deine Kunden die Netze planst - es dann auch mal sein kann, dass du IPs verschenkst (Kunde könnte 3 IPs haben im /29er, nutzt aber nur eine) oder einen Kunden hast, der plötzlich mehr braucht und du das Netz größer fassen müsstest. Nur das geht nicht mehr, dann das nächste kleine Subnetz ist schon vergeben.
Wenn du also kein richtig großes IP Segment hast, in dem du Subnetten kannst, würde ich dir raten es sein zu lassen. Das wird nochmal ganz anders mit IPv6 (klar) oder wenn ihr bspw. selbst RIPE Member wärt (dann bekommst du Zuordnungen von /22 oder größer), aber mit einem /24er wirst du dich beim Kleinsägen nur ständig ärgern, es sei denn du kannst garantieren dass du die Netzgrößen genau kennst und diese auch nie wachsen werden (eher unwahrscheinlich).
Grüße
-
Hey,
besten Dank schon mal für deine Einschätzung. Das mit dem Verschnitt hat mich bisher ebenfalls stark gestört, da ich bereits jetzt schon CARP einsetze und somit 5 IP's jedes mal weg fallen würden. Interessant aber das mit Version 2.2 es da eine Änderung geben soll. Ich war mir bisher allerdings immer unsicher, ob dieses 1:1 NAT gerade beim Einsatz von DMZ's gängige Praxis ist oder ich hier doch eher in meiner eigenen kleinen Welt lebe :). Den bisher wurde ich immer schief angeschaut, wenn ich Kunden die private IP ihres Servers mitgeteilt habe und das ich 1:1 NAT verwende.
Leider habe ich in der Firma keinen mit dem ich mich über solche Themen austauschen kann, um mal eine andere Sichtweiße oder Einblick zu bekommen. Aber dafür gibt es ja das Forum :)
-
Da wir in unserem Setup meist nicht nur einen Server des Kunden, sondern mehrere betreuen, schaut hier auch niemand seltsam, wenn der Server eine private IP hat, da wir meistens entweder SSL-VPN anbieten oder VPN-Tunnel zum Kunden aufbauen, damit dieser auf sein Projektsetup zugreifen kann. Da dieses in einem separaten VLAN mit eigenem Netz untergebracht wird, haben alle Kisten dort private IPs. Wir gehen hier noch einen Schritt weiter und Knoten auf den Server des Kunden extra IPs für den notwendigen Service (so er Sichtbarkeit ins Netz hat) so dass bspw. der Server selbst auf .10 hört und arbeitet (SSH), der Webserver aber bspw. auf die .11 und aufsteigend. Damit lässt sich via 1:1 NAT dann gezielt nur der Webserver bspw. nach außen öffnen und selbst wenn jemand die Regeln auf der Firewall versauen würde (alle Ports statt 80,443) würde auf Serverseite nur der Webserver antworten, weil nichts anderes auf der Maschine bspw. auf die .11 hört (natürlich muss dann auch SSH und bspw. NTP beigebracht werden, da nicht drauf zu hören und sich mal kurz auf alles zu binden).
Ein weiterer Vorteil für den Kunden ist, dass er bspw. bei einem Serverupdate hergehen kann (wenn ers beauftragt und zahlt ;)) und die neue Kiste soweit vorbereitet wird (auf der internen IP) und dann kann man für den Livegang einfach die NAT Target IP ändern -> done. Kein unnötiges IP runterfahren auf Server1 und draufbinden auf Server2. Oder man zieht die externe IP via 1:1 NAT auf einen Loadbalancer - oder nutzt bspw. das HAProxy Package - um das Setup zu erweitern. Auch dafür muss am Endsystem dann überhaupt nichts geändert werden.
Natürlich kann man das auch geroutet und mit 2 oder 3 Interfaces lösen wobei ich hier schon oft Server gesehen habe, die dann trotzdem Dienste hatten, die eigentlich intern bleiben sollten, aber dank "BIND ALL" dann trotzdem auf der externen IP erreichbar waren. Sicher steht dann noch die Firewall dazwischen, aber wenn gar nicht erst was drauf hört, ist das immer sinnvoller.
Und zum Thema "sicherer", wenn Server wie DB bspw. dann komplett getrennt stehen: Meist ist es nicht der DB Server der "gehackt" oder übernommen wird, sondern das Frontend. Und da die Server auf die DB kommen sollen, können Sie dann auch weiterspringen (es sei denn man baut es wirklich extrem mit einer zweiten Firewallschicht auch intern).
Für große Provider à la 1&1 und Co. ist es eben einfacher die Server einfach mit externer IP auszurollen (da mietet man meist eh keine Firewall dazu) und die Absicherung der Server von-/gegeneinander dann über VLANs und Port-Security auf den Switchen zu erledigen. Aber gerade speziellere Hosting-Partner die nicht einfach "nur" dedizierte Server anbieten, sondern managed Services/Hosting/Firewall setzen das oft anders auf, um es im Sinne des Kunden besser wart- und konfigurierbar zu haben und ggf. eben auch gut erweitern zu können.
Just my 0.02c (die eher zu 2€ geworden sind ;))
Grüße