Pi のホットスポットクライアントが TUN VPN 経由で自宅 LAN に届かない

ローカルの Wi-Fi と Ethernet クライアントは Pi のホットスポットに接続し、その DHCP 範囲からアドレスを取得して、何の不満もなくインターネットページを読み込みます。ところが同じクライアントが自宅 LAN のファイル共有や Web UI を開くとタイムアウトします。一方、Pi 自身はトンネル経由でその LAN に到達しています。ワイヤレス層には何も壊れていません。欠けているのはルーティングされた契約です。ホットスポットのプレフィックスを TUN インターフェースへ運び、自宅側の何かが応答をそこへ返す方法を知っていなければなりません。一つのパケットが往復を完了するには、両方の半分が必要です。

三つの異なる役割を持つ三つの接続

Linux の Ethernet ブリッジは宛先 MAC アドレスでフレームを転送します。OpenVPN は TUN モードで IP パケットを運び、MAC 層をまったく持たないため、ローカルブリッジを追加してもトンネルがポートとして登録されることはありません。カーネルの TUN/TAP ドキュメント はその分離を明示しています：TAP デバイスは Ethernet インターフェースに見えますが、TUN デバイスはそうではありません。二つのローカルポートをブリッジしてからルーティングする設計は、インターフェース名が何であれルーターです。

その区別が所有権を決めます。クライアントのサブネット、既定ゲートウェイ、その範囲の DHCP 権限は Pi のローカル計画に属します。自宅の DHCP ブロードキャストはルーティングされたトンネルを越えず、ブリッジ設定でも変わりませんし、クライアントを自宅の DHCP サーバーに向けるのは独自の障害モードを持つ別の意図的なリレー設計です。

モデムもクライアントブリッジの外に保ちます。PPP 接続は別のラベルを貼った Ethernet デバイスではなく、pppd の文書化された既定ルートのロジックは IPCP 交渉の後に動き、そのリンクが落ちるとルートを撤回します。DHCP テンプレートをコピーし、すべての usb0 を ppp0 に改名しても、ゲートウェイ、メトリック、ライフサイクルについて何も証明しません。

どの設定を編集する前にもプレフィックスを選びます

重複するプレフィックスは、トンネルが健全でも重複がルート検索を間違ったインターフェースへ送るため、ファイアウォール規則よりも多くの夜を無駄にします。まず Pi に既にあるものを列挙し、その結果を四つの別々のプールとして読みます。

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

最初のプールはキャリアがモデムに渡した underlay アドレスで、クライアント向けのあらゆる計画から外しておく必要があります。二番目はサーバーが選んだトンネルサブネットで、多くの場合サーバー自身のプライベート /24 です。三番目はホットスポットブリッジ、四番目は到達したい自宅のプレフィックスです。この手順ではホットスポットが 172.28.90.0/24 を取得してブリッジは 172.28.90.1、自宅のサービス LAN は 192.168.77.0/24 を保ち、これによりコンシューマールーターが同梱する 192.168.1.0/24 と 10.0.0.0/24 の既定値、およびキャリア範囲 100.64.0.0/10 を避けられます。

ホットスポットの DHCP 範囲ではブリッジアドレスだけをゲートウェイとして告知してください。ホットスポットクライアントに自宅のアドレスをゲートウェイとして渡してはいけませんし、そのセグメントへのリンク層の経路もありません。

各方向をそれを所有する側でルーティングします

Pi にはトンネル経由で自宅プレフィックスへのルートが必要です。サーバーモードのサーバーは通常そのルートをプッシュするので、まず転送が有効で、カーネルが tun0 から自宅アドレスを解決することを確認します。

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

経路のこれ以降は誤った検索を修復できないため、ip route get が依然として underlay インターフェースを報告するならそこで停止してください。

自宅のデバイスは 172.28.90.0/24 への経路を持たないため、応答は既定ゲートウェイに従いルーターで消えます。サポートされる修復は二つあります。自宅ルーターに静的経路を追加してホットスポットのプレフィックスを VPN サーバーの LAN アドレスに向けるか、サーバー自身がゲートウェイの場合はクライアントのプレフィックスをサーバー自身のルーティングテーブルに登録します。OpenVPN のマルチクライアントモードではクライアント固有のディレクトリがその関連を担います：クライアント証明書のコモンネームにちなんだファイルで、iroute 172.28.90.0 255.255.255.0 と、それをサーバーカーネルに登録する対応する route 行を含みます。サーバー上で推測したカーネル経路は、どのクライアントがプレフィックスを所有するかをサーバーに伝えることと同じ表明ではありません。

これを機能させるために自宅ネットワークの DHCP サービスを VPN サーバーへ移さないでください。家全体の既定ゲートウェイを置き換えるのは、プライベートな戻りルートを一つ追加するよりはるかに大きな変更で、DNS、アドレス予約、新しいリースを無視するあらゆるデバイスを障害へ引きずり込みます。

ファイアウォールを推測せずに転送を開きます

転送が有効であることは、パケットが通過を許されることを意味しません。ブリッジからトンネルへのトラフィックは依然としてフィルター規則に当たり、既定の drop 転送ポリシーはホットスポットのトラフィックを落とす一方で Pi 自身のトラフィックは動き続けるため、まさに上の分割症状を生み出します。

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

br0 から tun0 への許可規則と対応する応答方向、および送信元を書き換えうる postrouting 規則を探します。チェーンポリシーが drop でどの規則も一致しないなら、ポリシーを accept に反転させるのではなく、狭い許可を追加して再テストします。

翻訳は要件ではなくポリシーの選択です。自宅 LAN 向けの送信元 NAT は、すべてのホットスポットクライアントを Pi のトンネルアドレスのように見せ、自宅のログでクライアントごとの帰属を失わせ、元の送信元を期待するサービスを壊します。NAT なしのルーティングはクライアントアドレスを見えるままにしますが、上の戻りルートに依存します。どちらかを選び、DNS と IPv6 も同じように扱ってください。IPv4 の経路が機能していても、隣の IPv6 経路が壊れていればブラウザーでは半分壊れていると読めるからです。

往復を検証し、それから意図的に壊します

ホットスポットクライアントからテストし、Pi からは決してテストしません。Pi 自身のトラフィックは転送経路と戻り経路の両方を迂回するからです。一つのクライアントが自宅のサービスに到達しようとする間、両方のインターフェースを監視します。

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

二つのキャプチャを合わせて読みます。br0 に現れて tun0 に決して現れない要求は、Pi が転送していないか経路が別の場所を指しています。tun0 で応答のない要求は、自宅側に戻り経路がないかサーバーがパケットをフィルターしたことを意味します。tun0 に現れて br0 に二度と現れない応答は、逆方向のフィルター規則が欠けていることを意味し、トンネルは完璧に見えるのにクライアントには何も見えません。

次に経路を意図的に壊します。モデム接続を切断して再び接続し、経路とキャプチャのチェックを再実行します。トンネルを生き延びても再接続で消える経路は、一時的なコマンドではなく接続プロファイルに入れるべきです。トンネルのトランスポートが依然として underlay を通って出ており、自分自身を通っていないことを確認します。これは、ピアへのホスト経路なしにプッシュされた既定経路を受け入れたときの古典的なループです。

ホットスポットクライアントが自宅の名前を解決し、TCP サービスを開き、モデムの再接続一回をまたいでセッションを生かし続けられるときにだけ、この設計を受け入れます。アプリケーションが本当に自宅セグメントでの Ethernet レベルの検出を必要とするなら、ローカルブリッジをブリッジ済みと説明してブロードキャストを待つのではなく、サポートされた Layer 2 設計を選んでください。