ポート53のOpenVPN：混同されやすい三つの会話

VPNがポート53でブロックされているという報告は、それぞれ別の理由で失敗する三つの観測を混ぜています。エンドポイント名の解決はトンネルが存在する前に起こり、暗号化トランスポートは別の会話であり、その後に発生するDNSクエリが三つ目です。それぞれに固有の失敗の兆候があり、DNSに関係するのはそのうち一つだけです。

修正は段階に従うため、何かを変える前にパケットを目的別に整理してください。

三つの会話、一つのポート番号

一つ目の会話はエンドポイントの名前解決で、お使いのマシンは設定済みのリゾルバにvpn.example.comの場所を問い合わせ、その応答はクライアントがトンネルパケットを一つも送る前に通常のDNSで届きます。二つ目はOpenVPNのトランスポートそのもので、名前解決が返したアドレスへ、プロファイルが指定するプロトコルとポートで接続します。三つ目はトンネルが起動した後に起こり、アプリケーションが名前を要求し、プッシュされたリゾルバ設定が誰が応答するかを決めます。

この三つは独立して成功も失敗もします。クライアントはエンドポイントを完全に解決できてもリスナーに到達できないことがあり、DNS設定が届かなかったために内部の名前解決がすべて失敗したままトンネルを確立することもあります。

表は説明ではなくチェックリストとして読んでください。エンドポイント名が解決できなければ、その後の何も機能せず、トンネルは決して始まりません。

ポート番号はアプリケーションを指し示さない

ポート53がDNSを運ぶのは慣例であり、OpenVPNの運用者がそこにリスナーを公開することもできるため、この番号は識別子として不適切です。UDP 53上のOpenVPNセッションは依然としてOpenVPNセッションであり、ポート53のサーバーへのDNSクエリはトンネルが許可されているかどうかを何も語りません。プロファイルのprotoとremoteの行が外側のエンドポイントを定義し、ポート番号自体は何も定義しません。

診断ではこれは両方向に効き、ポート53への一般的なUDPプローブが証明するのは、あるポートが応答することであり、VPNサービスが応答することではありません。サービスが期待するハンドシェイクを試せるのは実際のクライアントと実際のプロファイルだけなので、それでテストしてください。

ネットワークを責める前にリスナーを証明する

サーバー側ではss -lunp | grep 53で何がバインドされているかを確認し、プロファイルのプロトコルとポートと比較します。クライアント側のネットワークからは、より詳細なログを有効にしてクライアントを実行し、どのアドレスとトランスポートを試したかを記録で確認します。サーバーが待ち受けていてクライアントのパケットが届かないなら、経路かポリシーが拒否しているのであり、それはネットワーク所有者との会話であってポートを変える理由ではありません。

別のポートが役立つのは、サービスが実際にそこで待ち受け、展開がそれを許可している場合だけです。管理されたネットワークのフィルタリングを避けるためにリスナーを移すのはポリシーの判断であり、トラブルシューティングの手順ではありません。サービスを変える前にネットワーク所有者に何が許可されているか尋ねてください。ポリシーに反する回避策はいずれ閉じられるため、その回答をプロファイルの隣に記録し、次の人が同じ依頼を繰り返さないようにしてください。

トンネル後のDNSを別途確認する

トンネルが起動したら、VPNインターフェースのリゾルバ状態を調べ、内部名を一つと公開名を一つ問い合わせます。トンネルが通信を運んでいるのに内部名が失敗するなら、プッシュされたDNS設定が適用されておらず、それはトランスポートではなくクライアント統合の問題です。公開名が失敗し内部名が機能するなら、分割トンネルのポリシーは設定どおりに動作しています。

DNSの変更はリゾルバの所有者に任せてください。一つのテストを通すために管理されたリゾルバ設定を上書きすると、マシン上の他のすべてについてプライベート名が壊れる可能性があります。トンネルがリゾルバをプッシュしクライアントがそれを無視するなら、別の場所に静的エントリを追加するのではなくクライアント統合を修正してください。静的エントリは、誰かがネットワークを変えるまで失敗を隠します。どのリゾルバがどの名前空間に応答すべきかを書き留めてください。