VPN を設定する前にパケットの経路を書く

VPN の構築のほとんどはクライアントとプロファイルから始まり、トンネルが上がった頃にはどのパケットがそこを通るはずだったのか誰にも言えない。最初の一枚の作業は三時間目のデバッグより安く、設定ファイルができる前に意図した接続を一つ、紙の上で端から端まで書き出そう。この作業は、要件がインターネットへの出口なのか、サブネットへの遠隔アクセスなのか、二つの拠点を結ぶ回線なのか、といったまだ問うていなかった疑問をたいてい片づける。

始めるには接続一つで足りる。トポロジーの三枚はたいてい同じ欠けた答えを隠している。

図ではなく、一つの要求を書く

送信元とは、アドレスの範囲、アドレスの種類、そして通信を生むアプリケーションのことだ。次に宛先のプレフィックスとその上のサービスをポートとプロトコルまで名付けるのは、サブネットは許すがサービスは許さない規則が何もしない規則だからだ。二つのアドレスが肝心で、その下のすべてはそれに合わせる仕組みである。

経路として順に、物理リンク、両端の VPN 端点、トンネルそのもの、その先のネットワークを並べる。インターフェース名を知っているなら、その細部が後でルーティングテーブルと比べられる記述に変えるので書いておく。各インターフェースがトンネル側で使うアドレスも加える。この二つの事実がなければ、ほかの誰も記録を機器と照合できない。

次に、意図した一つの接続をページの一番上で一文に書く。その文に「または」が必要なら、設計は二つあり、別々に扱うべきだ。

要求より先に応答を追う

外向きの方向だけを書いた経路は文書の半分だ。応答を逆にたどり、どの機器が送信元の範囲を知っているか、変換が出口で送信元を変えるか、戻りのパケットがどこから入る想定かを見極める。 多くの構築が失敗するのは応答の側だ、要求は観察しやすいが、応答はそうではないからだ。

アドレス変換があれば、どこで起きるか、遠い側がその後何を見るかまで明記する。一つのアドレスを記録しながら別のアドレスへ経路を向ける相手は、二つの異なる設計を語っている。

名前解決はアプリケーションの経路の一部ではなく、独立したやり取りとして扱う。内部のレコードはトンネル経由でしか届かないリゾルバーを必要とすることがあり、アプリケーションのプレフィックスで止まる経路記録はそれを明らかにしない。内部の認証局に届くことに依存する証明書の検証も同じだ。

すべての決定に持ち主を与える

経路、ファイアウォール規則、セレクター、資格情報のそれぞれについて、どの設定がそれを保持し、誰が変更できるかを書く。一行ごとの持ち主が最初の変更要求を文書が生き延びる理由で、そうしなければ意図を書いた文書と履歴を語るネットワークが残るだけになる。

一つの既定値に二人の持ち主がいないか注意する。クライアントスクリプトとネットワークマネージャーは互いを知らないまま経路を入れることがあり、ゲートウェイでの待ち受け許可は転送の許可と同じではない。どちらの場合も、紙の上では正しくケーブルの上では誤った経路記録ができる。

値があなたではなく提供者に決められているなら、同じ行にそう書く。ホスティング会社が委任したプレフィックスは、自分で選んだものとは変更手続きが違う。その注記は、障害のときに次の技術者がサポート窓口を開く手間を省く。承認した変更がなぜ効かなかったのかも説明できる。

何が壊れ、どう戻るかを書く

経路の各段階について、トンネルが消えたときに何が止まるか、直すためにどの外向き接続が届いたままでなければならないかを述べる。トンネルと一緒に管理アクセスまで失う設計は、現地訪問が要る設計だ。

全トンネルと分割トンネルは、失敗の仕方と復旧の道の両方が変わるため、チェックボックスではなく明示的な選択としてこのページに属する。

各段階に無害な試験を一つ名付ける

端点への到達、トンネルの確立、非公開アドレス、非公開の名前、アプリケーションの許可は五つの別の観察であり、どれも別のものと取り違えられない試験を必要とする。ゲートウェイへの ping が証明するのはせいぜい最初の二つだ。アプリケーションのポートへの接続は、名前が意図したリゾルバーで解決されたときに限り四番目と五番目を証明する。

試験は、それが覆う段階の隣に、コマンドと期待する出力とともに書く。正確な経路の一枚は、どのパケットに効かせるつもりだったかを決して言わないコマンドの一枚に勝る。