今日、2 つの IP アドレスを持つ VPS を取得しました。
IP がeth0オンのときは動作していますが、ping -I eth0 www.google.comパケット損失は 0% です。しかし、オンのときはping -I eth1 www.goole.com100% のパケット損失になります。
出力は次のようになりますifconfig。
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
これは次の出力です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
そして、これは出力です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
システムを再起動しようとしましたが、何も機能しません。
答え1
両方のインターフェース構成で「DEFROUTE=yes」を指定しても、期待どおりには動作しません。
再起動して (変更した内容を消去するため)、「ip route」を実行します。
次のような画面が表示されます。
# 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
「ping -I eth1 8.8.8.8」を発行すると、システムは eth1 から到達可能なデフォルト ゲートウェイで構成されていないため、ローカル ネットワーク上の 8.8.8.8 を見つけるために ARP 要求がすべてのインターフェイスに送信されます。
# 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
(当然ながら、Google の DNS サーバーは VPS と同じサブネット上にはありません。)
2 番目のデフォルト ルートを追加してみましょう。
# ip route add default via 185.8.49.1 dev eth1
RTNETLINK answers: File exists
システムは複数のデフォルト ルートをすぐには受け入れないようです。
そして、それはある程度理にかなっています。そうでなければ、デバイスは複数のゲートウェイのどれを介してパケットを送信するかを知ることができるのでしょうか。ゲートウェイごとにコピーを送信し、複数の返信パケットを処理するのでしょうか。それとも、非決定的な方法でパケットを任意に送信するのでしょうか (トラブルシューティングが悪夢です)。
おそらく負荷分散できるはずなので、それを試してみましょう。
#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
...
しかし、それは機能するのでしょうか?
# 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!
負荷分散があなたにとって重要なものかどうかを決めるのはあなた次第です本当に必要そして支援する意思があります。