☰

Multi-Homed Ubuntu kann nicht von einem anderen Subnetz aus erreicht werden

tag-icon • tag-icon ubuntu linux-networking multi-homed
Multi-Homed Ubuntu kann nicht von einem anderen Subnetz aus erreicht werden

Ich habe einen Multi-Homed-Server mit Ubuntu 12.04. Ich habe zwei Netzwerkschnittstellen, die mit zwei verschiedenen IP-Bereichen verbunden sind.

2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 190.113.X.X/29 brd 190.113.98.183 scope global eth1
(...)

3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 10.100.100.21/24 brd 10.100.100.255 scope global eth0
(...)

Wenn ich versuche, von einem anderen Subnetz, das nicht zum Netzwerk gehört, auf den Server über den eth0-Link zuzugreifen, 10.100.100.Xerhalte ich keine Antwort. Ich habe iptableses auf dem Server laufen (da er eine öffentliche IP in eth1 hat), aber ich lasse den gesamten Datenverkehr aus dem privaten Netzwerk über den eth0-Link zu.

Wenn ich eins tcpdumpauf der Schnittstelle im Server mache, erhalte ich Folgendes (mein PC ist 10.100.102.22):

18:30:23.813889 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.100.102.22 tell 10.100.100.21, length 28
18:30:24.810691 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.100.102.22 tell 10.100.100.21, length 28
18:30:25.810718 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.100.102.22 tell 10.100.100.21, length 28

Ich kann vom Server aus einen Ping an meinen PC senden:

PING 10.100.102.22 (10.100.102.22) 56(84) bytes of data.
64 bytes from 10.100.102.22: icmp_req=1 ttl=63 time=0.273 ms
64 bytes from 10.100.102.22: icmp_req=2 ttl=63 time=0.324 ms

Die Routingtabelle sieht wie folgt aus: Tabelle 1:

default via 10.100.100.1 dev eth0 
10.0.0.0/8 dev eth0  scope link  src 10.100.100.21

Tabelle 2:

default via 190.113.X.X dev eth1 
190.113.X.X/29 dev eth1  scope link  src 190.113.X.X

Standard:

default via 10.100.100.1 dev eth0  metric 100 
10.100.100.0/24 dev eth0  proto kernel  scope link  src 10.100.100.21 
190.113.X.X/29 dev eth1  proto kernel  scope link  src 190.113.X.X

Antwort1

Der Client muss auch die Route zum Netzwerk 10.100.100.0/24 kennen.

Sie müssen also entweder eine Route auf dem Client hinzufügen

ip r a 10.100.100.0/24 via 10.100.100.1 dev eth0

oder Sie müssen die Route zum Standard-Gateway hinzufügen, das der Client verwendet.

Sie können es sich so vorstellen: Der Client muss wissen, wie er 10.100.100.21 erreicht. Wenn nicht, versucht er es mit dem Standard-Gateway. Wenn das Gateway es nicht weiß, haben Sie Pech gehabt.

verwandte Informationen