Absenderadresse der Public IP gewünscht, statt die des Transfernetzes

[erikgriffin]

Hallo zusammen,

ich habe einen Router konfiguriert der aus folgenden Schnittstellen besteht:

• eth0.1000 - mit Public IP-Adresse aaa.bbb.ccc.217/29

• eth0.1100 - mit lokaler IP-Adresse 192.168.x.x (NAT!)

• eth1.1407 - mit Transfer-Netz-Adresse xxx.yyy.zzz.179/31

An dem Router hängen über das VLAN 1000 noch weitere Firmen/Mieter die jeweils eine weitere Public IP-Adresse besitzen. Das Routing funktioniert auch soweit wunderbar.

Was mich stört ist, dass der Netzwerktraffic aus dem 192.168.x.x-Netz welcher genattet wird, als Absenderadresse die des Transfer-Netzes von eth1.1407 und nicht die Public-IP von eth0.1000 hat. Der Traffic aus dem VLAN 1000 der anderen Router hat jeweils die Absenderadresse des jeweils dort eingesetzten Routers. Irgendwie stehe ich auf dem Schlauch.

Folgende NAT-Regeln habe ich probiert:

# funktioniert nicht, soll die Absenderadresse aaa.bbb.ccc.217 haben

Code: Alles auswählen

-A POSTROUTING -m iprange --src-range 192.168.0.0-192.168.255.255 -o eth0.1000 -j MASQUERADE

# funktioniert, hat aber die Absenderadresse xxx.yyy.zzz.179

Code: Alles auswählen

-A POSTROUTING -m iprange --src-range 192.168.0.0-192.168.255.255 -o eth1.1407 -j MASQUERADE

# funktioniert, hat aber die Absenderadresse xxx.yyy.zzz.179

Code: Alles auswählen

-A POSTROUTING -m iprange --src-range 192.168.0.0-192.168.255.255 -j MASQUERADE

Was muss ich ändern, damit mein genatteter Traffic als Absender-IP die Public-IP vom eth0.1100 hat?

Danke + viele Grüße
Erik

[Livingston]

Was sagt denn vor und nach der Eingabe des POSTROUTING der Befehl

Code: Alles auswählen

$ ip r

[mludwig]

Bei SNAT kann man direkt die IP angeben, auf die genattet werden soll. Dabei wird aber immer davon ausgegangen, dass die entsprechende IP auch auf dem ausgehenden Interface vorhanden ist.

Code: Alles auswählen

iptables -t nat -A POSTROUTING -o ethx.y -j SNAT --to $ip

Ob das dann auch funktioniert, wenn $ip nicht (z. B. als zusätzliche IP) an ethx.y hängt, müsstest du ausprobieren.

[mat6937]

..., wenn $ip nicht (z. B. als zusätzliche IP) an ethx.y hängt, müsstest du ausprobieren.

Ich denke iptables kann mit aliases nichts anfangen. Für iptables ist ethx.y = ethx.
Oder ist das nur bei iptables-legacy so, und das "neue" iptables kann mit aliases umgehen?
BTW: Mit systemd-networkd kann man einem Interface mehrere IP-Adressen zuweisen, so dass aliases nicht mehr gebraucht werden.
Z. B.:

Code: Alles auswählen

:~# ip a s dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1472 qdisc mq state UP group default qlen 5000
    link/ether ##:##:##:62:3c:ae brd ff:ff:ff:ff:ff:ff permaddr xx:xx:xx:46:a1:0e
    inet 192.168.178.13/24 brd 192.168.178.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.174.24/24 brd 192.168.174.255 scope global eth0
       valid_lft forever preferred_lft forever

Code: Alles auswählen

:~ $ ip r g 192.168.174.3
192.168.174.3 dev eth0 src 192.168.174.24 uid 1000 
    cache 

Code: Alles auswählen

:~ $ ip r g 192.168.178.45
192.168.178.45 dev eth0 src 192.168.178.13 uid 1000 
    cache 

... auch mit:

Code: Alles auswählen

net.ipv4.conf.eth0.arp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1

[mludwig]

..., wenn $ip nicht (z. B. als zusätzliche IP) an ethx.y hängt, müsstest du ausprobieren.

Ich denke iptables kann mit aliases nichts anfangen. Für iptables ist ethx.y = ethx.
Oder ist das nur bei iptables-legacy so, und das "neue" iptables kann mit aliases umgehen?

Es ging beim Threadersteller nicht um aliases, sondern eth0.1000 war dort VLAN 1000 auf eth0. Dort geht das mit separaten IPs und iptables Regeln auf jeden Fall.