LAN 内のすべてのデバイスと 1 本の VPN 接続を共有する

ノート PC 一台がトンネルを保持し、家の残りは同じアクセスを望み、最初の試みはすべてを接続済みのマシンに向けることですが、これは VPN とは何の関係もない理由で失敗します。受け取るホストがパケットを転送し、送信元を書き換え、応答が戻り道を見つけられるようにしなければなりません。三つのうち一つでも欠けると、接続されたノート PC は動き続ける一方で、他のすべてのデバイスは応答を受け取れません。解決策はルーティングの設計であり、クライアントの設定ではありません。

デバイスをホストに向けると失敗する理由

リモートネットワーク宛てのパケットを受け取ったホストは、誰かがそう設定したかどうかに関係なく、その瞬間にルーターになります。転送は Linux と Windows では既定で無効で、何らかの機能が有効にしない限りオフのままです。アドレス変換が重要なのは、リモート側が応答をどこへ送るべきかを知る必要があり、プライベートな LAN アドレスはリモート側にとって何の意味も持たないからです。戻り経路が三つ目の要素であり、最初の ping が成功したように見えるときに人々が忘れるのがこれです。

設定をランダムに切り替えるのではなく、その順序で診断してください。欠けている要素ごとに症状は少しずつ異なります。

ホストで転送とアドレス変換を有効にする

接続済みのホストでは、IPv4 転送を有効にし、LAN のトラフィックをトンネルインターフェースへ変換する二つの変更が最初の二つの要素をカバーします。

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

sysctl の値を /etc/sysctl.d 配下のファイルに保存し、ファイアウォールのフロントエンドが独自のチェーンを消去することがあるため再起動後に masquerade ルールを再確認してください。Windows では共有機能が両方の手順を行いますが、LAN アダプターを固定サブネットに再アドレスし、そのゲートウェイを消去するため、静的アドレス指定とポート転送が壊れます。共有が失敗したと結論づける前に、新しいアドレスにあるホストへのルーターの経路を復元してください。そのうえで、二台目のデバイスが通信している間にルールのカウンターが増えるか観察します。

再起動に耐える経路を LAN に与える

他のデバイスにはリモートプレフィックスへの経路が必要で、それを提供する二つの方法は影響範囲が異なります。

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

クライアントのデフォルトゲートウェイをホストに向けると、ローカル印刷やファイル共有を含むすべてのトラフィックがホストを経由するため、ホストがスリープすると無関係なものまで止まります。ルーターにリモートプレフィックスへの特定の経路を追加する方が範囲は狭く、トンネルの背後にある宛先だけが接続済みのマシンへ行き、LAN の残りは動き続けます。上記のサブネットは例なので、自分の LAN とトンネルの範囲に置き換えてください。いずれの場合も、トンネルを有効にした状態と無効にした状態で二台目のデバイスから試してください。

トンネルのせいにする前に MTU を確認する

トンネルは利用可能なパケットサイズを縮めますが、二台目のデバイスはそれを知りません。大きな転送と TLS ハンドシェイクが止まる一方で、小さなリクエストは成功します。

ping -M do -s 1400 10.8.0.5

応答があればそのサイズが経路を断片化なしで通過することが証明され、タイムアウトはカプセル化のオーバーヘッドがパケットをトンネルの MTU の外へ押し出したことを意味します。共有インターフェースの MTU を下げるか、転送側で最大セグメントサイズを制限してから、同じ確認を繰り返してください。ローカルでの失敗はトンネルではなく LAN を示すため、まず LAN 側で同じサイズを試してください。後でプロバイダーやトンネルを変えると動くことがあるので、動作するサイズを記録しておいてください。

追加のデバイスが一台だけなら、ホストからの共有で十分です。家庭なら経路をルーターに置きます。ノート PC があなたと一緒に外へ出てもアクセスを保つ必要があるなら、トンネル自体を専用ゲートウェイに置くべきです。