サーバーのない Wi-Fi ネットワークに VPN が参加できない理由

この依頼はたいてい、クライアントを Wi-Fi ネットワークに向けてその内側に入りたいという、同じ願望の一形態として届きます。トンネルがするのはそれではありません。トンネルは、すでに待ち受けている何かにクライアントを接続します。対象ネットワークに遠隔アクセスのために待ち受けているものがなければ、もう一方の端は存在しません。

トンネルは設定ではなく関係である

一方が待ち受け、他方が接続し、双方がプロトコルと資格情報について合意します。待ち受ける側は、到達したいネットワークの内側に置かれていなければなりません。その部分はクライアント側から作り出すことはできません。正しいアドレスと背後にある誤ったネットワークを持つプロファイルは、アクセスではなくタイムアウトを生みます。

だからこそ、こうした質問のいくつかに対する正直な答えは、そのネットワークには遠隔アクセスが存在しない、というものです。プロトコルやポート、別のクライアントを加えても、所有者が一度も導入していない端点は生まれません。

Wi-Fi の情報はトンネルの資格情報ではない

SSID、サブネット、ゲートウェイ、パスフレーズは、建物の中に立っていることについての事実です。そのどれも、インターネットのどこか別の場所にあるサービスに対してあなたを認証しません。キャンパスやホテルのネットワークは、その情報を建物内の宿泊客向けに公開しているのであって、インターネット上のクライアント向けではありません。

内部サブネットを VPN プロファイルにコピーすると、あなたのいる場所からは経路のないアドレスに到達しようとする試みになります。その試みは資格情報が確認される前に失敗するため、ユーザー名や認証方式を変えても決して役に立ちません。

組織が遠隔アクセスサービスを運用している場合、その文書には端点と方式が示されていますから、その二つの事実を具体的に尋ねてください。そうしなければ、ヘルプデスクはいつも聞いている質問、つまり Wi-Fi についての質問に答えてしまいます。

出口はあなたの送信元ネットワークを選ばない

一部のサーバーは、アドレスが一定の範囲に入るクライアントにしか応答しません。これは送信元の確認です。商用の出口はその範囲の外にあるため、アプリケーションのデータが交換される前に接続は拒否されます。別の事業者を選んでも、アドレスは依然としてサーバーが求めるものではないため、計算は変わりません。

残る選択肢は三つだけで、三つしかありません。許可された範囲の内側に端点を見つけるか、すでにそこにある承認済みのジャンプホストを使うか、所有者にポリシーの変更を求めるかです。それ以外はすべて、確認が実施されないことを期待する変形です。

ローカルのトンネルは誤った区間を暗号化する

ループバックインターフェースに束縛されたサーバーは、同じマシン上の二つのプロセス間の通信を保護します。そのループバック経路の外では、パケットは以前とまったく同じようにホストを離れます。ネットワークに望んでいた保護は決して存在しませんでしたが、処理のコストは実際にかかります。

その構成には、配備する前にクライアント、ルート、構成を試すという正当な用途があります。それはプライバシー対策でも遠隔ネットワークへの到達手段でもなく、両者を混同すると大量の構成が無駄になります。

サーバーなしで実際に機能するもの

デバイスに安定した受信経路がない場合、有用なパターンは直接接続ではなく待ち合わせ地点です。外部でホストされるリレー、デバイスから自分で管理する小さなサーバーへの逆トンネル、受信アドレス指定を提供する事業者のいずれも、間に到達可能なものを置きます。消費者向け VPN の契約は、あなたのネットワークの内側に端点を置かないため、それではありません。

ssh -N -R 2222:localhost:22 [email protected]
ss -tlnp | grep 2222
nc -vz 198.51.100.7 2222

最初のコマンドはデバイスからリレーへの逆トンネルを開き、二番目はローカルの待ち受けを確認し、三番目は外側から経路を試します。文書のアドレスを自分のリレーに置き換えて方向を明示的に確認してください、なぜなら、外向きの接続は翻訳を経て成功することが多い一方、求めていない内向きの接続は決して届かないからです。

目的が、自分で管理するネットワークにすでに存在するサービスに到達することだけなら、クライアントをそれを必要とするデバイスに置いてください。ノートパソコンからトンネルを共有するのは、独自の失敗様式を持つルーティングと翻訳のプロジェクトであり、管理されたクライアントはたいていそれを遮断します。