28
IP NAT oder Routing
Moin Leute,
mal eine kurze Frage an euch;
Folgendes Szenario - Kleine RZ Infrastruktur mit Mikrotik Router + Switch und jede (Proxmox) VM in einem VLAN.
Derzeit ist es so, dass sich bei uns alles via VPN abspielt, selten aber doch benötige eine VM aber doch mal eine externe IP..
Wie würdet ihr das umsetzen?
Habe 3x /27 Netze am Mikrotik via Transfernetz aufliegen..
Würdet ihr - Da ja sowieso jede VM schon eine VLAN-IP im eigenen Subnet hat - die IP durchNATen oder Routen?
Vorteil vom NATen wäre natürlich die flexibilität und die Einsparung von v4 Adressen...
Was sagen die Profis hierzu?
VG in die Runde
mal eine kurze Frage an euch;
Folgendes Szenario - Kleine RZ Infrastruktur mit Mikrotik Router + Switch und jede (Proxmox) VM in einem VLAN.
Derzeit ist es so, dass sich bei uns alles via VPN abspielt, selten aber doch benötige eine VM aber doch mal eine externe IP..
Wie würdet ihr das umsetzen?
Habe 3x /27 Netze am Mikrotik via Transfernetz aufliegen..
Würdet ihr - Da ja sowieso jede VM schon eine VLAN-IP im eigenen Subnet hat - die IP durchNATen oder Routen?
Vorteil vom NATen wäre natürlich die flexibilität und die Einsparung von v4 Adressen...
Was sagen die Profis hierzu?
VG in die Runde
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5056909474
Url: https://administrator.de/contentid/5056909474
Ausgedruckt am: 19.11.2024 um 02:11 Uhr
28 Kommentare
Neuester Kommentar
Ich sage mal so: Wenn du es jetzt ordentlich mit Routing machst, fällt es dir auch leichter, das mit IPv6 umzusetzen. NAT ist eigentlich in erster Linie Pfusch für solche Zwecke, der mit IPv6 zum Glück nicht mehr so einfach geht.
Im Prinzip:
Die VM bekommt zusätzlich zur internen IP-Adresse eine externe IPv4 zugewiesen mit /32-Maske.
Dann legst du auf dem Router eine Route an: Öffentliche IPv4/32 -> interne IPv4.
Damit sparst du IP-Adressen wie bei NAT ohne die Nachteile von NAT. Und mit IPv6 könntest du exakt genauso verfahren
Im Prinzip:
Die VM bekommt zusätzlich zur internen IP-Adresse eine externe IPv4 zugewiesen mit /32-Maske.
Dann legst du auf dem Router eine Route an: Öffentliche IPv4/32 -> interne IPv4.
Damit sparst du IP-Adressen wie bei NAT ohne die Nachteile von NAT. Und mit IPv6 könntest du exakt genauso verfahren
2
Vielen Dank für Deine Rückmeldung.
Also dass man eine einzelne /32 IP einfach auf eine LAN-IP Routen kann, wusste ich so nicht - Aber genial..!
Wie sieht das Setup in diesem Fall Client-Seitig aus? (Linux bzw. Win)
GW gibts js nicht. Woher weiß das Server, dass er öffentlich x.x.x.x ist?
Vielen Dank.
Also dass man eine einzelne /32 IP einfach auf eine LAN-IP Routen kann, wusste ich so nicht - Aber genial..!
Wie sieht das Setup in diesem Fall Client-Seitig aus? (Linux bzw. Win)
GW gibts js nicht. Woher weiß das Server, dass er öffentlich x.x.x.x ist?
Vielen Dank.
Der Server braucht nur ein einziges Gateway, in deinem Fall das aus dem internen/privaten Netz der Server.
Darüber kann er den Traffic aller IP-Adressen, die der Server hat, abwerfen
Beispiel:
IP1: 10.4.4.4 /24
IP2: 203.0.113.25 /32
GW: 10.4.4.1
EDIT: Der Server muss auch nicht wissen, ob eine IP öffentlich ist oder nicht.
Für ausgehende Verbindungen nutzt der Server standardmäßig die IP-Adresse, die im selben Subnetz wie das Gateway liegt (also in dem Fall IP1). Verbindungen, die auf IP2 eingehen, werden aber natürlich unabhängig davon auch über IP2 beantwortet.
Darüber kann er den Traffic aller IP-Adressen, die der Server hat, abwerfen
Beispiel:
IP1: 10.4.4.4 /24
IP2: 203.0.113.25 /32
GW: 10.4.4.1
EDIT: Der Server muss auch nicht wissen, ob eine IP öffentlich ist oder nicht.
Für ausgehende Verbindungen nutzt der Server standardmäßig die IP-Adresse, die im selben Subnetz wie das Gateway liegt (also in dem Fall IP1). Verbindungen, die auf IP2 eingehen, werden aber natürlich unabhängig davon auch über IP2 beantwortet.
2
Vielen Dank, jetzt ist alles soweit klar.
Auf die Methode habe ich das noch nicht gemacht :D
Und die öffentlichen IPs am Mikrotik lege ich einfach neben dem Transfernetz auf das WAN-Interface mit bspw. 55.55.55.1/27 und kann dann sämtliche IPs aus dem Subnetz (natürlich außer der Router-IP) auf deine Variante in die VLANS/auf die LAN-IP routen..?
Auf die Methode habe ich das noch nicht gemacht :D
Und die öffentlichen IPs am Mikrotik lege ich einfach neben dem Transfernetz auf das WAN-Interface mit bspw. 55.55.55.1/27 und kann dann sämtliche IPs aus dem Subnetz (natürlich außer der Router-IP) auf deine Variante in die VLANS/auf die LAN-IP routen..?
Nein, um die IP-Adressen routen zu können, darfst du sie nicht am Router binden.
Diese werden ja, so wie ich das verstanden habe, vom RZ-Provider über ein Transfernetz auf deinen Mikrotik geroutet?
Diese werden ja, so wie ich das verstanden habe, vom RZ-Provider über ein Transfernetz auf deinen Mikrotik geroutet?
Genau, ich bekomme die per Transfernetz vom Provider geroutet..
Du meinst, der Router weiß nicht, dass die IPs existieren - Bis auf die Route ins LAN? Sonst muss ich die nirgendwo am Router eintragen oder bekannt machen?
Du meinst, der Router weiß nicht, dass die IPs existieren - Bis auf die Route ins LAN? Sonst muss ich die nirgendwo am Router eintragen oder bekannt machen?
Die statische Route reicht
Alles klar, versuche ich so.
Thanks
Thanks
Mir fällt gerade ein: Du solltest bei dem Setup auf dem Router für das an euch geroutete Netz eine /27-Nullroute anlegen.
Hintergrund ist, dass dein Router sonst Pakete bekommt, nicht weiß wohin damit und diese mangels Alternative über das Defaultgateway wieder rausschickt. Solche Loops sind unschön und belasten die Router unnötig.
Deshalb sollte man dann immer Nullrouten für alle Präfixe anlegen, die man bekommt. Die spezifischeren /32-Routen übersteuern die Nullroute problemlos, aber Traffic an "ungeroutete" Adressen wird von deinem Router dann verworfen.
Hintergrund ist, dass dein Router sonst Pakete bekommt, nicht weiß wohin damit und diese mangels Alternative über das Defaultgateway wieder rausschickt. Solche Loops sind unschön und belasten die Router unnötig.
Deshalb sollte man dann immer Nullrouten für alle Präfixe anlegen, die man bekommt. Die spezifischeren /32-Routen übersteuern die Nullroute problemlos, aber Traffic an "ungeroutete" Adressen wird von deinem Router dann verworfen.
eine /27-Nullroute anlegen.
Bei Mikrotik dann also ne Route vom type blackhole,unreachable oder prohibit anlegen./ip route add dst-address=x.x.x.x/27 type=unreachableZitat von @LordGurke:
Ich sage mal so: Wenn du es jetzt ordentlich mit Routing machst, fällt es dir auch leichter, das mit IPv6 umzusetzen. NAT ist eigentlich in erster Linie Pfusch für solche Zwecke, der mit IPv6 zum Glück nicht mehr so einfach geht.
Im Prinzip:
Die VM bekommt zusätzlich zur internen IP-Adresse eine externe IPv4 zugewiesen mit /32-Maske.
Dann legst du auf dem Router eine Route an: Öffentliche IPv4/32 -> interne IPv4.
Damit sparst du IP-Adressen wie bei NAT ohne die Nachteile von NAT. Und mit IPv6 könntest du exakt genauso verfahren
Ich sage mal so: Wenn du es jetzt ordentlich mit Routing machst, fällt es dir auch leichter, das mit IPv6 umzusetzen. NAT ist eigentlich in erster Linie Pfusch für solche Zwecke, der mit IPv6 zum Glück nicht mehr so einfach geht.
Im Prinzip:
Die VM bekommt zusätzlich zur internen IP-Adresse eine externe IPv4 zugewiesen mit /32-Maske.
Dann legst du auf dem Router eine Route an: Öffentliche IPv4/32 -> interne IPv4.
Damit sparst du IP-Adressen wie bei NAT ohne die Nachteile von NAT. Und mit IPv6 könntest du exakt genauso verfahren
Guten Morgen,
die blackholes habe ich nun umgesetzt - Das klappt einwandfrei.
Möchtest du mir mal eine Beispiel-Route zum Routen der statischen IP auf die LAN-IP schreiben? :D
Das will im Moment nicht, wobei man dazu sagen muss, dass sich die Optionen der Routen bei MikroTik extrem geändert haben.
Vielen Dank.
/ip route add dst-address=x.x.x.x/32 gateway=10.4.4.20Natürlich die Firewall nicht vergessen. Die Forward-Chain muss den Traffic von extern nach intern durchlassen.
Bspw. mit
/ip firewall filter add chain=forward in-interface=ether1 dst-address=x.x.x.x/32 action=accept
Schönen Abend zusammen, ich muss das Thema hier nochmal aufreißen - Das /32 Routing funktioniert einwandfrei - Dafür übrigens nochmal vielen Dank, kannte ich so wirklich nicht.
Nun ist es aber so, dass ich aufgrund des LAN-Gateways natürlich über die "LAN-IP" per NAT raus gehe und nicht mit der zugewiesenen öffentlichen IP.
Habt ihr hier eine Idee, das zu lösen?
In Linux habe ich die /32 einfach per ip up hinzugefügt, bzw. bei neuen Distris schon mit netplan - address, bei Windows einfach als "zusätzliche IP-Adresse".
Nun ist es aber so, dass ich aufgrund des LAN-Gateways natürlich über die "LAN-IP" per NAT raus gehe und nicht mit der zugewiesenen öffentlichen IP.
Habt ihr hier eine Idee, das zu lösen?
In Linux habe ich die /32 einfach per ip up hinzugefügt, bzw. bei neuen Distris schon mit netplan - address, bei Windows einfach als "zusätzliche IP-Adresse".
Bei Linux kann man die zu verwendende Source-Adresse bei Routen mitgeben.
Du würdest dann die Default-Route anlegen mit
Je nach Distro kann/muss das in entsprechenden Config-Dateien abgelegt werden.
Bei Windows wird es sicherlich mit netsh etwas identisches geben, da bin ich aber mittlerweile zu lange raus.
Du würdest dann die Default-Route anlegen mit
ip route add default via 10.4.4.1 src 4.3.2.1Je nach Distro kann/muss das in entsprechenden Config-Dateien abgelegt werden.
Bei Windows wird es sicherlich mit netsh etwas identisches geben, da bin ich aber mittlerweile zu lange raus.
1Zitat von @LordGurke:
Bei Linux kann man die zu verwendende Source-Adresse bei Routen mitgeben.
Du würdest dann die Default-Route anlegen mit
Je nach Distro kann/muss das in entsprechenden Config-Dateien abgelegt werden.
Bei Windows wird es sicherlich mit netsh etwas identisches geben, da bin ich aber mittlerweile zu lange raus.
Bei Linux kann man die zu verwendende Source-Adresse bei Routen mitgeben.
Du würdest dann die Default-Route anlegen mit
ip route add default via 10.4.4.1 src 4.3.2.1Je nach Distro kann/muss das in entsprechenden Config-Dateien abgelegt werden.
Bei Windows wird es sicherlich mit netsh etwas identisches geben, da bin ich aber mittlerweile zu lange raus.
Linux funktioniert einwandfrei, leider benötige auch eine Windows-VM die source-IP.
Hier habe ich nun versucht, den "Skip as Source" Parameter für die LAN-IP auf "true" zu setzen, das funktioniert allerdings nicht.
Get-NetIPAddress 192.x.x.x | Set-NetIPAddress -SkipAsSource $TrueAddress 78.x.x.x Parameters
---------------------------------------------------------
Interface Luid : Ethernet Instance 0 2
Scope Id : 0.0
Valid Lifetime : infinite
Preferred Lifetime : infinite
DAD State : Preferred
Address Type : Manual
Skip as Source : false
Address 192.x.x.x Parameters
---------------------------------------------------------
Interface Luid : Ethernet Instance 0 2
Scope Id : 0.0
Valid Lifetime : infinite
Preferred Lifetime : infinite
DAD State : Preferred
Address Type : Manual
Skip as Source : trueZitat von @LordGurke:
Bei Linux kann man die zu verwendende Source-Adresse bei Routen mitgeben.
Du würdest dann die Default-Route anlegen mit
Je nach Distro kann/muss das in entsprechenden Config-Dateien abgelegt werden.
Bei Windows wird es sicherlich mit netsh etwas identisches geben, da bin ich aber mittlerweile zu lange raus.
Bei Linux kann man die zu verwendende Source-Adresse bei Routen mitgeben.
Du würdest dann die Default-Route anlegen mit
ip route add default via 10.4.4.1 src 4.3.2.1Je nach Distro kann/muss das in entsprechenden Config-Dateien abgelegt werden.
Bei Windows wird es sicherlich mit netsh etwas identisches geben, da bin ich aber mittlerweile zu lange raus.
Komme hier leider unter Windows auf keinen grünen Zweig.
Im schlimmsten Fall könnte man das aber auch mit NAT lösen, und die IP-Adresse übersetzen, oder?
Ist natürlich nicht die schönste Lösung.
Habe das hier mal getestet und eine zweite IP unter windows mit X.X.X.X MASK 255.255.255.255 auf dem LAN Interface hinterlegt.
Dann eine Zielroute auf dem Router zu dieser IP über die andere Adresse angelegt. Die Pakete kamen brav wieder von der angesprochenen IP zurück. Würde ja sonst auch zum break der TCP-Connection kommen wenn die Pakete plötzlich von einer anderen als der DST Adresse zurück kommen würden ... Das ist also der Default in Windows, da braucht man nichts ändern.
Wurstel
Dann eine Zielroute auf dem Router zu dieser IP über die andere Adresse angelegt. Die Pakete kamen brav wieder von der angesprochenen IP zurück. Würde ja sonst auch zum break der TCP-Connection kommen wenn die Pakete plötzlich von einer anderen als der DST Adresse zurück kommen würden ... Das ist also der Default in Windows, da braucht man nichts ändern.
Wurstel
1Zitat von @5175293307:
Habe das hier mal getestet und eine zweite IP unter windows mit X.X.X.X MASK 255.255.255.255 auf dem LAN Interface hinterlegt.
Dann eine Zielroute auf dem Router zu dieser IP über die andere Adresse angelegt. Die Pakete kamen brav wieder von der angesprochenen IP zurück. Würde ja sonst auch zum break der TCP-Connection kommen wenn die Pakete plötzlich von einer anderen als der DST Adresse zurück kommen würden ... Das ist also der Default in Windows, da braucht man nichts ändern.
Wurstel
Habe das hier mal getestet und eine zweite IP unter windows mit X.X.X.X MASK 255.255.255.255 auf dem LAN Interface hinterlegt.
Dann eine Zielroute auf dem Router zu dieser IP über die andere Adresse angelegt. Die Pakete kamen brav wieder von der angesprochenen IP zurück. Würde ja sonst auch zum break der TCP-Connection kommen wenn die Pakete plötzlich von einer anderen als der DST Adresse zurück kommen würden ... Das ist also der Default in Windows, da braucht man nichts ändern.
Wurstel
Vielen Dank für deine Antwort.
Klappt bei mir allerdings nicht - Ich gehe immer mit der Mikrotik-Router IP raus, auf dem Router selbst ist NAT eingerichtet (srcnat/masquerade mit meinem WAN als out-interface)
Das sollte damit aber nichts zutun haben, oder?
Wenn ich testweise NAT ausschalte, komme ich von meiner Windows-VM nicht mehr raus.
Hast du keine zusätzlichen Settings im Windows gemacht, außer die /32 IP aufgeschalten?
Zitat von @tommy98:
Klappt bei mir allerdings nicht - Ich gehe immer mit der Mikrotik-Router IP raus, auf dem Router selbst ist NAT eingerichtet (srcnat/masquerade mit meinem WAN als out-interface)
Wieso? Genau das willst du doch nicht, du willst ja routen nicht NATenDas sollte damit aber nichts zutun haben, oder?
Das NAT muss natürlich für die Public IPvom SRCNAT ausgenommen werden!
Z.B. mit folgender Regel die vor der allgemeinen masquerade Regel stehen muss
/ip firewall nat add chain=srcnat src-address=x.x.x.x out-interface=wan action=accept place-before=1Wenn ich testweise NAT ausschalte, komme ich von meiner Windows-VM nicht mehr raus.
Du darfst nicht die feste IP NATen sondern nur den Traffic der internen privaten Adresse.Hast du keine zusätzlichen Settings im Windows gemacht, außer die /32 IP aufgeschalten?
Zitat von @5175293307:
vom SRCNAT ausgenommen werden!
Z.B. mit folgender Regel die vor der allgemeinen masquerade Regel stehen muss
Hast du keine zusätzlichen Settings im Windows gemacht, außer die /32 IP aufgeschalten?
Nein!
Zitat von @tommy98:
Klappt bei mir allerdings nicht - Ich gehe immer mit der Mikrotik-Router IP raus, auf dem Router selbst ist NAT eingerichtet (srcnat/masquerade mit meinem WAN als out-interface)
Wieso? Genau das willst du doch nicht, du willst ja routen nicht NATenDas sollte damit aber nichts zutun haben, oder?
Das NAT muss natürlich für die Public IPvom SRCNAT ausgenommen werden!
Z.B. mit folgender Regel die vor der allgemeinen masquerade Regel stehen muss
/ip firewall nat add chain=srcnat src-address=x.x.x.x out-interface=wan action=accept place-before=1Wenn ich testweise NAT ausschalte, komme ich von meiner Windows-VM nicht mehr raus.
Du darfst nicht die feste IP NATen sondern nur den Traffic der internen privaten Adresse.Hast du keine zusätzlichen Settings im Windows gemacht, außer die /32 IP aufgeschalten?
Vielen Dank nochmal für deine Denkansätze.
Genau so wie von Dir beschrieben ist es gemacht.
Ich habe deine NAT-Regel nun auch noch hinzugefügt, hatte es mit einer Ausnahme in der masquerade-Regel - Ändert aber nichts am Geschehen. Ich gehe immer noch über meine Router-IP raus. Mir gehen langsam die Ideen aus.
Traceroute aus der VM zeigt
hop1: VLAN Gateway
hop2: Internet Provider GatewayIrgendeine Idee das zu debuggen?
Wäre ja vielleicht mal sinnvoll deine Config als Export im Klartext zu posten damit wir hier nicht im Regen stehen und die Glaskugel polieren müssen.
@5175293307:
Das Problem ist, dass neue, ausgehende Verbindungen vom Windows-System mit der lokalen RFC1918-IP initiiert werden, die dann vom Router geNATet werden - aber dadurch natürlich nicht mit der IP kommen, die als /32 auf dem Windows-Server konfiguriert und geroutet ist.
Speziell bei Mailservern ist das natürlich schlecht.
Am Router kannst du das aber auch nicht richtig NATen, da der Router die IP ja überhaupt nicht gebunden hat.
Windows wählt, was an sich ja vollkommen richtig ist, als Quelladresse für neue ausgehende Verbindungen die IP als Quelle, die sich "am nächsten" am Gateway befindet. Und das ist nunmal die RFC1918-Adresse.
Unter Linux wird das identisch gehandhabt, dort lässt sich das aber wie gesagt beim Anlegen der Default-Route schlicht übersteuern. Einen solchen Parameter habe ich bei Windows nicht gefunden
So eine richtig gute Lösung dafür habe ich leider noch nicht gefunden...
Das Problem ist, dass neue, ausgehende Verbindungen vom Windows-System mit der lokalen RFC1918-IP initiiert werden, die dann vom Router geNATet werden - aber dadurch natürlich nicht mit der IP kommen, die als /32 auf dem Windows-Server konfiguriert und geroutet ist.
Speziell bei Mailservern ist das natürlich schlecht.
Am Router kannst du das aber auch nicht richtig NATen, da der Router die IP ja überhaupt nicht gebunden hat.
Windows wählt, was an sich ja vollkommen richtig ist, als Quelladresse für neue ausgehende Verbindungen die IP als Quelle, die sich "am nächsten" am Gateway befindet. Und das ist nunmal die RFC1918-Adresse.
Unter Linux wird das identisch gehandhabt, dort lässt sich das aber wie gesagt beim Anlegen der Default-Route schlicht übersteuern. Einen solchen Parameter habe ich bei Windows nicht gefunden
So eine richtig gute Lösung dafür habe ich leider noch nicht gefunden...
Achso das meint er, wenn er mit der öffentlichen IP raus will, klar. Dann wird er unter Windows wohl oder übel seine DefaultGW Adresse anpassen müssen.
Also eine der Public IPs aus dem Pool am Router binden und im Server statt dessen als Default GW eintragen.
Ist zwar blöd das man damit IPs verschwendet aber wat willste machen bei dem Winblows Theater, am besten gleich auf Linux umsatteln...
Also eine der Public IPs aus dem Pool am Router binden und im Server statt dessen als Default GW eintragen.
Ist zwar blöd das man damit IPs verschwendet aber wat willste machen bei dem Winblows Theater, am besten gleich auf Linux umsatteln...
Vielen Dank für eure Hilfe - Dann dürfte das unter Windows wohl echt nicht machbar sein - Echt schade.
So wie ich das sehe bleibt nur ein Umstieg auf Linux, oder das Subnetz teilen und an den Router & VLAN binden..
So wie ich das sehe bleibt nur ein Umstieg auf Linux, oder das Subnetz teilen und an den Router & VLAN binden..
Zitat von @LordGurke:
Bei Linux kann man die zu verwendende Source-Adresse bei Routen mitgeben.
Du würdest dann die Default-Route anlegen mit
Je nach Distro kann/muss das in entsprechenden Config-Dateien abgelegt werden.
Bei Windows wird es sicherlich mit netsh etwas identisches geben, da bin ich aber mittlerweile zu lange raus.
Bei Linux kann man die zu verwendende Source-Adresse bei Routen mitgeben.
Du würdest dann die Default-Route anlegen mit
ip route add default via 10.4.4.1 src 4.3.2.1Je nach Distro kann/muss das in entsprechenden Config-Dateien abgelegt werden.
Bei Windows wird es sicherlich mit netsh etwas identisches geben, da bin ich aber mittlerweile zu lange raus.
Hatte mich da letztens wohl vertan.
Habe das jetzt mal etwas näher getestet, das funktioniert allerdings auch nicht unter Linux - Die IP ist up und die Route eingetragen, auch hier gehe ich wie bei Windows wieder unter der Router-IP raus.
Ping der Öffentlichen IP von außen kein Problem.
/etc/network/interfaces
up ip addr add 80.0.0.12/32 dev ens18
up ip route add default via 10.0.0.1 src 80.0.0.12das funktioniert allerdings auch nicht unter Linux
Klappt hier im Test einwandfrei ... Wireshark bestätigt mir das.via 10.0.0.1 via 1.2.3.1
wat soll'n das?Zitat von @5175293307:
das funktioniert allerdings auch nicht unter Linux
Klappt hier im Test einwandfrei ... Wireshark bestätigt mir das.via 10.0.0.1 via 1.2.3.1
wat soll'n das?Da habe ich mir beim rauskopieren und anpassen vertippt - sorry.
Regel im Kommentar ist angepasst, die funktioniert aber soweit, komme ja auch von außen drauf, geht nur drum, dass ich mit neuen Verbindungen nach außen mit der falschen IP raus gehe..
Zitat von @LordGurke:
@5175293307:
Das Problem ist, dass neue, ausgehende Verbindungen vom Windows-System mit der lokalen RFC1918-IP initiiert werden, die dann vom Router geNATet werden - aber dadurch natürlich nicht mit der IP kommen, die als /32 auf dem Windows-Server konfiguriert und geroutet ist.
Speziell bei Mailservern ist das natürlich schlecht.
Am Router kannst du das aber auch nicht richtig NATen, da der Router die IP ja überhaupt nicht gebunden hat.
Windows wählt, was an sich ja vollkommen richtig ist, als Quelladresse für neue ausgehende Verbindungen die IP als Quelle, die sich "am nächsten" am Gateway befindet. Und das ist nunmal die RFC1918-Adresse.
Unter Linux wird das identisch gehandhabt, dort lässt sich das aber wie gesagt beim Anlegen der Default-Route schlicht übersteuern. Einen solchen Parameter habe ich bei Windows nicht gefunden
So eine richtig gute Lösung dafür habe ich leider noch nicht gefunden...
@5175293307:
Das Problem ist, dass neue, ausgehende Verbindungen vom Windows-System mit der lokalen RFC1918-IP initiiert werden, die dann vom Router geNATet werden - aber dadurch natürlich nicht mit der IP kommen, die als /32 auf dem Windows-Server konfiguriert und geroutet ist.
Speziell bei Mailservern ist das natürlich schlecht.
Am Router kannst du das aber auch nicht richtig NATen, da der Router die IP ja überhaupt nicht gebunden hat.
Windows wählt, was an sich ja vollkommen richtig ist, als Quelladresse für neue ausgehende Verbindungen die IP als Quelle, die sich "am nächsten" am Gateway befindet. Und das ist nunmal die RFC1918-Adresse.
Unter Linux wird das identisch gehandhabt, dort lässt sich das aber wie gesagt beim Anlegen der Default-Route schlicht übersteuern. Einen solchen Parameter habe ich bei Windows nicht gefunden
So eine richtig gute Lösung dafür habe ich leider noch nicht gefunden...
Unter Linux Debian bin ich nun auf die lösung gekommen, hier hilft folgender Eintrag in der
/etc/network/interfaces
up ip route change default via 10.0.0.1 src 80.0.0.12Nur Windows ist noch die Frage..
