公開VPNのホスト名が証明できることとできないこと

ホスト名や国旗はサーバーに関する事実のように見えますが、どちらも事実ではありません。名前は変わりうるアドレスに対応しており、その中の言葉は登録した人が選んだものです。プロトコル、出口の位置、ログの扱いは、それぞれ独自の証拠を必要とします。名前が実際に何に解決されるかから始め、何がまだ不明かを決めてください。

名前が解決するだけで、他は何も確定しない

ホスト名はDNS内のポインタであり、その背後のレコードはリゾルバによって、時間帯によって、クライアントが好むアドレスファミリーによって異なりえます。同じディレクトリ項目を読む二人が、正当に別のマシンへ到達することはありえます。名前は何を尋ねるかを教えるだけで、何が答えるかは教えません。

検索結果も予告なく変わるため、プロファイルが名前ではなくアドレスを固定している場合には重要です。古いアドレスをハードコードしたプロファイルは、運営者がサービスを移した後も失敗し続け、その失敗はブロックされたポートのように見えます。解決されたアドレスをプロファイルのそばに残しておけば、後で比較するときの基準になります。そのどれも、反対側を誰が運営しているかは語りません。

dig +short vpn.example.net A
dig +short vpn.example.net AAAA
dig +short vpn.example.net A @1.1.1.1

トランスポートと身元は別の問い

ホスト名で開くウェブページは、一つのポート上の一つのリスナーを試すだけです。OpenVPN、IPsec、SSTPはそれぞれ別の場所で、独自のポートとプロトコルで待ち受けるので、到達できるウェブサーバーはそれらについて何も語りません。

ディレクトリ項目とプロファイルは、トランスポート、ポート、資格情報で一致していなければなりません。身元はクライアントの設定に使われた証明書チェーンや相手鍵の指紋で検証されるのであり、ホスト名の綴りで検証されるのではありません。よく知られたプロジェクト名を含む名前は、誰かがそれを登録したことだけを証明します。サービスが提示する証明書を読み、発行者とサブジェクトをプロファイルが期待する内容と比べてください。

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -dates

国名の言葉は位置の監査ではない

ディレクトリのjpやdeというラベルは登録にすぎず、IPの地理位置情報データベースはしばしば食い違うため、どちらも絶対的な真実として扱うべきではありません。共有ホスティング、エニーキャスト、単純な設定ミスは、いずれも観測される位置をラベルから遠ざけます。

実用的な検証はアプリケーション自身の経路、つまりどのアドレスに到達するのか、セッションの内側から出口アドレスの確認が何を示すのかを見ることです。観測された出口アドレスはその瞬間の経路の性質であり、名前に付随する保証ではありません。ボランティアのディレクトリはさらに層を加えます、なぜなら項目を登録した人が、そのマシンを運用している人とは限らないからです。何をいつ測定したかを書き留め、項目が約束したことを書かないでください。

提供されるサービスを確認し、次に運営者を

トランスポートと身元が確定した後に残る問いは運営者の行動であり、それには推測ではなく文書による証拠が必要です。プライバシーポリシー、公開された連絡先、透明性の通知は意図の証拠ですが、どれも実際の運用を証明するものではなく、三つとも欠けていることも情報です。

公開ノードやボランティア運営のノードでは、出口は共有されており、運営する人は通過するものを見られるものと想定してください。トンネルを通して何を送るかは、ホスト名ではなくその想定で決めるべきです。

curl -sSI https://vpn.example.net/ | head -n 5
whois 203.0.113.25 | grep -i -E 'orgname|netname'

名前は得意なことに、つまりエンドポイントを見つけてそこへ接続するために使ってください。それ以外のすべては、それが重要になる日に、別々に検証する必要があります。