WireGuard の中に企業 VPN を重ねる：どちらの層を先にするか

一台の端末で二つのクライアントが動くのは、外側のトンネルが内側クライアント自身の接続を運び、メトリックがプレフィックスごとに正しいインターフェースを選ぶ場合だけです。

開発者のノート PC でトンネルを入れ子にする正当な理由は二つあります。企業クライアントが特定の国から来ているように見える必要があるか、二つのプライベートネットワークに同時に到達できる必要があるかのどちらかです。どちらの場合も、外側のトンネルが内側クライアント自身の接続を運ぶ必要があります。

二つのクライアントをどの順で起動しても、それは実現しません。実現するのはルーティングです。

二つの可能な順序を比較する

外側の層は、エンドポイントに公衆インターネットから到達できるトンネルとして選びます。内側の層は、サーバーがその出口を通してしか応答しないトンネルです。Windows での実務的な分割は、外側が WireGuard、内側が企業クライアントです。決め手は制御です。

公式の WireGuard クライアントは、ルートと DNS を含む完全な設定ファイルを適用します。商用の企業クライアントは通常、どちらも隠します。隠れたクライアントを外側に置くと、その下の経路について推測するしかなくなります。

逆の順序も不可能ではありません。ただし、外側のクライアントが決して見えないスケジュールでルートを書き換えるため、考えるのは難しくなります。

AllowedIPs には企業の範囲だけを書かせる

AllowedIPs は、WireGuard がトンネルに流す宛先を列挙します。入れ子にするには、内側サーバーのアドレスと企業のプレフィックスだけで足ります。それ以外はすべてローカルネットワークに残り、プリンターやハイパーバイザーも含まれます。これは設計上スプリットトンネルであり、除外の問題を完全に避けます。

フルトンネルの外側の層には 0.0.0.0/0 からローカル範囲を除いたものが必要です。 この形式では除外を表現できません。そのため補集合を計算して貼り付ける必要があります。

[Interface]
PrivateKey = ...
Address = 10.99.4.2/32

[Peer]
PublicKey = ...
Endpoint = 198.51.100.44:51820
AllowedIPs = 198.51.100.44/32, 10.20.0.0/16, 10.21.0.0/16

内側のクライアントが独自のルートをインストールしない場合は、企業のプレフィックスを自分で列挙します。その行から漏れたプレフィックスは、外側のトンネルが決して運ばない宛先です。リストの古いコピーは、正しく見えるぶん、ないより悪いものです。

順序、メトリック、二つ目のアダプター

先に外側のトンネルへ接続し、その後に企業クライアントを起動します。すると、そのエンドポイント接続はローカルゲートウェイではなく WireGuard を通って出ていきます。企業インターフェースには低いメトリックを設定し、所有するアドレスでそのプレフィックスが優先されるようにします。

# which interface currently claims the corporate prefix?
Find-NetRoute -RemoteIPAddress 10.20.10.5 | Select-Object -First 1

# prefer the corporate interface for its own prefixes
Set-NetIPInterface -InterfaceAlias 'Corp VPN' -InterfaceMetric 3
Set-NetIPInterface -InterfaceAlias 'wg-personal' -InterfaceMetric 40

wg show interfaces

メトリックは見落とされがちな手順です。順序がないと、重複するプレフィックスでは最後にインストールされたルートが勝ちます。これは起動のたびに変わるため、問題が断続的に見えます。

OpenVPN 2.6 を基にしたクライアントには独自の罠があります。データチャネルのオフロードアダプターがすでに使われていると、二つ目のインスタンスは起動を拒否します。プロファイルに disable-dco を加えると古い TAP 経路に戻り、両方が並んで動くようになります。

入れ子の経路が壊れる場所

外側のトンネルを切断すると内側も死にます。内側のクライアントだけを再接続すると、そのままインターネットへ出てしまい、入れ子が黙って外れることがよくあります。毎回、両方のトンネルを止めた状態から手順を試してください。

使える MTU は小さくなると考えてください。層が増えるたびにオーバーヘッドが加わるため、1420 と 1400 あたりの組から始めるのがよいでしょう。大きなパケットで止まるのに小さな要求は通る、というのがよくある兆候です。企業ポリシーももう一つの制約で、管理された端末を求めるクライアントは入れ子の経路を違反とみなすことがあります。

両端が固定ネットワークなら、ゲートウェイ間のサイト間トンネルにすれば、順序の問題を管理するのではなく取り除けます。一台のノート PC では、二つのトンネルはそれぞれ独自のインターフェースと、プレフィックスごとに宛先を選ぶルールがあるときだけ共存します。

関連記事