Заполнение кэша маршрутов неправильными записями

У меня проблема с трафиком частной сети, который не маскируется при очень специфических обстоятельствах.

Сеть представляет собой группу гостей 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-шлюза (без lo тоже):

 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 ведет к внешнему миру и настраивается на сеть виртуальных машин 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
Источник

3 ответа

Решение

Я спросил это где-то еще, и оказалось, что решение было отключить перенаправления ICMP.

Источник

К сожалению, большая часть того, что вы видите, связана с проблемами маршрутизации между внешними маршрутизаторами, они получают и обновляют свою информацию о маршрутизации динамически, чтобы помочь маршрутизировать трафик вокруг проблемных областей, но когда эти маршруты часто изменяются (обычно из-за доступности), это называется колебание маршрута. Это отражается на вас, обычно конечные пользователи не видят ничего подобного..

Вы могли бы попытаться отключить кэш маршрутов, как объяснено здесь (обратите внимание на предостережения, это не то, что может принести много пользы), но я думаю, что вам будет лучше просто поговорить с сетевыми администраторами локально, как кажется, что их маршрутизация действительно нестабильна.

Я, конечно, исходил из того, что вы не несете ответственность за сетевое администрирование.

Источник

Попросите кого-нибудь или вас взглянуть на устройство маршрутизатора /L3 в 10.1.4.20. Похоже, что он может получать плохие маршруты от вышестоящего однорангового узла, которые затем удаляются и затем рекламируются.

Источник
Другие вопросы по тегам