Mesh Wi-Fi サテライトが VPN ルーターを使っているか確認する方法

デフォルトゲートウェイ、ノードの転送モード、ルーターのステートテーブルをたどり、Mesh サテライト配下のクライアントが VPN を通っているかを確かめます。

ベースルーターと同じ Wi-Fi 名に応答するサテライトは、その配下のクライアントのパケットがどこへ行くかをほとんど語りません。ノードは、反証がない限りラジオとブリッジにすぎません。出口を決めるのは、各クライアントが受け取るデフォルトゲートウェイと、その手前にあるノードの転送モードです。次の五つの確認をクライアント側から外へ向かって行えば、速度テストの印象ではなく、説明できる答えが得られます。

クライアントが実際に受け取ったゲートウェイを読む

クライアントでルートテーブルと近隣テーブルを出力します。デフォルトルートは転送するアドレスを示し、近隣エントリはそのアドレスを持つ MAC を示します。ルーターの端末一覧ではなくクライアントを見るのは 端末一覧が示すのは関連付けであって経路ではないからです。

ip route show default
ip -6 route show default
ip neigh show

Windows は同じ事実を別の形で出力します：ipconfig /all がデフォルトゲートウェイを、arp -a が MAC を示します。macOS では route -n get default と arp -an が同じ役割を果たします。

そのゲートウェイを、すでに知っている二つのアドレス、つまりベースルーターの LAN アドレスとサテライトの管理アドレスと比べます。ゲートウェイがルーターの LAN アドレスなら、クライアントはルーターにブリッジされ、そのセグメントに対するルーターのポリシーがそのまま効きます。ゲートウェイがサテライト自身のアドレスなら、サテライトがルーティングしており、ルーターはクライアントのパケットをLAN の通信として見ませんから、判断はノード側で行う必要があり、そこで行われなければ何も行われません。

ノードが実際にどのモードかを確かめる

Mesh 製品は同じ三つの言葉を別々の挙動に使い回すので、アプリの表示よりパケットの経路を信じてください。ブリッジまたはアクセスポイントモードはフレームを転送します。ルーターモードはサブネットを終端し DHCP を動かします。ゲストモードは通常、独自の規則を持つ別の VLAN にクライアントを置きます。別のルーターの背後にあるルーターモードのノードは二重 NAT になり、そのクライアントはすでに変換された状態で VPN ルーターに届くため、送信元アドレスに基づくポリシーが効かなくなります。

What you seeWhat it meansNext check
Gateway is the router's LAN address, one MAC for every nodeThe node bridges; the router owns the policyRouter policy for that LAN and VLAN
Gateway is the node's address and DHCP comes from the nodeThe node routes; double NATNode's own VPN client, or a static route plus policy on the router
Gateway is a different subnet on a guest SSIDGuest VLAN, often client-isolatedWhether that VLAN is inside the tunnel policy
Gateway changes when you walk into another roomRoaming across segmentsRepeat the check per node

MAC を特定するには、ノードのラベルを読み、ip neighの結果と突き合わせます。多くのメーカーは基本 MAC だけを印刷し、各無線の MAC はバイトを一つ増やして作るため末尾の桁が変わるので、アドレス全体ではなく前半を比べてください。ゲートウェイの MAC がルーターの LAN インターフェースのものなら、そのクライアントに対してノードはルーティングしていません。

出口はルーター側で証明し、速度テストでは証明しない

変換を示すのはルーター側の状態だけなので、OpenWrt ならポリシールールとルーティングテーブルを一覧し、トンネルに新しいハンドシェイクがあることを確認します。

ip rule show
ip route show table all | grep default
wg show

pfSense や OPNsense では同じ証拠が pfctl -sr にルールとして、pfctl -ss に有効な状態として、WireGuard の状態ページにピアのカウンタとしてあり、参照先は WireGuard クライアントのドキュメント です。ステートテーブルをクライアントのアドレスで絞り込みます。状態がクライアントをトンネルアドレスに変換して示していれば通信はトンネル内、WAN アドレスを示していればトンネル外であり、ダッシュボードの表示は関係ありません。

クライアントからの traceroute は、ステートテーブルでは分からない事実、つまり最初のホップを加えます。最初のホップがルーターの LAN アドレスなら、クライアントはルーターに直接届いています。ノードのアドレスで、その次にもう一つプライベートなホップが続くなら、そこはルーティングされたセグメントであり、二番目のホップがポリシーを持つべき機器です。

ノードがアドレス以外に何を配るか確認する

DHCP オプションはリースと一緒に配られるため、自前の DHCP を持つノードは自分の DNS と自分の IPv6 ルーター通知も配れます。そのためクライアントはトンネルを通りながら、ノード上のリゾルバーへ問い合わせたり、トンネルのポリシーが決して覆わないグローバル IPv6 アドレスを受け取ったりするので、両方をクライアントで出力してください。

cat /etc/resolv.conf
ip -6 addr show scope global

リゾルバーがノードで、ノードがルーターへ転送するなら DNS はトンネルに従います。ノードがローカルで解決するか、プロバイダーのリゾルバーを指すなら、HTTP がトンネルを通っていても問い合わせはトンネルの外へ出ます。IPv6 も同じ検証に値し、グローバルアドレスとトンネルを迂回するデフォルトルートの組み合わせは漏えいで、Mesh のファームウェアは IPv6 を有効にしたまま VPN のポリシーが IPv4 しか覆っていないことがよくあります。

わざとトンネルを落として、結果を記録する

トンネルを落とし、ルーターの隣のクライアントではなく、そのノードに接続したクライアントを観察します ping と短いタイムアウトの curl と短いタイムアウトの X は十分であり、問うのは通信が止まるのか WAN へ戻るのかという点です。トンネルはルーター自身のサービスコマンドで止めます。たとえば wg-quick down wg0 や OpenVPN サービスの停止で止め、テストは短く済ませてください。

クライアントが動き続けるなら、そのセグメントではノードかルーターがフェイルオープンしており、Mesh はキルスイッチを静かに無効化しています。トンネルを戻し、ハンドシェイクのカウンタが動いたことを確認し、三番目のステートテーブル確認をやり直してください。

ノードごとに、ラベル、SSID、ゲートウェイアドレス、MAC の前半、出口が確認できたか、IPv6 が覆われているか、トンネルを落としたときの挙動を一行に記録します。答えが変わるのはローミングのときなので、実際に歩き回る部屋で試してください。一行だけ他と食い違うなら、調べるべきはそのノードであり、修正はその行のゲートウェイを持つ機器に入れます。

関連記事