LAN 向け VirtualBox VPN ゲートウェイ：ブリッジ、ルート、戻り経路

リモートのユーザーは物理 LAN 上のプリンターとファイルサーバーに到達する必要があり、常時稼働している唯一の Linux 機は VirtualBox の VM です。その VM を LAN にブリッジするのが前半です。後半は、LAN のすべての機器が実際に使う戻りルートであり、ほとんどの構成がここを落とします。これが欠けていると、トンネルはつながり、クライアントはゲートウェイに ping でき、それ以外は何も応答しません。

到達できるアドレスを使う

VM の LAN アダプターを、そのネットワークで承認された Bridged Adapter 接続に設定し、通常の割り当て手順でアドレスを付与します。すると VM は他のホストと同じように物理 LAN 上に現れます。既定ルートは引き続き実在のゲートウェイを使う必要があり、そうしないと VPN ピアへの暗号化トランスポートに到達できなくなります。VirtualBox の既定 NAT アドレスは、仮想 NAT の背後にあり、ホストや他の LAN マシンにとって on-link ではないため、LAN の次ホップにしないでください。

LAN router:          192.168.70.1/24
VirtualBox host:     192.168.70.5/24
VPN gateway VM:      192.168.70.10/24
Example LAN service: 192.168.70.40
VPN client pool:     10.80.0.0/24

アドレスプールを選ぶ前に、リモートユーザーの家庭内ネットワークとの重複を確認してください。重複はルーティングの曖昧さになり、サーバー設定では直せません。

LAN を広告し、それから転送する

認証とトランスポートがすでに管理されているサーバーなら、ネットワーク行は次のようになります。push は受け入れるクライアントに LAN への到達方法を伝えますが、それ自体が VM に何かを転送させるわけではありません。

dev tun
topology subnet
server 10.80.0.0 255.255.255.0
push "route 192.168.70.0 255.255.255.0"

VM の永続ネットワーク設定で IPv4 転送を有効にし、クライアントプールが VM の転送境界で目的の LAN サービスに到達できるようにします。VPN リスナーへの到達許可は別のルールで、トンネルが上がっていればすでに機能しています。

戻りルートは LAN ルーターに置く

LAN の機器は既定ゲートウェイ、つまり 192.168.70.1 の LAN ルーターを通して応答します。そのルーターは、教えられない限り 10.80.0.0/24 がどこにあるか知りません。プールのルートをルーターの対応する永続設定に追加し、VM の LAN アドレスを指します。VirtualBox ホストにだけ追加しても、そのホストに問い合わせる経路しか直らず、LAN のすべての機器ではありません。

ip route add 10.80.0.0/24 via 192.168.70.10

宛先自身のファイアウォールは、依然としてクライアントプールを送信元として許可する必要があります。ルートはパケットを運ぶだけで、サービスを許可するものではありません。

LAN ルーターを変更できない場合の代替は、VM 上での限定的な送信元変換です。これにより戻りの応答がルートなしで返り、LAN サービスから個々のクライアントアドレスが見えなくなります。

ひとつのパケットを端から端まで追う

10.80.0.25 のクライアントがトンネル経由で 192.168.70.40 に送信します。VM はパケットを LAN に転送します。サービスは自分のルーターに応答し、ルーターはクライアントプールに対して VM を選び、VM は OpenVPN 経由でパケットを返します。その文のどのホップも、設計が失敗しうる場所です。

リモートクライアントから実際のアプリケーションで試し、VM とルーターの両方で管理設定を再読み込みした後にもう一度試してください。

クライアントが VM には到達するがサービスに到達しない場合は、まずルーターのルートを確認してください。サービスが要求を受け取り、クライアントが応答をまったく見ない場合は、戻り経路が疑わしいです。