Firewall Passthrough NATing einrichten

[KeinNickFrei]

Hi,
ich bin im Themen Firewall/Netzwerk/Linux nicht so ganz tief drin.

Folgendes: Ein Mailserver soll auf eine andere IP umgestellt werden. Eigentlich kein Problem.
Ich möchte die neue IP bereits erreichbar machen, aber erstmal auf die aktuelle IP durchleiten. Sollte also quasi ein "transparentes NAT" sein, wenn ich das richtig verstehe.
Die beiden IPs sind in unterschiedlichen Netzwerken, sei angemerkt

10.1.1.10 / 16 --> Alte IP, existierender Mailserver
10.4.1.10 / 24 --> Neue IP, die er bekommen soll

Ich stelle mir das so vor, dass ich einfach einen Debian (kann ich am ehesten) vServer aufsetze, ihm die designierte neue IP gebe und via iptables alle Ports und Protokolle 1:1 an die aktuelle, alte IP weiterleite.
Der Mailserver soll von dem Zwischenschritt nichts mitbekommen sondern die Anfragen von der Quelle direkt bekommen.

Ist der Begriff "transparentes NAT" hier korrekt ?
und geht das einfach so? die Befehle wären hilfreich oder ein Link für ein kleines How-To...

Bin mir sicher, dass das eine Kleinigkeit ist, wenn man die richtigen Befehle eingibt...

Danke!

 

[riversource]

Das ist ein XY Problem. Was auch immer du erreichen willst, so wird es nichts. Die Frage ist, was ist das Ziel?

 

[blöderidiot]

Was Du willst ist möglicherweise nicht NAT sondern "port forwarding"?

 

[KeinNickFrei]

XY Problem?

Der Mailserver muss von extern erreichbar erreichbar sein - diese Änderung muss ein Dienstleister für mich machen.
Ich möchte zum einen die IP des Mailservers umstellen (in eben ein anderes VLAN) und auch einen Reverse-Proxy davor hängen.
Um das ganze in einzelne Steps zu unterteilen, wollte ich dieses Forwarding davor hängen, sodass ich dem Dienstleister schon die Umstellung machen lassen kann und im Hintergrund noch die alte IP behalten

Oder andersrum die interne IP ändern und dem temporären Routing kurzerhand die alte IP verpassen.

Was den Reverse Proxy betrifft hab ich so auch die Möglichkeit mir mit einem "Verteiler" zu helfen

Leider ist die SLA beim Dienstleister nicht sonderlich hoch. Ich bastle gerne abends noch, aber der DL stellt mir da nichts mehr um, wenn was nicht geht

Als "Port Forwarding" hätte ich es nur bezeichnet, wenn einzelne Ports weitergeleitet werden.

Aber in dem Fall möchte ich 1:1 alle Ports, alle Protokolle (TCP, UDP, ICMP) weitergeleitet haben.
Wobei im Grunde natürlich nur die von extern weitergeleiteten Ports verwendet werden (HTTPS (OWA, ActiveSync), SMTP, div. Mailprotokolle...)

Ich wollte das nicht so ausführlich beschreiben, da mir ja klar ist, was ich will, nur eben nicht, wie ich das mit der Konfig erreiche.
Ist natürlich möglich, dass das nicht ganz klappt, wobei die Anfragen ja nur von extern kommen und synchron beantwortet werden sollen vom Server.

Begriffe verwechsle ich leider oft....

Update:
Reverse Proxy wird mit Apache dann gemacht:
https://www.frankysweb.de/apache-als-reverse-proxy-fuer-exchange-server-teil-1/

 

[riversource]

Kein Mensch würde das so machen. Spätestens wenn die reale Umstellung ansteht, hast du ja lange Ausfallzeiten, da die IP ja schon in Benutzung ist und du alles umstellen musst, während die Daten über den Server laufen. Das Vorgehen ist äußerst riskant, da du keinerlei Möglichkeit hast, es vorher zu testen. Das System ist aktiv, bevor es fertig ist.

Setze den Server frisch auf mit dem Proxy davor und migriere die Konten. Am Tag X wird dann nur die Firewall auf die neue IP gesetzt. Da ja eh alles private IPs sind, muss es ja schon ein NAT geben, die Umstellung erfolgt also nahtlos. Vorher hast du alle Möglichkeiten, es in Ruhe zu testen.

XY Problem ist ein guter Suchbegriff, und dies ist ein Paradebeispiel dafür.

 

[Mojo1987]

Der Reverse Proxy bringt dir für den Mailversand/Empfang ohnehin nichts, der ist auschließlich für die Webbasierten Teile da.

Da es um Exchange geht ist der ja sicher auch Teil einer AD, die mags nicht besonders wenn man einfach die IP des Exchange-Servers ändert, der interne DNS und ggf zugehörige (interne) Zertifikate sind da nicht so ein Fan von der Nummer.

Ich stimme da riversource zu, gerade bei einem Exchange würde ich das so nicht machen sondern einen zweiten aufsetzen und sauber migrieren.

 

[KeinNickFrei]

Die IP kann ich flexibel wählen. Im ersten Lauf ja zb. eine andere. Da sehe ich jetzt kein Problem. Vielleicht hab ich ja ein Brett vor dem Kopf - danke für den Hinweis

Abgesehen vom Risiko, ist eine solche Umleitung mit iptables nun möglich oder nicht?

Den Mailserver werde ich definitiv NICHT frisch aufsetzen. Die IP Umstellung ist kein Risiko, das ist ein einzelner Reboot, da intern alles über DNS läuft.

Im Grunde könnte ich dem DL sagen, bitte stell mir das an der Firewall auf die neue IP um und sobald ich das Go bekomme, ändere ich die IP am Mailserver und starte neu - das wäre die Umstellung.
Hab ich auch schon so gemacht

Nur leider ohne dass ich dazwischen was testen kann.

Ergänzung (26. April 2023)

Ja, der Reverse Proxy ist NUR für OWA / Active Sync
NICHT für Mailempfang und Senden - das läuft über eine andere IP. Das weiß ich

Und die IP Umstellung ist kein Problem. Garantiert. Hab ich schon so gemacht und hab ich auch schriftlich von einem Exchange Profi.

 

[riversource]

Du willst doch den Proxy davor hängen, und das ist eine signifikannte Umstellung. Und wenn du die VLANs wechseln willst, dann ist das auch mehr, als nur eine Änderung der IP. Die Clients werden den Server ja dann nicht mehr direkt erreichen können, denn wofür sollte man sonst das VLAN ändern? Wenn es eh ein Routing zwischen ddn Netzen gibt, kann man sich das auch direkt sparen. Für die Weiterleitung jetzt bräuchtest du ja einen zusätzlichdn Rechner, auch das hat nichts mit dem Ziel-Setup zu tun. Für mich macht die Herangehensweise noch so überhaupt keinen Sinn.

 

[KeinNickFrei]

Ich werde die IP (und damit das VLAN) ändern. Die alte IP ist in einem Vlan, das weg muss ( / 16 )
Das gibt natürlich einen längeren Ausfall, weshalb ich das nachts machen werde (wo mir der Dienstleiter sicher nicht helfen wird). Wenn es ein Problem gibt, kann ich leider nicht über die externe Firewall zurück

Die internen Clients verbinden sich NUR per DNS. Das hab ich schon geprüft, dass da nirgends eine IP hardcoded ist.

Ich verstehe, dass du (gemäß XY Problem) erst die Herangehensweise hinterfragst. Aber ich wollte nur wissen, ob die Umleitung überhaupt machbar ist.

Ich würde das erst mit einem anderen Dienst testen. Und ein zusätzlicher vserver macht nichts aus...

Die Umleitung macht für mich sehr viel Sinn, da sie mir Flexibilität bietet (wie ein Verteiler eben), aber irgendwie kann ich es wohl gerade nicht genug darstellen. Ich kann mich jedenfalls zeitlich unabhängig vom Dienstleister machen und mir die Zeit frei (nachts) einteilen, was wohl der größte Vorteil ist.

..............................................................................................................................................
Ich habe das Ganze mal via ChatGPT eingegeben. Die Antworten wären:

sudo apt-get install iptables
nano /etc/sysctl.conf

eintragen:
net.ipv4.ip_forward=1

nano /etc/network/interfaces

eintragen:
auto eth0
iface eth0 inet static
address 10.4.1.10
netmask 255.255.255.0

neu starten:
sudo ifdown eth0 && sudo ifup eth0

sudo iptables -t nat -A POSTROUTING -s 10.4.1.10/24 -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -i eth0 -o eth0 -j ACCEPT
sudo iptables -t nat -A PREROUTING -i eth0 -j DNAT --to-destination 1.1.1.10
sudo iptables -A FORWARD -i eth0 -o eth0 -j ACCEPT

sudo iptables-save > /etc/iptables/rules.v4


Wenn die iptables-Regeln wie oben beschrieben konfiguriert werden, wird der Server mit der IP 10.1.1.10 die ursprüngliche Quell-IP-Adresse der Pakete sehen, die von Ihrem Debian-Server weitergeleitet werden. Das liegt daran, dass die Option "DNAT" in der iptables-Regel verwendet wird, um das Ziel-IP-Ziel der Pakete zu ändern, bevor sie an den Zielserver weitergeleitet werden.

In diesem Fall wird der Zielserver 1.1.1.10 die Pakete sehen, als ob sie direkt von der Quell-IP-Adresse stammen, die die Pakete tatsächlich sendet (in diesem Fall der Debian-Server mit der IP-Adresse 10.4.1.10).



Leider traue ich dem Braten nicht ganz und hätte die iptables Befehle gern von jemand, der das besser kann als ich (und ChatGPT)

 

[riversource]

Ich werde die IP (und damit das VLAN) ändern. Die alte IP ist in einem Vlan, das weg muss ( / 16 )

Kann es sein, dass du Subnetz und VLAN vertauscht?

Die Umleitung macht für mich sehr viel Sinn, da sie mir Flexibilität bietet (wie ein Verteiler eben),

Genau das macht sie nicht. Ganz im Gegenteil. Es ist lediglich ein weiterer Hop auf dem Weg.

Das Problem bei der Chat-GPT Lösung ist, dass die Anfragen von der original-Adresse beim Server ankommen. Er wird seine Antworten also direkt dahin zurücksenden, von seiner alten Adresse. Der Client hat aber keine Verbindung mit der alten Adresse, sondern mit der Neuen. Er wird die Antworten vom Server verwerfen, weil er die Pakete keiner Verbindung zuordnen kann.

Dir IP-Adressen sind natürlich Unsinn, 1.1.1.10 ist eine öffentliche IP.

 

[KeinNickFrei]

Nein, es ist tatsächlich in einem anderen VLAN und zusätzlich noch dazu in einem übermäßig großen Subnetz (eben 255.255.0.0. )
Ich bin hergegangen und habe neue Vlans mit /24 eingeführt und in die migriere ich.
Routing gibt es natürlich dazwischen. Alles fertig und funktional
Ich muss nur im DNS Server die Einträge anpassen, ein bisschen warten und/oder neu starten und die clients verbinden sich



Aber Danke für den Hinweis im zweiten Absatz. Daran hatte ich nicht gedacht, dass die Clients die Anfrage verwerfen, da die Antwortadresse ja nicht übersetzt wird auf dem Rückweg...

Der Exchange sieht die Original-IP und antwortet mit seiner eigenen und der Client verwirft diese. Ich hatte den TCP-Handshake komplett ignoriert...
Wobei ich mir nicht sicher bin, ob die externe Firewall durch das NAT ing das nicht übersetzt. Schließlich verbinden sich die Clients ja nicht auf interne IPs, sondern auf die externe, die nach intern 1:1 genated wird

Und mit Masquerading , also dass der Exchange den zusätzlichen Hop sieht, wird die Sache wohl nicht besser?

 

[Hannibal Smith]

Routing gibt es natürlich dazwischen. Alles fertig und funktional

Ich hoffe mal via Firewall? Andernfalls trennst du nur Layer2 Broadcastdomänen auf und hast kein Stück an Sicherheit gewonnen.

Schließlich verbinden sich die Clients ja nicht auf interne IPs, sondern auf die externe, die nach intern 1:1 genated wird

Die internen Clients gehen durch die Firewall um dann via Public IP des Exchange wieder auf eine interne zu kommen? Klingt nicht gut.

So oder so, geb dem Exchange doch einfach ein neues Interface im entsprechende vlan und der passenden IP? So kannst du die neue public IP dorthin übersetzen lassen, alle Zugriffe testen und anschliesend die DNS Records anpassen.

Weiterhin solltet ihr euer gesamtes Desing überdenken aber das geht hier zu weit. Dafür gibt es im Zweifel Duenstleister die damit ihre Brötchen verdienen.

 

[KeinNickFrei]

Es gibt natürlich noch Baustellen (wie überall) aber die will ich hier verständlicherweise nicht alle auflisten. Ich sag mal so: bevor ich das übernommen habe, war viel mehr im Argen... und das braucht leider Zeit

Die internen Clients gehen durch die Firewall um dann via Public IP des Exchange wieder auf eine interne zu kommen? Klingt nicht gut.

So oder so, geb dem Exchange doch einfach ein neues Interface im entsprechende vlan und der passenden IP? So kannst du die neue public IP dorthin übersetzen lassen, alle Zugriffe testen und anschliesend die DNS Records anpassen.

Nein, ich meinte, die Clients extern verbinden sich ja auf DNS Records, die auf die externe Ip zeigen, das dann auf die Firewall geht die dann nach intern verbindet...
Und so ein Client erwartet natürlich eine Antwort von der public IP und nicht von einer internen IP.
Wie das die (externe) Firewall übersetzen würde, weiß ich nun nicht

Ja, der Schritt, erst einfach die interne IP zu ändern, dann die Übersetzung wäre der einfache Schritt...
Dann muss ich halt nochmal ran wenn ich auch den Reverse Proxy dazwischen hänge.

 

[riversource]

Nein, ich meinte, die Clients extern verbinden sich ja auf DNS Records, die auf die externe Ip zeigen, das dann auf die Firewall geht die dann nach intern verbindet...

Wenn das der Fall ist, dann kommen doch alle Anfragen beim Mail-Server von internen Clients von der gleichen IP, nämlich vom Gateway. Warum dann der Aufwand, dass die Quell-IP erhalten bleiben muss?

Wie gesagt, wenn es ein Routing zwischen den VLANs gibt, dann ist der Schutzeffekt quasi weg. Das macht keinen Sinn.

So oder so, geb dem Exchange doch einfach ein neues Interface im entsprechende vlan und der passenden IP? So kannst du die neue public IP dorthin übersetzen lassen, alle Zugriffe testen und anschliesend die DNS Records anpassen.

Das würde ich inzwischen auch vorschlagen. Wobei eine gründliche Überarbeitung der Netzwerkarchitektur sinnvoll erscheint. Auch wenn du sagst, dass du dabei bist, aufzuräumen, im Moment sieht das eher nach Chaos aus.

 

[KeinNickFrei]

Nein, ich habe NUR externe Clients skizziert
Interne Clients verbinden sich auf den DNS Namen, der auf die interne IP zeigt.

aber ich glaube, dass ich das einfach mal in einem anderen Szenario teste.

Es wirkt nach Chaos, vieles weil es historisch so übernommen wurde, aber durch mein aufräumen wurde es schon viel besser. Kann es wohl nur nicht ganz so gut präsentieren, wie es scheint

Danke für die Hilfen! V.a. an den Handshake hatte ich eben nicht gedacht.

 

[KeinNickFrei]

Hallo,
als Nachtrag:

Wir haben das so gemacht, dass ich (abends, angekündigtes Wartungsfenster) die interne IP erst geändert habe. Danach alle DNS Einträge angepasst / flushdns gemacht und geprüft, ob alle Einträge (intern) nun auf die neue IP zeigen
Relativ zeitgleich hat der externe Dienstleister dann das Forwarding an der Firewall angepasst.
Hier gab es noch Zeitverzögerungen

Aber rein der IP-Change war komplett problemlos. Mehr noch, nachdem das alte /16 Vlan weg war, wurde es spürbar flotter an manchen Stellen.

Das mit dem Forwarding wäre interessant gewesen, wie es sich verhalten hätte, aber das wäre was für ein Test-Setup, was ich leider nicht habe aus Ressourcengründen.

Thread somit geschlossen/gelöst!