OpenVPN を TAP から TUN へ: 機能する移行手順

dev tap を dev tun に替えると、トンネルが運ぶものが変わり、変わるのは名前だけではない。TAP インターフェースは Ethernet フレームをブリッジに渡すので、クライアントはオフィスのスイッチにつながれているように振る舞う。TUN インターフェースは IP パケットを運ぶので、クライアントにはルートが、反対側には戻り経路が必要になる。クライアント、アドレス計画、LAN の戻りルートは、すべてこの変更に合わせて動かす必要がある。

この移行はトンネルを伴うネットワーク再設計であり、以下の順序なら巻き戻せる。

Ethernet に実際に依存しているものを棚卸しする

ホストではなくアプリケーションを列挙する。それぞれがルーティングされた TCP や UDP サービス、ブロードキャストによる検出、オフィス LAN からの DHCP、IP 以外の Ethernet プロトコル、両端が同じサブネットにあるという前提のどれを使うかを判断する。通常の IP アクセスはルーティング設計でも生き残る。生の Ethernet フレームを必要とするプロトコルは生き残らず、どれだけルーティングしても動かない。検出に依存するアプリケーションには、切り替えの前に決めた代替手段が必要で、切り替え中に決めるものではない。

この棚卸しは受け入れリストでもある。移行できない項目は、文書化された例外になるか、そのワークロードのためだけに小さな TAP セグメントを残す理由になる。

アドレスと戻り経路の計画を立てる

LAN、古いブリッジの範囲、クライアントがすでに到達するネットワークのどれとも重ならないクライアント用プレフィックスを選ぶ。dev tun、topology subnet と server 10.78.0.0 255.255.255.0、しかしこれは断片であり、動作するプロファイルではない。その周りに承認済みの TLS、ID、トランスポート、アクセス方針を保ち、空いていることを確認したプレフィックスを使う。

次に、クライアントが到達すべき宛先と、戻り経路を誰が提供するかを書き出す。サーバーには転送の有効化と、許可された先への経路が必要だ。LAN のルーターには新しいプレフィックスへの戻りルートが必要であり、そうでなければ設計に送信元変換とそれに伴う可視性のコストが必要になる。クライアント設定に送られるルートはクライアントを設定するのであって、LAN の応答経路を設定するのではない。

別のリスナーで試験する

動いている唯一の入口を置き換えるのではなく、新しいサービスを古いものの隣に、専用のポートと専用のアドレス範囲で立ち上げる。パイロット用プロファイルは既存の登録手順で発行し、移行のために誰も CA を作り直さないようにする。代表的なクライアントを一台、パイロット経路だけ有効にして接続し、割り当てアドレス、プライベート DNS、棚卸しのアプリケーション、遮断されたままであるべき経路を比較する。

再接続と戻りトラフィックのテストも含める。ハンドシェイクが完了しても、反対側が応答できるかどうかは分からない。

クライアントをグループ単位でロールバック付きで移す

失敗が障害ではなくサポート作業で済む程度に小さいグループで移行する。各グループの実際の業務フローが通るまで古いサービスを稼働させ文書化しておき、ロールバックは再構築ではなく以前のプロファイルへの切り戻しとして書く。グループが移るたびに、アドレスベースのファイアウォール規則、監視、サーバー側から開始されるアクセスを新しいプレフィックス向けに更新する。

グループは、古い経路がまだ比較のために残っている間に、誰も言わなかったアプリケーションを見つける場所にもなる。

受け入れ後にだけブリッジを廃止する

TAP デバイスの削除は最初ではなく最後の手順だ。何かを削除する前に、ブリッジがまだサーバーの管理アドレス、監視経路、無関係なワークロードを運んでいないか確認する。起動時の依存関係、ブリッジのメンバーシップ、DHCP の予約を、その順に所有者を通じて廃止し、何を外したかを記録する。

移行が終わるのは、ルーティングされたアクセスモデルが棚卸しに対して機能したときであり、ip link の出力から TAP インターフェースが消えたときではない。