ブリッジ型ホットスポットにつながったスマホは、自分のアドレスとゲートウェイをどこかから受け取ります。それはPiのデフォルトルートではありません。Piのデフォルトを変えると、Pi自身の通信の送り先が変わります。スマホは教えられたゲートウェイを使い続け、そのゲートウェイがリモートLAN上にあるとき、フレームはただブリッジを渡ります。消費者は二つ、決定も二つ。両者を分けて考えれば、Pi自体は正常なのにホットスポットにインターネットがないという報告の大半が説明できます。

二台の機器、二つの異なるゲートウェイ決定

Piには独自のIPスタックとデフォルトルートがあります。スマホにも独自のIPスタックとデフォルトルートがあります。

ConsumerWho chooses its gatewayWhat carries the traffic
Phone on the bridged APThe remote LAN router, delivered in its client configurationAn Ethernet frame toward that router crosses the AP and TAP bridge
Pi's encrypted connectionThe travel uplink's route toward the VPN peerThe Pi sends its own outer transport packets over the underlay

この表がモデルのすべてです。スマホのゲートウェイはリモートLAN上のアドレスで、そのフレームはレイヤ2でそのルーターへ転送されます。PiのデフォルトルートはPi自身の外側トランスポートに関わり、それは旅行用アップリンク経由でVPNピアに届く必要があります。

ブリッジはフレームを転送し、パケットをルーティングしない

Linuxブリッジは宛先MACでEthernetフレームを転送し、ポート間でそれ以外のことはしません。リモートルーターのMAC宛てのスマホのフレームはTAPポートへ切り替えられ、Piのルーティングテーブルに触れずトンネルを渡ります。だからPiのデフォルトルートが壊れてもスマホは動き続け、正しいデフォルトルートでも誤ったゲートウェイを渡されたスマホは直りません。

TAPはEthernetフレームを運び、ブリッジポートになれます。TUNはIPパケットを運び、ブリッジポートにはなれません。設計が両者を入れ替えているなら、それはブリッジではなく、ここからの話は当てはまりません。

スマホのリースを誰が配るかを決める

DHCPオプション3はルーターオプションで、クライアントに自分のサブネットで使うゲートウェイを伝えます。リモートLANのDHCPサーバーだけが配布者なら、スマホはリモートのゲートウェイを得て、設計は一貫します。旅行側の何かが先に応答すると、スマホはローカルのゲートウェイを得て、インターネット通信は旅行用アップリンクから出て行き、リモートLANへの通信には経路がまったくなくなります。

そのブロードキャストドメインには配布者を一つだけ置き、何を配るかを記録します。

Piは同じリースからアドレスを取る場合でも別のケースです。リースが提示するルートをインストールすべきかを意識して決めてください。取り込んだリモートのデフォルトが、Pi自身のVPNトランスポートを、生かしておきたいトンネルの中へ引き込みかねないからです。systemd-networkdならDHCPセクションのUseRoutes=、dhclientなら要求リストのroutersオプションがその決定です。

アップリンクをブリッジLANの外に置く

Piの外側VPN接続を運ぶインターフェースをブリッジポートにしてはいけません。そうなると暗号化トランスポートが拡張LANへ切り替えられ、トンネルが自分の外側パケットを運ぶことになり、ループではなくパケット損失のように見える形で失敗します。AP機能とブリッジ対応も明示しておきます。ステーションモードの無線インターフェースは通常ブリッジポートになれません。802.11ヘッダーにはブリッジが必要とする二つ目のMACアドレスの余地がないからです。

定義するのは 拡張ブロードキャストドメイン、一つのアドレス計画、そして本当に必要なフレームフィルタリングです。PiでVPNリスナーを許可しても、ブリッジされた全クライアントにPiの管理サービスへのアクセスを与えるわけではありません。これらは別のルールであり、一つとして扱うことが、ホットスポットが静かに開いた扉になる道です。

壊れたときは四つを別々に試す

スマホがリモートLANに届かないとき、四つの観察が原因を切り分けます。この順に実行し、最初に失敗したところで止めます。

ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmp

リースから始めます。スマホはリモートサブネットのアドレスとゲートウェイを持っているか。次にブリッジを見て、APポートとTAPポートの両方が転送していることを確認します。次に近隣テーブルを読みます。リモートルーターのエントリが未解決なら、フレームは出ていくが何も応答していないという意味です。最後にスマホがpingしている間のフレームをブリッジで観察します。これで障害がIPより下にあるかどうかがわかります。

終わったら、どのデバイスがどのデフォルトを持つかを記録します。一行の文書が、ローカルとリモートのどちらから出るかを意識的なクライアント決定に変え、ブリッジの参照をその隣に置く価値があります。

関連記事