VPNエンドポイントの許可リスト：忘れていたDNS更新

ファイアウォール例外に vpn.example.com と入力すると、DNSを購読した気分になります。たいてい起きるのは読み込み時の変換で、そのあとルールはアドレスを保持し、何もそれらを更新しません。いまや二つの構成要素が仕事を分け合っています。答えるリゾルバーと、保存するファイアウォールです。ほとんどのエンドポイント障害は、この受け渡しが設計されなかった場所から始まります。

ルール内のホスト名は生きた購読ではない

設定の読み込み時点で名前を解決するツールもあれば、ホスト名を保持して独自のスケジュールで再解決するものもあり、アドレスしか受け付けないものもあります。見える設定がどれかを示すことはほとんどありません。ドキュメントの例はたいてい読み込み時のケースを前提にするので、移行の際にこの違いが人を驚かせます。アドレス変更が気づかれると決めつける前に、実装の振る舞いを読んでください。なぜなら、古い許可リストは、エンドポイントが移るまでは正常に動くものとまったく同じに見えるからです。

正しいホストを名指すルールでも、間違ったアドレスを許可することがあります。その隙間こそが神話であって、綴りの間違いではありません。

キャッシュのTTLはファイアウォールのタイマーではない

DNSレコードには生存時間があり、リゾルバーはその間レスポンスをキャッシュします。DNS仕様はそのキャッシュ動作を定義していますが、対象はDNSデータであり、ファイアウォールの別個のアドレス格納庫ではありません。短いTTLは、存在しない更新作業を作り出しません。キャッシュは複数の層でも起こるため、端末が見る応答はファイアウォールが見たものとは限りません。

実際の製品に三つ尋ねてください。いつ解決するのか、結果をどこに保存するのか、何が更新を引き起こすのか。答えが起動時だけなら、長命なセッションは、受け入れられたアドレスより長く生き残る可能性があります。

dig +short vpn.example.com
resolvectl query vpn.example.com

更新と失敗を一つのポリシーとして設計する

維持される例外には明示的な答えが必要です。クライアントが新しいアドレスを選ぶ前に何が更新を引き起こすのか、許可集合が広い一時的な窓を開かずにどう変わるのか、古いエントリがいつ削除されるのか。その答えをルールのそばに書きます。

失敗時の動作を意図的に選びます。古いアドレスを保持すればセッションを保てる一方で古い許可が残り、集合を空にすれば復旧が妨げられるかもしれません。どちらも失敗した問い合わせの偶然の結果であるべきではありません。選んだ動作をランブックに書き、次の運用者がプレッシャーの中で即興しないようにします。

ブートストラップDNSも狭く保ちます。公共リゾルバーへの無条件の例外は、一致するすべてへの直接DNS経路であり、エンドポイントの名前だけのものではありません。

エンドポイントの変更を証明するのであって、最初の接続ではない

クライアントが対応するマネージャーがすでに解決とブロックを調整しているなら、それを使います。サイト管理のPFホストでは、別のライフサイクル動作を持つプラットフォームからホスト名テーブルの構文をコピーするのではなく、サイトの所有権と復旧計画を保ちます。

承認された無害なテストで、管理された変更の前後でクライアントが選ぶアドレスを有効な許可集合と比較します。失敗した問い合わせ、有効でなくなったエントリの削除、対応している場合は別のアドレスファミリーを対象にします。意図したトンネルは回復し、無関係な直接トラフィックはポリシー下にとどまるべきです。最初の接続の成功は、初期の変換がたまたま正しかったことだけを証明します。