host-only ネットワークの VM トラフィックを TUN OpenVPN サーバー経由でルーティングする

host-only アダプターはローカルの仮想ネットワークを作り、ルーティングされた TUN トンネルはアドレス間で IP パケットを運びます。どちらも他方へのブリッジではないため、動作する構成では誰が転送し、誰が戻り経路を持つのかを明示する必要があります。この二つの割り当てを間違えると、ゲストはトンネルクライアントが求めていない送信元でトンネルに応答します。以下の設計では両方のプレフィックスを分離し、戻り経路を明示します。

二つのネットワーク、二つのプレフィックス

トンネルプールと host-only ネットワークには異なるプレフィックスを与え、片方をもう片方に再利用しないでください。この例では VPN プールが 10.44.0.0/24、host-only ネットワークが 192.168.99.0/24 で、ホストは 192.168.99.1、ゲストは 192.168.99.20 です。同じプレフィックスを TUN デバイスと host-only アダプターの両方に割り当てても、両者は結合されません。一つのアドレス範囲に二つの主張が生まれ、ルーティングテーブルはたまたま残した方の主張に応答します。

host-only アダプターはホスト上とゲスト内の両方に存在し、それ自体ではマシンの外へ出る経路を持ちません。ブリッジ接続と NAT 接続では露出が異なり、一つのゲストサービスに到達するためにブリッジモードへ切り替える必要はありません。

ホストはすでに経路を持っている

何かを追加する前に、何が存在するかを確認してください。ホストには host-only ネットワーク上のインターフェースと、そのプレフィックスのルートがあり、どちらもアダプターの起動時に作られています。

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

三行目はホストをホップに変える仕組みです。これがなければ、トンネルから届いたパケットはホストが到達できても転送しないネットワーク宛になります。転送は必要ですが十分ではありません。フィルターポリシーは、トンネルインターフェースと host-only インターフェースの間の特定のフローを許可するかどうかを依然として決めており、その判断は誰も読まなかった既定ポリシーではなく文書に残すべきです。

ルートをプッシュし、それが到達する範囲をフィルタリングする

サーバーはプッシュされたルートを受け入れるクライアントに host-only プレフィックスを提供できますが、これはトンネルの背後にある他のサブネットと同じ仕組みです。

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

この二つのルールは、一方向の一つのサービスとその応答を許可します。プレフィックス全体に届くルートと一つのポートを許可するフィルターは意図的な組み合わせであり、ルートと無条件の許可を組み合わせると、実験用サービスが露出したサービスになります。プッシュされたルートも認可ではありません。クライアントは受け入れ、ホストは転送し、ゲストのファイアウォールとサービス自体はまだ発言権を持ちます。

ゲストには戻り道が必要

10.44.0.x から到達されるゲストは、応答をホストの host-only アドレスへ送るか、ホストが送信元を変換する必要があります。VirtualBox DHCP からアドレスを受け取ることは、どちらの配置についても何も語りません。

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

ゲスト内でそのルートを追加すると元の送信元が保たれ、クライアントごとのポリシーとログが意味を持ちます。ホスト側での限定的な送信元変換が代替案で、それも機能しますが、どのクライアントが接続したかを隠す代償があります。重複がもう一つの失敗モードです。自宅の LAN がすでに 192.168.99.0/24 を使っている遠隔クライアントは、プッシュされたルートを自分のネットワークと解釈し、サーバー側の変更ではその曖昧さを解消できません。片側を付け替えるか、衝突しにくいプレフィックスを選んでください。

TUN デバイスは IP パケットを運ぶので、ゲスト内に既定ゲートウェイを追加しても、トンネルが host-only アダプターと Ethernet セグメントになるわけではありません。TAP ブリッジはクライアント対応とアドレス所有権が異なる別の設計であり、二つの説明を混ぜると決して収束しない構成になります。

検証し、再起動を生き残るようにする

通常の遠隔クライアントから無害なサービスを一つ試し、ゲストの戻りルートを確認し、許可していないサービスが遅いのではなく拒否されることを確かめてください。

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

次に VPN サービスと仮想マシンのネットワークを再起動し、同じ三つの確認を繰り返します。手で追加したルートは次の再起動までしか持ちませんし、温かいセッションでしか動かない構成は設計ではありません。二つのプレフィックス、転送ポリシー、ゲストのルートをまとめて記録してください。次に仮想マシンを追加する人には三つすべてが必要で、そうでなければ失敗する接続のたびにそれらを再発見することになります。