私人networkingstream量在非常特殊的情况下没有被伪装。
该networking是使用10.1.0.0/18networking的一组VMware客户端。
有问题的主机是10.1.4.20 255.255.192.0 ，它configuration使用的唯一的网关是10.1.63.254 。 网关服务器37.59.245.59应该伪装所有出站stream量并通过37.59.245.62转发，但由于某种原因， 10.1.4.20偶尔在其路由caching中有37.59.245.62 。
ip -s route show cache 199.16.156.40 199.16.156.40 from 10.1.4.20 via 37.59.245.62 dev eth0 cache used 149 age 17sec ipid 0x9e49 199.16.156.40 via 37.59.245.62 dev eth0 src 10.1.4.20 cache used 119 age 11sec ipid 0x9e49 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
问题是，为什么我在专用networking的路由caching中看到一个公共IP地址？
应用程序服务器的networking信息（不含）：
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网关的networking信息（不含太）：
eth0 Link encap:Ethernet HWaddr 00:50:56:a4:56:e9 inet addr:37.59.245.59 Bcast:37.59.245.63 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 PtP: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通向外部世界，并且通向一个位于应用服务器上的虚拟机的openvpnnetworking。
ip r为VPN网关：
default via 37.59.245.62 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 37.59.245.0/26 dev eth0 proto kernel scope link src 37.59.245.59
在应用程序服务器上运行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
不幸的是，你所看到的大部分是由于外部路由器之间的路由问题，他们dynamic地获取和更新他们的路由信息，以帮助路由问题区域的交通，但是当这些路由经常变化（通常由于可用性）叫路线扑。 这反映到你身上，通常最终用户不会看到任何这个..
你可以尝试禁用你的路由caching，正如这里所解释的（请注意，注意，这似乎并没有提供太多好处），但是我认为你最好是在本地与networkingpipe理员交谈，这似乎是他们的路线，这是非常不稳定的。
我当然假设你不负责networkingpipe理。
请有人或你在10.1.4.20查看路由器/ L3设备。 看起来它可能正在接收来自上游节点的不良路由，然后被撤回然后重新公布。
我问了这个地方 ，结果是解决办法是closuresICMPredirect。