ブリッジ型VPNホットスポット:スマホはどのデフォルトルートを使うのか
Piのデフォルトルートはスマホのゲートウェイではない。二つの決定を分け、アップリンクをブリッジの外に置き、トンネルより先にリースを確認する。
ブリッジ型ホットスポットにつながったスマホは、自分のアドレスとゲートウェイをどこかから受け取ります。それはPiのデフォルトルートではありません。Piのデフォルトを変えると、Pi自身の通信の送り先が変わります。スマホは教えられたゲートウェイを使い続け、そのゲートウェイがリモートLAN上にあるとき、フレームはただブリッジを渡ります。消費者は二つ、決定も二つ。両者を分けて考えれば、Pi自体は正常なのにホットスポットにインターネットがないという報告の大半が説明できます。
二台の機器、二つの異なるゲートウェイ決定
Piには独自のIPスタックとデフォルトルートがあります。スマホにも独自のIPスタックとデフォルトルートがあります。
| Consumer | Who chooses its gateway | What carries the traffic |
|---|---|---|
| Phone on the bridged AP | The remote LAN router, delivered in its client configuration | An Ethernet frame toward that router crosses the AP and TAP bridge |
| Pi's encrypted connection | The travel uplink's route toward the VPN peer | The 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より下にあるかどうかがわかります。
終わったら、どのデバイスがどのデフォルトを持つかを記録します。一行の文書が、ローカルとリモートのどちらから出るかを意識的なクライアント決定に変え、ブリッジの参照をその隣に置く価値があります。