あなたの VPN ゲートウェイには今も更新を入れる道が要る

トンネルはその後ろにいる全員のために機能し、ゲートウェイは彼らの通信を転送しているのに、マシン自身はセキュリティ更新をインストールできない。これが問題のよくある形だ。転送の許可はクライアントに与えられたが、ゲートウェイ自身の外向き接続は計画に含まれていなかった。パッケージマネージャーはゲートウェイから自分自身のソケットを開き、ファイアウォールポリシーのどこにも名前を書いていないであろうリポジトリへ向かう。

ゲートウェイを閉じることは正しい。パッチを受け取れなくなるほど厳しく閉じるのは別の判断であり、たいていは意図しないものだ。

ローカル出力はクライアント転送ではない

転送ルールが扱うのは、別の場所から到着しゲートウェイを通って出ていくパケットだ。ゲートウェイ自身の更新通信はそれらに決して一致しない。ローカルで生成され、出力経路を通るからだ。この違いが、クライアントのアクセスが完璧に動いているのに不可能に見える故障を説明する。

テストをすり抜けるポリシーの隙間も説明できる。トンネルの後ろのノートPCから素早く確認しても、転送チェーンが動いていることしか分からず、ホスト自身の接続については何も語らない。ゲートウェイを二人の主体として扱う。転送チェーンを持つルーターと、出力チェーンを持つホストだ。どちらにも方針が要るが、普段書かれるのは片方だけだ。

失敗した段階を名指しする

更新のエラーは異なる境界を指す。どれが失敗したかを読む前にポートのルールへ飛びつくと、半日を無駄にする。解決できないリポジトリ名はリゾルバーの問題であり、転送の問題ではない。

getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update

解決に成功した後のタイムアウトは、問いを転送へ移す。パッケージマネージャーが実際に試したのはどのアドレス、どのポート、どの設定済みプロキシか。TLS 検証の失敗は第三の、まったく別の事柄であり、接続が交渉できるほどには機能したという意味だ。 アーカイブ認証に関する訴えは第四の段階だ。到達性ではなく署名済みメタデータに関わる。四つの段階、四つの異なる修理、そして ping が示すのは、どのパッケージマネージャーも使わない一つのプロトコルだけだ。

ルールを足す前にソース一覧を読む

覚えているものではなく、実際のソース URI と有効なプロキシ設定を並べる。ソースが HTTPS なのに平文 HTTP 向けのルールを書いても無意味であり、シェルが知っているプロキシは、別の環境で起動時に動くサービスには見えないことがある。

APT の HTTP トランスポートの文書 は環境と APT 固有のプロキシ設定を扱い、ホストごとの選択も含む。その HTTPS トランスポートには独自の検証設定がある。ブラウザーが通る道とパッケージマネージャーが通る道は、同じマシン上でも別の道だ。

ソースがどのアドレスファミリーへ解決されるかに注目する。IPv4 だけを許すルールは、ソースが AAAA レコードを好むホストで失敗し続ける。どちらの応答が先に届くかで決まるため、エラーは断続的に見える。

保守の経路を一つ選び、それを保つ

擁護できる選択肢は三つある。トンネル経由の保守通信、管理された更新プロキシ経由、あるいは狭い直接の例外だ。意図して一つ選び、リゾルバーをそれに合わせる。名前は一方へ解決し接続は他方へ向かうという分裂は、誰にも説明できない故障を生む。

何を選ぶにせよ、無制限の逃げ道にしてはならない。トンネルが落ちているとき直接の外向き通信を禁じているなら、黙ってすべてを許す保守の例外は、修正の姿をしたポリシー変更だ。トンネル自身の端点とブートストラップの要件は、リポジトリへのアクセスとは別の分類に置く。行き先が違い、失敗の仕方も違うので、片方の免除でもう片方は覆えない。

検証を弱めずに確認する

すでにポリシーを持つファイアウォールを通して範囲を適用する。ある手引きが使ったからといって二つ目の管理ツールを足さない。そのうえで維持されたポリシーの下でメタデータの更新と実際のパッケージ操作を一度行い、終了状態だけでなく出力を読む。

転送の成功は検証を緩める許可ではない。アーカイブ認証と TLS サーバーの同一性は別々の保証であり、エラーを黙らせるためにどちらかを切るのは、何を信頼するかを変えることであって、何に届くかを変えることではない。

最後に、トンネルがない場合を意図して試す。トンネルなしでゲートウェイがどう振る舞うかを知るのは設計の一部であり、障害の最中に知ることではない。トンネルを落とし、メタデータの更新を実行し、ホストが意図したとおりに失敗することを確認する。黙って開いた経路へ戻ってはいけない。リポジトリとプロキシの資格情報は共有の診断から外し、更新経路の持ち主が誰かを記したメモを残す。