セントラルオフィスには、いくつかのリモートオフィスのハブとして機能するSonicWALLNSA-2400アプライアンスがあります。 DHCP要求を内部DHCPサーバーに渡すように構成されています。 VPN接続は正常に機能し、IPアドレスは必要に応じてリモートオフィスに配布されます。1つのリモートオフィスを除いて、結果に非常に満足しています。
先週の金曜日、私はNSA-2400の弟であるNSA-240をリモートオフィスに設置しました。両方のファイアウォールは常に堅固な接続を報告し、トンネルを介したネットワーク接続のすべての側面が正常に機能しています。私の問題は、これまでのところ、毎朝、リモートオフィスから電話があり、ネットワークにアクセスできないと言われることです。いずれの場合も、会社のDHCPサーバーから渡されたIPアドレスを失い、「ジャンク」169.xxxアドレスが与えられています。
ファイアウォールを再起動してDHCPリースを更新すると、問題はすぐに修正されます。最初にファイアウォールを再起動せずにDHCPリースを更新すると、失敗します。
キープアライブは両方のファイアウォールで有効になっています。
明らかに、ある程度の非アクティブ状態の後、IPアドレスは期限切れになります。誰かが私のためにこれにいくつかの光を当てることができますか?
詳細については編集:この時点で、8時間の稼働時間後にリモートサイトのIPアドレスに障害が発生したと判断しました。ログは、この頃のARPパケットの障害を示しています。繰り返しになりますが、8時間経過した後でも、トンネルは両方のファイアウォールで安定しており、DHCPによって割り当てられたIPアドレスのみが失われます。私は今朝7:45にリモートファイアウォールを再起動し、接続を修復してもらいました。そのため、4:45に別の電話があり、インターネットがダウンしていることを知らせます。
トラブルシューティングを提供してくれたすべての人に感謝します。これが私の問題の解決策でした:
リモートオフィスのファイアウォールが競合する設定で構成されていました。一方では、ファイアウォールを介して企業のDHCPサーバーからIPアドレスを取得して配布することになっていた。一方、トンネルに障害が発生した場合にローカルIPアドレスを提供するように構成されていました。
さらに調査した結果、リモートクライアントは最後にファイアウォールを再起動してからちょうど8時間後にIPアドレスを失ったと結論付けました。 8時間は28,800秒、つまりIPSecトンネルのデフォルトの有効期間です。
基本的に、2つのファイアウォールは8時間ごとに、暗号化を再ネゴシエートします。この再ネゴシエーションには2秒以上かかり、リモートファイアウォールはトンネルが壊れていると判断し、ローカルIPアドレスをクライアントに渡そうとします。トンネルネゴシエーションは数秒後に成功し、トンネルは両端で強力になりますが、リモートクライアントには無効なIPアドレスがあります。
169.X.Y.Z APIPAアドレスは、コンピューターとDHCPサーバー間の接続がないためにのみ表示されます。
簡単な回避策(ただし、問題がないわけではありません)は、問題の診断中に静的アドレスを構成することです。
診断するには、問題のあるコンピューターの1つを取得し、ファイアウォールログを監視しながらIPアドレスを更新します。または、ユーザーが到着したとき、またはシステムがDHCPリースを更新したときに、ファイアウォールログを確認するだけです。
問題が発生し始めた理由はわかりませんが、DHCPスコープ全体の指定されたセグメントをリモートデバイスで処理することにより、DHCPを分割することをお勧めします。これにより、少なくともリモートネットワークの実行を維持する限り、サイト間の接続に問題が発生した場合のバックアップも提供されます。
Sonicwallサポートサイトには、ドキュメントsite_to_site_vpn_troubleshooting_on_sonicwall_security_appliances.pdfがあります。
このタイプのシナリオをトラブルシューティングする手順を説明します。