二つの名前は同じ拠点を表しながら、まったく別の問いに答えます。vpn.branch.example はリモートの相手にVPNエンドポイントの場所を伝えるもので、トンネルが存在する前に解決されなければなりません。inventory.branch.example は権限を持つ利用者にプライベートアプリケーションの在り処を伝えるもので、トンネルが上がってから初めて意味を持ちます。片方を保守しても、もう片方には何の効果もありません。

どちらかをデバッグする前に、二つのレコードを名付けておく

両方を所有者とともに書き留めます。エンドポイントについては、公開アドレスを誰が更新し、VPNクライアントがどのように応答を更新するかを記録します。サービスについては、プライベートアドレスの所有者、レコードを持つゾーン、どのリゾルバが応答すべきかを記録します。

この短い一覧が、この分野で最も多い誤診を防ぎます。つまり、中だけに存在するレコードを直そうとして、正常な拠点トンネルを再起動してしまうことです。トンネルはサービス名の輸送手段であり、その権威ではありません。

変更が提案されたら、二つのレコードのどちらに触れるのかを尋ねます。誰も答えられないなら、その変更は予定を組める状態ではありません。

エンドポイントは、トンネルが存在する前に解決されなければなりません

拠点のインターネット接続が新しい公開アドレスを受け取ったとします。エンドポイントの更新プログラムが新しいアドレスを公開し、遠隔のVPN実装がその変わった応答を読めなければなりません。その応答を返すリゾルバは、トンネルなしで到達できなければなりません。そうでなければ、クライアントは見つけられないものに接続してからしか解決できない名前を追いかけることになります。

この起動時の依存ははっきり書く価値があります。すべての内部リゾルバがVPNの内側にあると、うっかり作りやすいからです。エンドポイント参照用にトンネル前の経路を残し、新しい応答がすぐ取り込まれると決めつけずに、クライアントの再接続の挙動を確認してください。

動的DNSには、レコード更新が越えられない限界もあります。レコードを更新しても、ファイアウォールのポートは開かず、NATマッピングも作られず、相手の身元も証明されません。公開されたアドレスのポートが閉じていれば、正しく解決できても何にも接続できないクライアントになります。

最後に、稼働中のクライアントは再接続するまでキャッシュされたエンドポイントを使い続けることがあります。公開、キャッシュ、再接続ポリシーをメモで分けておき、古い相手を壊れた更新プログラムと取り違えないようにしてください。

サービス名は、アプリケーションがどこにあるかを示します

ここでトンネルは健全なまま、インベントリサーバーが 172.26.14.20 から 172.26.14.35 へ移ったとします。公開エンドポイントのレコードは影響を受けず、プライベートサービスのレコードは変更が必要です。そのサービス用に予約したアドレスや固定割り当てを使えばこれは稀になり、意図した場合は権限ある更新経路が対応します。

ここで二つの更新の仕組みが混同されます。RFC 2136 はゾーン内のDNSレコードを追加・削除するプロトコルを定義しますが、商用の動的DNS事業者は別の目的でまったく別のHTTP APIを公開することがあります。片方を使うことは、もう片方が自分の環境にあることを意味しません。更新プログラムを書く前に、自分のゾーンが実際にどちらを受け付けるかを確認してください。

正しいプライベート応答は、最初の条件にすぎません。遠隔の呼び出し元がそれを使うには、クライアントにプライベートゾーンを持つリゾルバ、そのリゾルバへの問い合わせを許すポリシー、返ってきたアドレスへの転送が必要です。到達できないアドレスに解決される名前は、サーバー障害に見えるタイムアウトを生みます。

二つの経路を別々に試します

トンネルの外からエンドポイントを、内側からサービスを確認し、結果を二つの独立した事実として残します。

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

最初の問い合わせが失敗するなら、問題は公開の公開処理かトンネル前の解決経路であり、内部の変更では助けになりません。二つ目がアドレスを返しても三つ目がトンネル経由の経路を示さないなら、DNS層は正常で、転送ポリシーが正常ではありません。

アドレスが変わるたびにこの組を実行し、どちらのレコードが動いたかを記録します。「DNSを更新した」とだけ書いた引き継ぎは、二つのライフサイクルのどちらが実際に走ったのかを次の担当者に推測させます。

関連記事