У меня проблема с тем, что трафик частной сети не маскируется в определенных обстоятельствах.
Сеть - это группа гостей VMware, использующих 10.1.0.0/18 сеть.
Проблемный хост 10.1.4.20 255.255.192.0 и единственный шлюз, который он настроен для использования, это 10.1.63.254. Сервер шлюза 37.59.245.59 должен маскировать весь исходящий трафик и перенаправлять его через 37.59.245.62, но почему-то 10.1.4.20 иногда заканчивает 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
Вопрос в том, почему я вижу публичный IP-адрес в моем кэше маршрутизации в частной сети?
Сетевая информация для сервера приложений (без 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-шлюза (тоже без ло):
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 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 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
Попросите кого-нибудь или вас взглянуть на маршрутизатор / устройство L3 по адресу 10.1.4.20. Похоже, он может получать неверные маршруты от вышестоящего партнера, которые затем удаляются, а затем повторно объявляются.
К сожалению, большая часть того, что вы видите, происходит из-за проблем с маршрутизацией между внешними маршрутизаторами, они получают и обновляют свою информацию о маршрутизации динамически, чтобы помочь маршрутизировать трафик в проблемных областях, но когда эти маршруты часто меняются (обычно из-за доступности), это называется колебанием маршрута. Это отражается на вас, обычно конечные пользователи ничего этого не видят.
Вы можете попытаться отключить кеш маршрута, как описано Вот (обратите внимание на предостережения, это не то, что, кажется, дает много преимуществ), но я думаю, вам лучше просто поговорить с сетевым администратором (ами) локально, поскольку кажется, что их маршрутизация действительно нестабильна.
Я, конечно, исхожу из предположения, что это не вы отвечаете за администрирование сети.
Я спросил это где-нибудь еще, и оказывается, решение заключалось в отключении перенаправления ICMP.