非常に特定の状況でプライベートネットワークトラフィックが偽装されていないかどうか質問があります。
10.1.0.0/18
ネットワークは、ネットワークを使用するVMwareゲストのセットです。
問題のホストは、10.1.4.20 255.255.192.0
使用するように構成された唯一のゲートウェイです10.1.63.254
。ゲートウェイサーバーは$vpnGatewayAddress
すべてのアウトバウンドトラフィックを偽装して転送する必要があります$outerGatewayAddress
が、何らかの理由で次のようにルートキャッシュに10.1.4.20
到達することがあります。$outerGatewayAddress
ip -s route show cache 199.16.156.40
199.16.156.40 from 10.1.4.20 via $outerGatewayAddress dev eth0
cache used 149 age 17sec ipid 0x9e49
199.16.156.40 via $outerGatewayAddress dev eth0 src 10.1.4.20
cache used 119 age 11sec ipid 0x9e49
この問題はapi.twitter.comでのみ発生します。
キャッシュを空にしてからもう一度pingすると、キャッシュは正常に見えます。
ip route flush cache 199.16.156.40
ping api.twitter.com
PING api.twitter.com (199.16.156.40) 56(84) bytes of data.
64 bytes from 199.16.156.40: icmp_req=1 ttl=247 time=93.4 ms
ip -s route show cache 199.16.156.40
199.16.156.40 from 10.1.4.20 via 10.1.63.254 dev eth0
cache age 3sec
199.16.156.40 via 10.1.63.254 dev eth0 src 10.1.4.20
cache used 2 age 2sec
アプリケーションサーバーのネットワーク情報(loを除く):
ip a
eth0 Link encap:Ethernet HWaddr 00:50:56:a4:48:20
inet addr:10.1.4.20 Bcast:10.1.63.255 Mask:255.255.192.0
inet6 addr: fe80::250:56ff:fea4:4820/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1523222895 errors:0 dropped:407 overruns:0 frame:0
TX packets:1444207934 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1524116772058 (1.5 TB) TX bytes:565691877505 (565.6 GB)
VPNゲートウェイのネットワーク情報(loもありません):
eth0 Link encap:Ethernet HWaddr 00:50:56:a4:56:e9
inet addr:$vpnGatewayAddress Bcast:$broadcastAddress Mask:255.255.255.192
inet6 addr: fe80::250:56ff:fea4:56e9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7030472688 errors:0 dropped:1802 overruns:0 frame:0
TX packets:6959026084 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7777330931859 (7.7 TB) TX bytes:7482143729162 (7.4 TB)
eth0:0 Link encap:Ethernet HWaddr 00:50:56:a4:56:e9
inet addr:10.1.63.254 Bcast:10.1.63.255 Mask:255.255.192.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth0:1 Link encap:Ethernet HWaddr 00:50:56:a4:56:e9
inet addr:10.1.127.254 Bcast:10.1.127.255 Mask:255.255.192.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.1.1 P-t-P:10.8.1.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:477047415 errors:0 dropped:0 overruns:0 frame:0
TX packets:833650386 errors:0 dropped:101834 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:89948688258 (89.9 GB) TX bytes:1050533566879 (1.0 TB)
eth0は外部の世界に接続され、tun0はアプリケーションサーバーが配置されている仮想マシンのopenvpnネットワークに接続されます。
ip r
VPNゲートウェイの場合:
default via $outerGatewayAddress dev eth0 metric 100
10.1.0.0/18 dev eth0 proto kernel scope link src 10.1.63.254
10.1.64.0/18 dev eth0 proto kernel scope link src 10.1.127.254
10.8.1.0/24 via 10.8.1.2 dev tun0
10.8.1.2 dev tun0 proto kernel scope link src 10.8.1.1
10.9.0.0/28 via 10.8.1.2 dev tun0
$addressEndingWithAZero/26 dev eth0 proto kernel scope link src $vpnGatewayAddress
ip r
アプリケーションサーバーから:
default via 10.1.63.254 dev eth0 metric 100
10.1.0.0/18 dev eth0 proto kernel scope link src 10.1.4.20
ファイアウォールルール:
Chain PREROUTING (policy ACCEPT 380M packets, 400G bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 127M packets, 9401M bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 1876K packets, 137M bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 223M packets, 389G bytes)
pkts bytes target prot opt in out source destination
32M 1921M MASQUERADE all -- * eth0 10.1.0.0/17 0.0.0.0/0
リダイレクトの設定:
sysctl net.ipv4.conf.all.send_redirects
net.ipv4.conf.all.send_redirects = 1
sysctl net.ipv4.conf.eth0.send_redirects
net.ipv4.conf.eth0.send_redirects = 1
sysctl net.ipv4.conf.tun0.send_redirects
net.ipv4.conf.tun0.send_redirects = 1
なぜ最も仮面舞踏会パーティーは時々失敗するのですか?これが起こらないようにするにはどうすればよいですか?
答え1
コメントで説明したように、問題はsysctlnet.ipv4.conf.all.send_redirects
および/またはnet.ipv4.conf.eth0.send_redirects
0を設定すると問題が解決したように見えるため、VPNゲートウェイがICMPリダイレクトをアプリケーションサーバーに誤って送信しているようです。
VPNゲートウェイがアプリケーションサーバーに外部ゲートウェイを通過するように指示する理由はわかりません。アプリケーションサーバーは、VPNサーバーを介さないとその外部ゲートウェイに到達できません。