ddclient が VPN 出口を公開する：検出元を修正する

あなたの DNS 名は今や VPN プロバイダのアドレスに解決され、更新ログはまったく健全に見えます。この組み合わせは正常です。ウェブベースの検出プローブは外部サービスに、どの送信元が見えるかを問い合わせるため、全トンネル VPN 経由で要求が出ると、答えは自宅の WAN アドレスではなく VPN の出口になります。更新ツールは仕事を果たしており、仕事の向き先が誤った観測でした。

名前が何に届くべきかを確認する

受信する自宅サービス用の公開名には、承認された受信接続がそのサービスに届くアドレスが必要です。共有プロバイダの出口を公開しても、そこに受信転送が整うわけではなく、どれだけ DNS を設定してもその転送は生まれません。更新ツールに触れる前にこれを決めてください。どちらのアドレスが正しいかは、これで決まります。

VPN クライアントのトンネルアドレス用の非公開名は、別の答えを持つ別の問題です。これは非公開 DNS に属し、公開の検出サービスはまったく必要ありません。二つの要件を混ぜると、機能している設定が誰も求めていないアドレスを公開し始めます。

インターフェースのアドレスにも解釈が必要です。自宅ルータの背後にあるノート PC のアドレスは公開 WAN アドレスではなく、ルータの WAN アドレスさえキャリアグレード NAT の背後にあることがあり、そこでは公開しても受信到達性は生まれません。

何かを変える前に値を再現する

二つの経路を別々に観察します。トンネルが上がっているとき、プローブは出口を報告します。トンネルが下がっているとき、またはプローブを物理インターフェースに束縛したときは、自宅のアドレスを報告します： curl --interface eth0 https://ifconfig.me。この二つの答えが異なれば、更新ツールに触れずに不具合を再現できたことになります。

次に、更新を実行せず設定だけを確認するモードでクライアントを起動します（例：ddclient -verbose -noexec）。選択された検出方法を読み取ってください。詳細出力には方法と取得した値が示され、これが編集前に必要な事実です。

検出を選んだ経路に向ける

名前が自宅の WAN アドレスを公開すべきなら、検出はそのアドレスを観測しなければなりません。おおまかな優先順に三つの選択肢があります。ルータ自身の対応更新ツールに公開させる。ルータが実際に配信するページに対して ddclient のルータ状態検出を使う。ウェブプローブを残すなら、トンネルの外に出るよう物理インターフェースに束縛する。

ルータ状態の経路では、新しい ddclient は usev4 と fwv4 というオプション群を使い、周囲のページ文に対する任意のスキップパターンも指定できます。インストール済みのバージョンの README を確認してください。古い版は同じ考えを use と fw で書いており、誤った版からコピーしたオプション名は起動時に失敗します。

ウェブ検出を残す場合、プローブの経路制御と更新 API 呼び出しの経路制御は別の判断であることを忘れないでください。更新呼び出しがレコードを届け、プローブが届ける値を決めます。

秘密情報とバージョンを整理する

ルータの認証情報とプロバイダのトークンは保護された設定ファイルに置くもので、シェル履歴に残るコマンドラインには置きません。詳細トレースには両方が含まれ得るので、チケットに貼る前に伏せてください。認証済みルータページの取得を要する検出方法は、ファームウェア更新をまたいでその認証情報を機能させ続けることも要求します。プロバイダのトークンと同じ注意で保管してください。

ddclient README は検出の手法とそのオプション名を説明しています。IPv4 と IPv6 の結果を一つのレコードに混ぜず、ある版に存在するオプションが別の版にもあると仮定しないでください。

値を検証し、次に到達性を確かめる

ライブ更新を許可する前に提案アドレスを意図した終端点と比較し、承認された更新を一度行った後に権威 DNS を確認してリゾルバのキャッシュを見込みます。低い TTL は待ち時間を短くしますが、誤った値を正しくはしません。

レコードが正しくなってから初めて、必要なファイアウォールと転送が承認済みの状態で、独立したネットワークから受信サービスを試してください。正しい A レコードは到達可能なサービスを証明せず、固定 VPN リースは非公開の命名を簡単にしても、誤った WAN を指す公開ホスト名を直しません。