ゲストWi-Fiがメインルートを使い続ける：専用の出口を与えよう

ゲストネットワークを作り、ルートを追加しても、ゲストは通常のインターネット接続から外へ出たままです。トンネルは起動しており、メインLANも動作し、ゲスト端末は割り当てた範囲のアドレスを報告しているので、壊れているようには見えません。たいてい欠けているのはルートではなくセレクタです：ルーターはパケットがどのインターフェースから到着したかを考慮する前に経路を決めるため、何かが明示的にゲストのトラフィックと一致しない限り、そのトラフィックは既定値を継承します。修正はセグメント、ポリシールール、応答経路の順です。

症状：ゲストは今もWANから出ていく

手がかりは出口アドレスです。トンネル経由でインターネットに到達するゲスト端末はトンネル事業者のアドレスを報告し、既定値を継承した端末は通常の接続を報告します。ゲスト端末とメインLANの端末を並べて比較してください、なぜなら、設定した内容と異なり、互いに一致している場合が興味深いからです。

二つ目の手がかりは、ゲストが閲覧している間、トンネルインターフェースにまったくトラフィックがないことです。カウンターが動かなければ、ポリシーは一度も適用されておらず、トンネル自体を調整しても解決しません。

ステップ1：名前だけでなく実際のセグメント

SSID名だけでは分離は生まれません。ゲストネットワークが独自のインターフェース、VLAN、ブリッジで終端していること、アドレス範囲が信頼されたLANと異なることを確認してください。多くの家庭用アクセスポイントでは、ゲストSSIDが他のすべてと同じセグメントにブリッジされるため、それを直さない限りこの作業の残りは不可能です。

次にゲスト範囲とそのDHCPサーバーを確認し、リゾルバーの設定はルーター全体ではなくそのセグメントに紐づけてください。ファイアウォールルールのコメントとしてしか存在しないゲストサブネットはセグメントではなく、ルーターには照合するインターフェースがありません。

VPNを設定しやすくするためにゲストをメインLANへブリッジしないでください。それは望んでいた分離をルーティングの近道と引き換えにし、ゲストネットワークがプリンターやNASへのアクセスを得てしまう通常の原因です。

ステップ2：送信元でトンネルを選ぶ

ルーティングテーブルは宛先で選ばれるため、「0.0.0.0/0をトンネルへ送る」というルールは全員に適用されます。ポリシールーティングは第二の次元を加えます：送信元アドレスでテーブルを選ぶのです。Linuxベースのルーターでは、追加のルールと専用テーブルが必要で、最初に一致したルールが優先されるため順序が重要です：

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

最後のコマンドは問いに直接答えます：この送信元がこの宛先に使うインターフェースはどれか、です。変更の前後で実行すれば、ブラウザーに触れずにポリシーが効いたか分かります。

ほとんどのルーターファームウェアは同じことをインターフェースルールや送信元ベースのゲートウェイ選択として表現します。プラットフォームがどの構文を使うにせよ、原理は同じです：入力インターフェースまたは送信元プレフィックスに一致させ、その一致にだけ経路を上書きします。宛先で一致するルールはゲストと家庭内端末を区別できません。

ステップ3：応答経路と変換

トンネルから出たパケットは戻ってこなければなりません。トンネルの相手がゲストプレフィックスへの戻り経路を知っているか、ルーターがゲストの送信元をトンネルのアドレスへ変換します。どちらかを選んで書き留めてください、失敗の形が異なるからです：戻り経路がない場合は接続は確立するのに応答がなく、変換がない場合は何も起きないことがよくあります。

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

変換を選ぶなら、相手はすべてのゲストに対して単一のアドレスを見るため、遠端でのクライアント単位のポリシーは失われます。アドレスを保持するなら、両端のルーティングとポリシーにゲストプレフィックスが必要で、手間は増えますが予測しやすくなります。

IPv6には独自のルールが必要です。IPv4向けに書いたポリシーはもう一方のファミリーをカバーせず、IPv6が動作するゲスト端末は喜んでそれを使い、丹念にルーティングしたIPv4の経路は遊んだままになります。両方のファミリーをルーティングするか、ゲストセグメントでIPv6を無効にしてください、ただし、書いた複合ルールが端末の実際の動作をカバーすると仮定しないでください。設計が耐えるべきなのは、両方のファミリーを有効にしたクライアントでテストする場合です。IPv6を優先するノートPCはIPv4のみのテストでは正しく見え、実際には漏れます。

分離をテストする：閲覧だけでなく

閲覧は出口が変わったことを証明します。セグメントが分離されていることは証明せず、分離こそがゲストネットワークの存在理由です。ゲスト端末から、ルーターの管理インターフェース、信頼されたLANのホスト、拒否されるべきサービスへ到達を試みてください、三つとも失敗すべきで、その失敗は誰にも説明できないタイムアウトではなくポリシーの判断であるべきです。

次にメインLANの端末をテストし、その出口が変わっていないことを確認します。この設計が最もよく引き起こすリグレッションはこれです：ゲスト向けの広いルールが、宛先で一致を書いたためにすべてのインターフェースに適用されるのです。

最後に、トンネルが落ちたときにどうなるかを決めてください。ゲストはインターネットを得られないか、承認した経路へフォールバックします、これを未決定のままにすると通常の接続への静かなフォールバックになり、それこそがゲストポリシーが防ぐはずだった漏れです。インターネットトラフィックのルーティングのレシピでは、pfSenseベースのルーターで同じ経路選択を順に説明しています。

ルーター発のDNSは、最後に人を驚かせるケースです。ゲストがルーターをリゾルバーとして使うと、ルーター自身のクエリはゲストルールではなくルーターの経路に従うため、アプリケーションのトラフィックが出ないのに検索だけが通常の接続から出ることがあります。セグメント、リゾルバー、障害時のポリシーを一つのメモにまとめておけば、次の人は設計を導き直さずに三つとも確認できます。