web-dev-qa-db-ja.com

間違ったエントリでキャッシュを埋めるルート

非常に特殊な状況でプライベートネットワークトラフィックがマスカレードされないという問題があります。

ネットワークは、10.1.0.0/18ネットワークを使用するVMwareゲストのグループです。

問題のあるホストは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は外の世界につながり、tun0はアプリサーバーが置かれているVMの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
4
greg0ire

私はこれを尋ねました どこか他の場所 、そして解決策はICMPリダイレクトをオフにすることでした。

0
greg0ire

残念ながら、あなたが見ているもののほとんどは外部ルーター間のルーティングの問題によるものであり、問​​題のあるエリアの周りのトラフィックをルーティングするのに役立つように、ルーターはルーティング情報を動的に取得して更新しますが、それらのルートが頻繁に変更されると(通常は可用性のため)ルートフラッピングと呼ばれます。それはあなたに反映されています、通常エンドユーザーはこれのどれも見ません。

説明されているように、ルートキャッシュを無効にしようとすることもできます ここ (注意点に注意してください、それは良い面で多くを提供するようには見えません)、しかし私はあなたがただ話している方が良いと思いますルーティングが非常に不安定であると思われるため、ローカルのネットワーク管理者。

もちろん、私はあなたがネットワーク管理に責任を負わないことを前提としています。

3
NickW

10.1.4.20のルーター/ L3デバイスを誰かまたはあなたに見てもらいます。アップストリームピアから不正なルートを受信して​​いる可能性があり、そのルートは撤回されてから再アドバタイズされているようです。

3
Couradical