VPN のエンドポイントアドレスが変わったときの UFW 例外

クライアントは再接続を試みているのに、マシンからは何も出ていかない。同じプロファイルは先週まで動いていた。エンドポイントのホスト名は今や別のアドレスに解決され、外向きの例外はまだ古いほうを指している。その古びた許可がひとつあるだけで、機能していたキルスイッチは完全な不通に変わる。しかもデスクトップが示すどの状態インジケーターにもそれは現れない。修復は一行の編集ではなく、小さなワークフローだ。

トンネルは再接続し、それから何も出ていかない

宛先アドレスを名指しする外向きルールはある瞬間のスナップショットであり、DNS の応答はそうではない。プロバイダーがアドレスを切り替えると、クライアントが新しいピアへ送るパケットは何にも一致せず、既定の拒否で捨てられる。するとクライアントはタイムアウトを報告し、それはファイアウォールではなくサーバーの問題のように見える。

公開検索が返すアドレスを固定すれば、今日は動き明日は壊れる。それは一度きりの編集であり、保守の方針ではない。

実際に意図している例外を書き出す

まずルールが必要とする四つの値を書き出そう。承認済みのエンドポイント名またはアドレス集合、トランスポート、宛先ポート、そしてパケットが出ていくインターフェースだ。四つとも許可の一部であり、どれかが間違っていてもルールはもっともらしく見える。三つで正しいルールは、四つとも間違ったルールとまったく同じように失敗する。コマンドを打つ前に書き出すべきだ。ルールはその背後にある記述以上のものではない。

以下のコマンドは、有線アップリンク上の IPv4 UDP エンドポイント一つの形を示している。両方の値は、配備に対して検証したものに置き換えてほしい。

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

その許可は同じポート上の任意の宛先を認めず、リスナーも作らず、TCP も対象にしない。UFW のマニュアルページは、アドレス、インターフェース、プロトコルがルールをどう狭めるかを説明しており、その狭め方こそが要点だ。

ひとつのワークフローとして更新する

例外を、所有者と遷移を持つリソースとして扱う。誰かが実行を思い出すコマンドとして扱うのではない。まず配備自身のリゾルバーとエンドポイント台帳から候補を得て、トンネルが存在する前にその名前がどう解決されるかを意図的に定める。次に、ルールセットに触れる前に、候補を想定したプロトコル、ポート、アドレスファミリーに対して検証する。

まず新しい狭い許可をインストールし、それが読み込まれたことを確認する。ファイアウォールがまだ遮断しているアドレスを使わせようとすれば、サーバーの障害に見える失敗になるからだ。変更の間は無関係なルールに触れない。

クライアントの遷移を、サポートされた再接続経路で観察し、どのリモートアドレスを選んだかを確認する。DNS だけを更新しても既存のソケットは動かないし、エンドポイント固定の設定は、レコードが変わったずっと後までクライアントを古いピアに留めうる。

最後に、古い許可を意図的に廃止する。古いセッションがまだ活動している間は、承認済みの重複期間を認める。古いエントリーを早すぎる段階で外せば短い不通になり、永遠に残せば誰も説明できない許可が残る。

古い許可を意図的に廃止する

削除こそがリスクの大半を占める。古いルールは現在動いている唯一のものだからだ。候補のインストールが失敗したなら、先に進まず、まだ通信を運んでいるエントリーを消してはいけない。削除そのものが失敗したなら、ポリシーを最新だと宣言するのではなく、古い許可を古いままとして記録する。

アップリンクが Ethernet から Wi-Fi に変わる時、トランスポートが変わる時、あるいはサービスが複数のアドレスをまたいで回る時には、レビュー全体をやり直す。インターフェース固有のルールはネットワーク変更後に一致しなくなるのが正しく、それは後退に見えても正しい挙動だ。

その後、無害な通信で契約を証明する。承認済みのエンドポイントは設定中に到達できなければならず、保護されたアプリケーションは接続後に動作しなければならず、無関係な直接通信は障害の間ブロックされたままでなければならない。両方のアドレスファミリーと、意図的に失敗させた更新の試行を一つ含めよう。固定アドレスの一度の編集の後に成功する接続は、それらのどの場合も証明しない。