なぜ、IPsecトンネルがダウンしていてもソケットにIPsecサイトへのルートがまだ存在するのですか?

Prev Next

質問

なぜ、IPsecトンネルがダウンしていてもソケットにIPsecサイトへのルートがまだ存在するのですか?

例として、IPsecサイトはネイティブ範囲10.80.80.0/24で設定されていました


このサイトは現在ダウンしています。


CMAのモニタリング > ルーティングテーブル以下では、10.80.80.0/24ネットワークは表示されていません


しかし、Socket UIには依然としてルートが表示されています:

回答

ソケットは到達可能性をテストでき、通常は他のソケットのルーティングテーブルに存在している範囲を指しますが、到達可能な場合のみです。 そうでない場合、これらの範囲はソケットのUIのモニタリングページでグレー表示されます。 これらのPing可能な範囲はREMOTE_SITEタイプであり、ソケット間で送信されるPingによって到達可能性をテストします。

対照的に、IPsecサイトはPingを受け付けません。そのため、ソケットはこれらのリモートIPsecサイトを常に接続されているとみなし、その静的な範囲は常に到達可能です。 これらはREMOTE_RANGEとして認識されます。 これは既知の制限であり、静的REMOTE_RANGEの到達可能性はプローブできません。

ケーススタディ

顧客が以下のデザインを持っている場合、これは問題となります:

IPsecサイトは10.10.10.0/24のサブネットを持ち、ソケットサイトは10.10.0.0/16ネットワークのBGP LANサブネットを持っています。 IPsecトンネルがダウンしている時、10.10.0.0/16に宛てられたトラフィックはソケットサイトを通るべきという意図があります。 しかし、これは実現不可能です。 ソケットルートテーブルには、まだIPsecサイトを通る10.10.10.0/24ルートがあります(たとえIPsecトンネルがダウンしていても)、そのため、ソケットはパケットをドロップします。 

回避策:

  1. BGPを介して範囲10.10.10.0/24を動的に公開する

  2. または、別のサイトのネットワーク範囲と重ならないIPsecサイトでネイティブ範囲を使用する