ルーティングまたは DNS に関連すると思われる奇妙な問題が発生しています。
当社では、Unifi 機器 (UDMP) を使用した「ハブ アンド スポーク」トポロジを採用しています。各サイトは、IPSEC トンネル経由で VyOS を実行する AWS EC2 インスタンスに接続し、サイトと AWS 内の他のインフラストラクチャ間のコア ルーティングを処理します。
以前、オンプレミス サーバーをいくつか備えたハイブリッド トポロジを採用していたときは、各サイトには古い VoIP サーバーに必要な、メイン オフィスに接続する別の IPSEC トンネルがあり、オンプレミスの DNS サーバーもいくつかありました。
その後、すべてのインフラストラクチャを AWS に移行したため、本社への 2 番目の IPSEC トンネルは不要になりました。本社に接続するサイトのトンネルのほとんどを停止しましたが、他のサイトではすべて正常に動作しています。トンネルを停止するたびに問題が発生するサイトが 1 つ残っています (サイト 3)。
問題: 「サイト 3」と本社の間の IPSEC トンネルを切断すると、10 分ほどは正常に動作しますが、その後、ユーザーが「インターネットが使えない」と文句を言い始めます。おそらく古いオンプレミス DNS サーバーをまだ使用していると判断したため、プライマリ DNS サーバーを AWS の DNS サーバーに切り替え、Google DNS をバックアップとして使用しました。問題ありません。すべて正常に動作しています。トンネルを再度切断すると、電話がかかってきます。今度は、ユーザーがマップされたドライブ (AWS のファイル サーバー) が失われたと言います。
奇妙なのは、本社への IPSEC トンネルが稼働しているときは、すべて正常に機能していることです (サイト 3 の AWS への接続)。IPSEC トンネルを停止すると、おそらく 10 分ほどは機能しますが、その後機能しなくなります。サイトはトンネルを介して本社にルーティングされ、その後 AWS にルーティングされていると思われますが、そうではありません。サイト 3 のクライアント マシンからの traceroute には、EC2 インスタンスに接続するための 3 つのホップ (WAN から VyOS IP、サーバー IP) が示されています。サイト 3 のクライアント マシンのルーティング テーブルを見ると、AWS ネットワークのエントリがないため、トラフィックは UDMP ゲートウェイの 0.0.0.0 に送信されます。サイト 3 UDMP のルーティング テーブルを見ると、AWS VPC ネットワークのエントリが 1 つ (172.30.0.0/16) あり、次のホップは VyOS ルーターであることが示されています。
1 つの興味深い点は、すべてが ICMP/ping への応答を許可するように設定されているにもかかわらず、UDMP も vyos ルーターも互いに、または ec2 インスタンスに ping できないことです...ただし、site3 ネットワーク上のクライアントはすべてに ping できます。
EC2 インスタンスのセキュリティ ルールを確認しましたが、必要なネットワークと WAN IP がすべて含まれています。
site3 udmp が静的 WAN IP で構成されているのに、「ルーター」および追加の IP アドレスの構成設定も設定されていることに気付いたとき、私はまったくアイデアがありませんでした。詳細は次のとおりです。
WAN IP=108.x.69.250
subnet mask: 255.255.255.248
Router: 108.x.69.249
Additional IP addresses: 108.x.69.251/32, 108.x.69.252/32, 108.x.69.253/32, 108.x.69.254/32, 108.x.69.255/32
AWS/EC2 のセキュリティ ルールを見ると、108.x.69.250/32 は許可されていますが、サブネット内の他の IP (ネクスト ホップ ISP ルーターまたは追加の IPS) は含まれていないことがわかりました。AWS セキュリティで許可されているエントリを 108.x.69.248/29 に変更しましたが、これは当てずっぽうです。これで問題が解決するかどうかは自信がありません。
誰か何か考えやアイデアはありますか? 営業時間外まで再度テストすることはできませんが、状況について他の人の意見を聞けるかもしれないと思いました。静的 WAN で UDMP を使用し、ルーターと追加の IP 用にこれらの追加フィールドも設定した経験のある方はいますか?
読者の皆様に楽しんでいただけるよう、トポロジーの美しい図を掲載しました。
答え1
WAN /29 ネットワーク上の追加の IP を AWS アクセス グループに追加することで、この問題が解決したと思います。