Firebox のジオロケーション拒否: まず VPN 入口の段階を特定する

別の国にいる人物が接続できず、最初の直感は内部リソースへのアクセスを許可するルールを見ることです。そのルールは受け入れの後に実行されるため、トンネルを拒否しているものではありえません。遮断している段階は入口経路のどこかにあり、Firebox には VPN サービスに応じて複数の入口経路があります。チェックは順番に行い、どれかが拒否を説明した時点で止めてください。

チェック 1: 受信サービスを特定する

SSL 付き Mobile VPN、Access Portal、TLS 上の BOVPN では、受信側の入口は WatchGuard SSLVPN ポリシーです。意図した制限は、後から実行されるユーザーアクセスルールから推測するのではなく、実際に設定されているサービス側で適用します。

IPsec は別の経路を通ります。組み込みの IPSec ポリシーは、該当するブランチおよびモバイル VPN サービスについて外部 IPsec トラフィックの Firebox への到達を許可し、手動作成の IPSec ポリシーより優先されます。クライアントが IKEv2 なら、あなたはその経路にいて、SSLVPN ポリシーは無関係です。

ここで間違えると、この分野で最もよく失われる午後になります。パケットを一度も見ないポリシーを編集し、制限が機能しないと結論づけてしまうのです。

チェック 2: 理論ではなく拒否を読む

制御された許可済みの試行を一度行い、四つの点を突き合わせます。クライアントの公開送信元アドレス、到達した入口サービス、一致したポリシー、ログにある拒否理由です。WatchGuard の IKEv2 トラブルシューティングガイドは、ジオロケーションと既定のパケット処理が組み込みポリシーの受け入れ前にトラフィックを拒否できると述べており、目にしている拒否が、検討していなかった段階を指している可能性があります。

国の分類は観測されたネットワーク送信元に従います。ローミング中のユーザー、上流の NAT、別の承認済み経路は Firebox が見るものを変えるため、ユーザーの所在地の説明ではなくアドレスを確認してください。クライアントが見ている公開アドレスを聞き、Firebox のログにある送信元と比較します。両者が異なる場合、分類は誰も言及していない経路に従っています。

チェック 3: 今も組み込みポリシーが所有者か

手動の IPSec ポリシーが無視されているように見える場合は、組み込みのものが今も有効かを確認してください。優先度の高い組み込みルールに隠された手動ルールと、唯一の受け入れである手動ルールは、見た目が同じインターフェースを持つ別の構成です。

どちらに経路を所有させるかを決めます。手動ポリシーなら、そのトラフィックに対して組み込みを無効にする必要があり、次のチェックはそこから始まります。

チェック 4: 無効化の前に置き換えを計画する

組み込み IPSec ポリシーを無効にすると、影響を受ける VPN サービスへの受け入れが失われます。これには、モバイルユーザー一人の接続を直している間に意識していないブランチトンネルも含まれます。

まず、どのサービスに受け入れが必要か、どの送信元範囲が割り当てられるか、変更が失敗した場合に機器をどう管理するかを含めて、完全な置き換えを計画します。ここでの誤りは修正に使うはずのトンネルを失わせかねないため、独立した管理と復旧の経路を確保しておいてください。変更記録には復旧手順を書き、VPN 経路が失われた場合に機器へ到達する方法も含めます。そのうえで、最初の接続だけでなく更新も試験します。

稼働中の接続とその後の再ネゴシエーションは、どちらも受け入れに依存し得ます。試験したセッションでは機能し、次の鍵更新で失敗する変更は、更新を試験せずに受け入れを置き換えたときの典型的な結果です。

チェック 5: 身元と場所を分けておく

ジオロケーションは入口判断に文脈を加えます。ユーザーが誰かを確定するものではなく、ゲートウェイの身元確認、アカウント認可、MFA の代わりにすべきではありません。

業務要件が承認された場所からの承認済みユーザーだけなら、両方の制御が必要です。国全体を許可する場所ルールは認証の代わりにならず、遮断された国の認証済みユーザーはポリシーの問題であり、不具合ではありません。

チェック 6: 記録し、両方の経路を検証する

サービス、入口ポリシー、意図した場所の範囲、例外、復旧の責任者を書き留めます。そのうえで変更後にモバイル経路と少なくとも一つの拠点経路を試験し、制限が本来制御すべきサービスに結び付いたままにします。

最後に、最初に見た拒否をもう一度読みます。場所による拒否から認証または認可の失敗に変わっていれば、入口の問題は解決し、別の問題が見えている状態です。上記の段階順序については IKEv2 の拒否に関する WatchGuard のガイダンス が参考になります。