スマホでページが開けない：待ち受けアドレスを確認する

ノート PC がページを localhost で配信し、スマホは同じ VPN に参加しているのに、スマホのブラウザはサイトに到達できないと表示する。トンネル自体はまだ何も壊れていない、トンネルはパケットを届けるだけだからだ。loopback インターフェースに束縛された開発サーバーは他のアドレス宛ての接続を決して受け付けない、したがって最初に見るべきは VPN ではなく、待ち受けているソケットである。

ソケット、バインド設定、ファイアウォール規則、URL の順に確認する。

ソケットはより狭い問いに答える

127.0.0.1 に作られたリスナーは、そのマシン自身からの通信だけを受け付け、別のアドレスに届いたものはすべて拒否する。ワイルドカードアドレスのリスナーは、VPN インターフェースを含むすべてのローカルインターフェースで受け付けるが、これはほとんどの開発環境が必要とする範囲より広い。特定の VPN アドレスに束縛されたリスナーが最も狭く実用的な選択であり、そのアドレスが存在する間だけ機能する。

そこから二つの命名の罠が生じる。スマホのブラウザでは localhost はスマホ自身を指し、ノート PC ではない。ワイルドカードアドレスはバインド値であり、URL に打ち込むものではない。どちらかで試した人は、ネットワークが一切関与していない失敗を報告することになる。

IPv6 は第三のケースを加える、ソケットは見落としやすいオプション次第で IPv4 と IPv6 の両方を受け付けることができる。一覧でアドレスファミリーを読むこと。一方のファミリーのワイルドカード項目は、もう一方を説明しない。

待ち受けアドレスを読む

設定を変える前にソケットを調べる。ローカルアドレス、ポート、所有プロセスを合わせれば、サーバーが VPN から到達可能かどうかが分かる。

Get-NetTCPConnection -State Listen -LocalPort 8080 | Select-Object LocalAddress,LocalPort,OwningProcess
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 8080).OwningProcess
ipconfig | Select-String -Pattern 'IPv4'
Get-NetFirewallRule -DisplayName '*8080*' | Format-Table DisplayName,Enabled,Profile,Direction,Action

ローカルアドレスが 127.0.0.1 なら話は決まりだ、ファイアウォールを変えても無駄で、アプリケーションが VPN インターフェースで待ち受けていないからだ。ワイルドカードまたは VPN アドレスなら、ソケットは正常で、次の境界が問題になる。

所有プロセスも確認すること、よく使うポート上の無関係なサービスが表を正しく見せていても、本来のサーバーが起動していないことがある。名前だけでなく実行ファイルのパスを照合する。以前の実行が残した古いプロセスはよくある偽物だ。

アプリケーション側でバインドを変える

フレームワークの文書化された待ち受けアドレスオプションを使い、プロセスを再起動する。ノート PC がプライベートアドレス 10.77.0.1 を持つなら、スマホの URL は http://10.77.0.1:8080/ になり、そのアドレスは VPN 経由でルーティングされなければならない、設定の他の部分は変わらない。

バインドを強制するために Windows に任意のアドレスを追加したり、ゲートウェイを変更したりしないこと。そうした変更はデバッグの後も残り、次の人を驚かせる。VPN アドレスが存在する前に起動したサーバーもバインドに失敗することがあるため、一時的なインターフェースでは起動順序が重要になる。再試行させるか、トンネルの後に起動する。起動時のバインド失敗は、翌朝にはファイアウォールの問題とそっくりに見える。

HTTPS では、サービスのホスト名と証明書の検証をそのまま保つ。生のアドレスに対する証明書警告は命名の問題であり、クリックして通過する手順ではない、プライベート DNS は選んだリスナーと一致していなければならない。

規則は一つだけ開き、ネットワーク全体は開かない

ソケットが VPN アドレスで受け付けるようになると、要求が届くかどうかはファイアウォールが決める。規則の範囲をこのアプリケーション、このプロトコル、このローカルポート、許可されたリモート送信元に限定し、VPN アダプターでどのプロファイルが有効かを確認する。

Windows が実際に見る送信元アドレスを使うこと、ゲートウェイが行う変換も含まれる、元のクライアントアドレス向けに書かれた規則は変換後のアドレスには一致しない。

ページが読み込まれてアプリケーションのエラーが表示されるのは前進だ、HTTP の拒否は TCP 接続がない場合とは別の失敗であり、次の調査はネットワークではなくアプリケーション自身のアクセス方針に属する。

最後に、目的のスマホからページを要求し、除外した端末が依然として到達できないことを確認する。すべてを許可する規則で動くリスナーは、同じ結果ではない。