☰

„eth1“ funktioniert nicht auf einem CentOS VPS-Setup mit Dual-IP

tag-icon • tag-icon linux networking centos
„eth1“ funktioniert nicht auf einem CentOS VPS-Setup mit Dual-IP

Heute habe ich einen VPS mit 2 IP-Adressen bekommen.

Die IP eth0funktioniert, wenn ich das tue, ping -I eth0 www.google.comhabe ich 0 % Paketverlust, aber wenn ich das tue, ping -I eth1 www.goole.comhabe ich 100 % Paketverlust.

Dies ist die ifconfigAusgabe:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 185.8.49.12  netmask 255.255.255.0  broadcast 185.8.49.255
    inet6 fe80::250:56ff:fe84:5ed6  prefixlen 64  scopeid 0x20<link>
    ether 00:50:56:84:5e:d6  txqueuelen 1000  (Ethernet)
    RX packets 5716  bytes 398892 (389.5 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 933  bytes 294738 (287.8 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
    inet 185.8.49.157  netmask 255.255.255.0  broadcast 185.8.49.255
    ether 00:50:56:84:5e:d7  txqueuelen 1000  (Ethernet)
    RX packets 0  bytes 0 (0.0 B)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 0  bytes 0 (0.0 B)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
    inet 127.0.0.1  netmask 255.0.0.0
    inet6 ::1  prefixlen 128  scopeid 0x10<host>
    loop  txqueuelen 0  (Local Loopback)
    RX packets 56  bytes 8896 (8.6 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 56  bytes 8896 (8.6 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Dies ist die Ausgabe von ifcfg-eth0:

DEVICE=eth0
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth0"
BOOTPROTO=none
IPADDR=185.8.49.12
NETMASK=255.255.255.0
GATEWAY=185.8.49.1
DNS1=62.149.128.4
DNS2=62.149.132.4

Und dies ist die Ausgabe von ifcfg-eth1:

DEVICE=eth1
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth1"
BOOTPROTO=none
IPADDR=185.8.49.157
NETMASK=255.255.255.0
GATEWAY=185.8.49.1

Ich habe versucht, das System neu zu starten, aber nichts funktioniert.

Antwort1

„DEFROUTE=yes“ bewirkt in beiden Schnittstellenkonfigurationen nicht das, was Sie denken.

Starten Sie neu (um alle Änderungen zu löschen, die Sie vorgenommen haben) und führen Sie „ip route“ aus.
Sie sollten etwas wie Folgendes sehen:

# ip route
default via 185.8.49.1 dev eth0
185.8.49.0/24 dev eth0  proto kernel  scope link  src 185.8.49.12 
185.8.49.0/24 dev eth1  proto kernel  scope link  src 185.8.49.157

Wenn Sie „ping -I eth1 8.8.8.8“ eingeben, werden ARP-Anfragen an alle Schnittstellen gesendet, um 8.8.8.8 im lokalen Netzwerk zu finden, da das System nicht mit einem über eth1 erreichbaren Standard-Gateway konfiguriert ist:

# ping -I eth1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 185.8.49.157 eth1: 56(84) bytes of data.
From 185.8.49.157 icmp_seq=1 Destination Host Unreachable
From 185.8.49.157 icmp_seq=2 Destination Host Unreachable
From 185.8.49.157 icmp_seq=3 Destination Host Unreachable
From 185.8.49.157 icmp_seq=4 Destination Host Unreachable

# tcpdump -ni eth0 'arp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
05:07:42.821526 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 46
05:07:43.821185 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 46
05:07:44.823000 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 46

# tcpdump -ni eth1 'arp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
05:07:42.820834 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 28
05:07:43.820864 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 28
05:07:44.822841 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 28

(Offensichtlich befindet sich der DNS-Server von Google nicht im selben Subnetz wie Ihr VPS.)

Versuchen Sie, die zweite Standardroute hinzuzufügen:

# ip route add default via 185.8.49.1 dev eth1
RTNETLINK answers: File exists

Es sieht so aus, als würde das System nicht ohne weiteres mehrere Standardrouten akzeptieren.
Und das macht durchaus Sinn – wie sonst würde das Gerät wissen, über welches seiner zahlreichen Gateways es ein Paket senden soll? Würde es eine Kopie pro Gateway senden ... und dann mit mehreren Rückpaketen umgehen? Oder würde es willkürlich und auf nicht deterministische Weise Pakete versenden (ein Albtraum bei der Fehlerbehebung)?
Vermutlich könnte es eine Lastverteilung vornehmen, also versuchen wir das:

#ip route delete default
#ip route add default scope global nexthop via 185.8.49.1 dev eth0 weight 1 nexthop via 185.8.49.1 dev eth1 weight 1
#ip ro
default 
        nexthop via 185.8.49.1  dev eth0 weight 1
        nexthop via 185.8.49.1  dev eth1 weight 1
...

Aber funktioniert es?

# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=17.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=18.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=17.1 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=15.3 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 15.337/17.227/18.762/1.241 ms

# tcpdump -ni eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
05:46:31.837933 IP 185.8.49.12 > 8.8.8.8: ICMP echo request, id 2382, seq 1, length 64
05:46:31.855566 IP 8.8.8.8 > 185.8.49.12: ICMP echo reply, id 2382, seq 1, length 64
05:46:33.842373 IP 185.8.49.12 > 8.8.8.8: ICMP echo request, id 2382, seq 3, length 64
05:46:33.859469 IP 8.8.8.8 > 185.8.49.12: ICMP echo reply, id 2382, seq 3, length 64

# tcpdump -ni eth1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
05:46:32.840535 IP 185.8.49.157 > 8.8.8.8: ICMP echo request, id 2382, seq 2, length 64
05:46:32.859029 IP 8.8.8.8 > 185.8.49.157: ICMP echo reply, id 2382, seq 2, length 64
05:46:34.843725 IP 185.8.49.157 > 8.8.8.8: ICMP echo request, id 2382, seq 4, length 64
05:46:34.859020 IP 8.8.8.8 > 185.8.49.157: ICMP echo reply, id 2382, seq 4, length 64

TA-DA!
Jetzt liegt es an Ihnen, zu entscheiden, ob Lastverteilung etwas ist, das Siewirklich brauchenund sind bereit zu unterstützen.

verwandte Informationen