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
