ホストのルートに触れずに名前空間で VPN ルーティングを試す
三つの模擬ロール、三つの分離されたコンテキスト、リンクごとに一つの veth。ホストに触れる前に、名前空間ラボとホストルートラボを比較します。
二つのラボは同じ VPN トポロジーを模擬しても、まったく異なる形で失敗します。一方はネットワーク名前空間の中に住み、もう一方はホスト自身のルート上に住みます。名前空間版は各インターフェース、ルート、ソケットを削除できるコンテキストに保ち、ホスト版はより速く起動して状態を後に残します。その残った状態こそが、一か月後に二つ目のラボを再現しにくくする理由です。まず後片付けを比べてください。二回実験を実行できるかどうかは、それで決まります。
同じラボを作る二つの方法と、それぞれが勝つ場面
ホストルートラボでは、作業中のマシンにトンネルインターフェースとルートを追加するので、実験はシェル、パッケージマネージャー、その他の接続と運命を共にします。名前空間ラボでは、各ロールがインターフェース、アドレス、ルート、ソケットの独自のスタックを持ち、名前空間を削除すればすべてが消えます。どちらのモデルもより正しいわけではありません。異なる問いに答えるからです。主題がルーティングと転送なら名前空間を、一つのデスクトップクライアントがどう統合されるかならホストラボを選んでください。
| Aspect | Namespace lab | Host-route lab |
|---|---|---|
| Isolation | Full stack per role | Shares the host stack |
| Cleanup | Delete named namespaces | Manual route and rule removal |
| Realism | Strong for routing | Needed for GUI clients |
両者を混ぜるのがよくある間違いです:ホスト上のクライアントだけに対して試した名前空間ラボは、どちらの配置についても何も証明しません。最初のリンクを作る前に、自分がどの問いを立てているかを決めてください。
ロールごとに一つのコンテキストを意図的に接続する
ロールごとに一つの名前空間を作り、各 veth ペアの両端をそれを所有するコンテキストへ移します。最初の四つのコマンドで形は十分に見えます:
ip netns add client
ip netns add gateway
ip link add veth-c type veth peer name veth-g
ip link set veth-c netns clientホスト上の何とも重ならない範囲をラボに与え、開始前にどの名前空間がどのアドレスを持つかを書き留めます。動作するラボには二つの別々の経路が必要です。VPN エンドポイントが相手に届くための外側の経路と、保護されるリソースのための戻り経路であり、それらを二つの決定としてモデル化してください。出ていく半分だけを作るラボは、ハンドシェイクのテストには通り、アプリケーションのテストには失敗します。
転送ロールこそがラボを面白くする場所
一つのロールが転送する必要があり、それはその名前空間の内部で転送を有効にして設計が必要とするルールを追加することを意味し、転送の状態は名前空間ごとなのでホストの設定はラボには無関係で、ラボの設定が外へ漏れることもありません。ネットワーク名前空間のドキュメントが説明しているとおりです。WireGuard は、インターフェースとその外側のソケットが別々の名前空間に住めることを文書化しています。これは便利なトリックであり、自分を混乱させる優れた方法でもあります。インターフェースを移せば接続のすべての部分が同じように移る、と決めつけないでください。
テストパケットの後に転送カウンターを確認してください。決して一致しなかったルールと、パケットを落としたルールは、ルートテーブルでは同じに見えます。両者を分けるのはカウンターだけです。
ベースラインを記録し、それから一本のルートを壊す
まず存在するものを記録し、各行の横にコンテキストを書きます。名前空間を読み、次にテスト宛先がそのうち一つの中でたどるルートを読み、次にそれを運ぶリンクのカウンターを読みます:
ip netns list
ip -n client route get 10.0.0.5
ip -n gateway -s link show veth-g三番目のコマンドは人が飛ばすもので、そこに証拠があります。落とした数とエラーのカウンターが、パケットが転送ロールにそもそも届いたかを教えてくれます。変更後に同じ三つの見え方を記録し、証拠は自分の記憶ではなく diff にしてください。次に一つだけ壊し、ルートを削除するか、転送経路に拒否ルールを追加して、予測した症状を確認します。応答のない完了したハンドシェイク、またはタイムアウトの代わりに名前解決の失敗です。成功だけを示すラボは、ほとんど何も教えません。
後片付けが次の実行を再現可能にする
後片付けは自分が名前を付けたリソースに限定してください。包括的なファイアウォールのリセットやホストルートの削除は再現性ではなく、二つ目のインシデントです。トポロジー、正確なコマンド、期待した観察を保存すれば、次の実行は前の状態がどのコンテキストにあったかを推測せずに同じ障害を再現します。その記録がなければ、ラボは手順ではなく物語です。
ラボにはローカルで生成した資格情報を使い、本番アカウントは共有の例から外してください。次に各名前空間を削除し、ホストの見え方が変わっていないことを確認します。これがこのモデルを選ぶ理由のすべてです。きれいに削除できないラボは、手順が増えただけのホスト変更です。