Linux ホストが ICMP リダイレクト (accept_redirects=1
問題のインターフェイス上) を受信して受け入れた場合、このルートはどのくらいの期間キャッシュされ、監視されますか? その時間を短縮できますか?
私が質問しているのは、おそらく不幸な ICMP リダイレクトから生じた偽のルートで汚染されたシステムがいくつかあるためです。
$ ip route get 10.2.2.2 10.2.2.2 via 10.2.2.2 dev eth0 src 10.1.1.2 cache <redirected>
そしてそれらは単に最後のICMPリダイレクトを受信してから12時間以上経過してもリダイレクトを忘れないip route flush cache
!エントリを削除して正しいルートを復元するには、手動で実行する必要があります。
$ ip route get 10.2.2.2 10.2.2.2 via 10.1.1.1 dev eth0 src 10.1.1.2 cache
そもそも ICMP リダイレクトがどのように、そしてなぜ送信され、受信され、受け入れられたのかはわかっていますが、この質問はそれについてのものではありません。
質問とは関係ないと思いますが、詳細は次のとおりです。
内部ネットワークは、たとえば 10.1.0.0/16 です。マシンの 1 つである 10.1.1.1 は OpenVPN サーバーで、リモート クライアントには 10.2.0.0/16 内のアドレスが割り当てられます。他の内部マシンには、静的ルート 10.0.0.0/8 --> 10.1.1.1 があります。VPN サーバーは将来的にさらに多くのクライアントにサービスを提供する可能性があるため、意図的に 10.2.0.0/16 よりも広くなっています。
残念ながら、当社の構成管理では、より広い静的ルート 10/8-->10.1.1.1 を VPN サーバー自体にもプッシュし、10/8-->eth0 として確立します。この不要なルートは通常、効果がありません。
通常の条件下では、この設定は問題なく動作します。しかし、次のようなことが起こりました。
- VPNサーバー10.1.1.1が再起動されます
- 他の内部ホスト(例えば 10.1.1.2)が、VPN サーバーの IP スタックが起動した直後に VPN クライアント(例えば 10.2.2.2)に接続しようとしますが、OpenVPN が起動する前なので、10.2.0.0/16 へのルートはまだ確立されていません。
- VPNサーバー
send_redirects=1
の内部インターフェースはeth0であり、ルートが10/8->eth0であるため、それに応じたICMPリダイレクトを10.1.1.2に送り返します。 - 10.1.1.2 は
accept_redirects=1
内部インターフェース上にあり、ICMP リダイレクトで通知されたルートをキャッシュし、必死に 10.2.2.2 の ARP 要求を内部ネットワークに送信します。
その後すぐに、VPN サーバーは VPN ルートを確立し、リダイレクトの送信を停止し、他のすべての VPN 接続は正常に動作します。
ここまでは順調です。何が起こったのか、なぜ起こったのかは理解できたと思います。短期的(内部ホスト上)および長期的な(もちろんVPNサーバー上の広いルートを削除するだけでなく、内部ホストまたはVPNサーバー上でip route flush cache
設定することもできます)さまざまな解決策を知っています。accept_redirects=0
send_redirects=0
ない私の質問。
ノート:
- Ubuntuカーネル3.13.0-141
- Ubuntu カーネル 4.4.0-116 は動作が異なるようです。宛先へのローカル ARP 要求の送信も開始する限り、ICMP リダイレクト (if
accept_redirects=1
) も受け入れます。ただし、少なくとも応答がない限り、IP パケットは元のネクストホップに送信され続け、ip route get 10.2.2.2
リダイレクトされていない元のネクストホップが表示されます。 - によるとhttps://vincent.bernat.im/en/blog/2011-ipv4-route-cache-linux、
net.ipv4.route.gc_interval
2.6.38 (2011) より前はこれを管理していたかもしれませんが、それ以降は管理していません。
答え1
ICMP リダイレクトは、gc_timeout () で指定された時間キャッシュされます/proc/sys/net/ipv4/gc_timeout
。ただし、タイムアウトは最後のアクティビティから開始されるため、状況によっては障害が永久に続く可能性があることに注意してください。
すべての Ubuntu ディストリビューションにこの機能があるかどうかはわかりません。