PPP ベースの VPN から、その前提をコピーせずに移行する

VPN の移行は、ユーザー、宛先、名前解決、障害時の挙動がすべて正しいままで終わるものであり、新しいクライアントが緑のアイコンを表示した時点で終わるものではない。古い PPP ベースの環境は、唯一の本人確認も兼ねていた共有シークレット、ファイアウォールが許可リストに入れている固定アドレスプール、サーバーが配布する DNS サフィックスといった、文書化されなかった前提を抱えている。これらの前提を棚卸しせずにプロトコルを置き換えると、ハンドシェイクは通るが境界が存在しないトンネルができる。以下の順序は私が使っているもので、最後の手順は多くのチームが飛ばすところだ。

ステップ 1：古い接続が提供しているものを棚卸しする

棚卸しは記憶ではなく記録する。対応クライアント、認証の役割、アドレスプール、保護対象ネットワーク、DNS 要件、そして各利用者層が必要とするサービス権限を書き出す。

L2TP/IPsec では、二つの層を明示的に分ける。IPsec のピア ID はマシンを認証し、PPP はユーザーを認証する（通常は CHAP か MSCHAPv2）。

古い環境が前提を隠すのは、まさにこの分離の部分である。 全クライアントが共有する事前共有鍵は、デバイスではなくグループを認証する。そして多くの場合、それがこれまでに更新された唯一のものだ。PPP アカウントが実質的なユーザー単位の制御なら、置き換え側は共有文字列ではない何かでその制御を再現しなければならないと明言し、固定の送信元アドレスとローカルネットワークの例外も記録しておく（これらは壊れるまで誰も文書化しない依存関係だ）。

ステップ 2：置き換えを意図的に設計する

置き換えの選択は要件ごとの対応づけであり、組織がサポートするプロトコルと保守されたクライアントを選んで、ID とアクセスの各要件を実際の仕組みに落とし込む。共有シークレットは自動的にデバイスごとの鍵や証明書と等価ではなく、ユーザー単位の PPP アカウントはデバイス証明書と等価ではない。

自宅やオフィスの LAN と重なる置き換えプールは暗号の強度とは無関係な障害を生むため、アドレス範囲は何よりも先に調整する。プールは古いサービス用に作った同じリストに照らして確認し、さらに新しいクライアントが既定で想定するものも加える。保護対象ネットワークの戻りルーティングを確認し、新しいクライアントが古い側の DNS サフィックスを配布または文書化できることを確認する。この二点は、プロトコルの変更そのものより多くの移行チケットを生む。

ステップ 3：段階的に導入し、許可と拒否の両方を検証する

代表的なユーザー一名と代表的なアプリケーション一つで段階導入する。テストにはプライベート DNS の名前解決を含める（アドレスには届いても内部名を解決できないトンネルは、半分しか移行できていない）。想定される利用不可の状態、つまりトンネルが切れたときに何が起きるべきか、クライアントがそれを強制するかどうかも含める。

次に、拒否されたままであるべき宛先を試す。広い一時許可ルールは、新しいトンネルを健全に見せる一方で、古いサービスが適用していた認可の境界を静かに取り除き、監査まで誰も気づかない。同じクライアントから、同じセッションで、許可と拒否の結果を並べて比較する。両方の列が設計と一致するまで、古いサービスは動かしておく。

管理者アクセスを移す前に、変更中のトンネルに依存しない承認済みの復旧経路があることを確認する。

ステップ 4：古い ID を廃止する

古い ID を正しく廃止するとは、不要になったユーザーとデバイス資格情報を所有するサービス側で失効させ、依存がなくなってから古いプロファイルとリスナーを削除することである。ローカルファイルの削除は別の場所のコピーを失効させず、古い共有シークレットを今も受け入れるリスナーは監視されていない扉だ。

この点は立ち止まる価値がある。ノート PC から外したクライアントプロファイルは失効した資格情報ではなく、資格情報はサーバー上にあり、サーバーが受け入れをやめるまで有効なままだ。試験用デバイス、忘れられた携帯、誰かが取っておいたインストーラーなど、古い設定の他のコピーを探し、リスナーの停止を古いサービスが本当に終わる瞬間とみなす。それまでは、移行には表の扉が二つある。

受け入れ記録は、最初の手順の棚卸しに一列を足したもので、新しい設計が各行に対して何をするのか、どう検証したのかを書く。これでプロトコルの更新は、根拠を伴うサービス要件になる。

成果はプロトコル名ではなく、サービスが必要とするものに結びつけておく（古い前提をコピーした現代的なプロトコルは、枠組みが良くなっただけで同じリスクである）。RFC 3193 は L2TP を IPsec 上で運ぶ方法を説明しており、二つの層が常に別々の判断だったことを思い出させてくれる。棚卸しに説明できない行があれば、止まって何がそれに依存しているかを突き止める。一覧が退屈になったとき、移行は完了している。