ルーティング型 OpenVPN トンネルで名前解決が失敗する理由

ホストがアドレス宛の ping には応答するのに、名前での検索はすべて失敗する。トンネルは上がっており経路も存在するので、VPN の設定ミスと結論したくなる。より有用な結論は、その検索がそもそもルーティング可能ではなかったということであり、ルーティング型トンネルが運ぶのはユニキャスト IP である一方、当の問い合わせは向こう側に存在しないセグメントを探すブロードキャストだった。層の食い違いが見えれば、修正は費用順に自ら並ぶ。

誤解：名前が失敗するからトンネルが壊れている

症状が説得力を持つのは、名前の層より上がすべて動いているからだ。アドレスは経路を持ち、インターフェースは上がり、相手は ping に応答する。失敗したのは、ポイントツーポイントのリンクを渡る道を一度も持たなかった検出の仕組みであり、これは壊れたトンネルとは別の話だ。この二つを切り分けることが診断の大半を占める。

トンネルの不具合として扱うと、役に立たないプロファイル編集に進んでしまう。オプションを足しても、暗号を変えても、クライアントを入れ直しても、ブロードキャストは元の場所に残る。

修正の名を挙げる前に、失敗した仕組みの名を挙げる。ブロードキャストを使う検索にはセグメントが要り、リゾルバを使う検索には問い合わせ先のアドレスが要る。

TUN が運ぶもの、運ばないもの

TUN デバイスは IP インターフェースであり、それがルーティング可能にする理由だ。OpenVPN はクライアントにアドレスと経路の集合を渡し、以後クライアントは相手にデータグラムを送る。このモデルには、すべてのホストがすべてのフレームを聞く共有リンクを作る要素はない。

検出のトラフィックはこのモデルにまったく合わない。古い Windows の名前問い合わせ、SSDP の告知、mDNS の要求は、単一の宛先ではなくセグメント上の全員に送られる。ルーティング型リンクには送るべき「全員」が存在しない。これらの仕組みはいずれも共有媒体を前提にしている。

したがってトンネルが健全でも検出は完全に失敗しうる。VPN が落ちていると誰かが報告したとき、握るべきはこの一文だ。

ブリッジングは境界を取り除くことで機能する

TAP デバイスはフレームを運び、ブリッジがそれを実在の LAN セグメントにつなぐ。するとクライアントはそのセグメント上のアドレスを持ち、そのブロードキャストを聞く。ブリッジングが名前の問題を治すように見えるのはそのためだ。同時に、アドレス付与をそのセグメントに依存させることにもなる。

治療はルーティング境界の除去であり、トンネル内部の新しい名前機能ではない。セグメントがブロードキャストするものは今やリンクも越える。

小さな実験室なら妥当な取引だ。分散した人員構成ではめったに成立しない。

DNS と WINS を配るのがより狭い修理

クライアントに問い合わせ先を具体的に与える。dhcp-option DNS と dhcp-option DOMAIN は内部名をゾーンを知るサーバーに向け、依然として NetBIOS に頼る Windows クライアントも同じ方法で WINS サーバーを受け取れる。トンネルはルーティング型のまま、セグメントはあるべき場所にとどまる。

うまくいくかは二つの条件で決まる。指定したサーバーがゾーンに応答すること、そして問い合わせがトンネルを通ることを許されていることだ。

リゾルバはサーバー自身のシェルからではなく、クライアントから試す。ローカルで動くリゾルバは、トンネルが何を運んでいるかについて何も語らない。

どの層が失敗したかを見極める

まずアドレスに ping を打ち、次に名前を解決して、どのサーバーが応答したかを読む。ゾーンをホストしていないサーバーの否定応答は、マシンから一度も出なかった問い合わせとは見え方が違う。解決はするが接続を拒む名前は、まったく別の第三の問題だ。

マルチキャストも同じ壁の向こうにある。224.0.0.251 のようなグループは既定ではルーティング型トンネルを越えて転送されず、マルチキャストを理解する経路や LAN 上のリフレクターがなければ、グループ向けの経路だけでは足りない。