TCP は動くが UDP は同じポートで別のサーバーに届く

あるプロファイルは TCP では動き、UDP では証明書の警告とともに失敗します。直感的な読みは UDP 経路が信頼を壊したというもので、直感的な修正は証明書を受け入れることです。どちらの前提も、症状を完全に説明する一つの可能性を飛ばしています：二つのトランスポートが別々のマシンに届いたのです。転送ルールはプロトコルごとに照合され、一つのポート番号の TCP 側と UDP 側を同じホストに向けるよう強制するものはありません。

一つのポート番号、二つの独立したルール

転送とは、プロトコル、宛先アドレス、ポートを鍵にした表引きです。TCP 1194 用のルールと UDP 1194 用のルールを持つゲートウェイは、二つの独立した判断を表しており、それらは別々の内部ホストを指せます。共有された番号は人間のための便宜であり、ネットワークが強制する性質ではありません。ポート番号はラベルとして扱い、サービスの定義として扱わないでください。

意図したルールではなく、実際に効いているルールを見てください。宛先アドレス、変換後のポート、入口インターフェースがすべて関与し、以前の移行から残ったルールが両半分の食い違いのよくある原因です。

ほかを変える前に、両方の対応を書き留めてください。その二行が仮説のすべてです。

クライアントが実際に検証したこと

ハンドシェイクの間、クライアントは設定された信頼と期待する名前に対して証明書を検査します。予期しない証明書は、身元の検査で落ちた成功した検証であり、相手が到達しようとした先でないときにはこれが正しい結果です。それを拒否することはクライアントが動いている証拠であり、トランスポートが壊れている証拠ではありません。報告された名前を報告されたチェーンより先に読んでください：クライアントが比較したのは名前だからです。

この区別が重要なのは、二つの失敗が別々の修正につながるからです。信頼の問題には信頼の修正が要り、予期しない相手には経路や転送の修正が要ります。

クライアントがどの身元を報告したかを記録してください。その名前が、どのマシンが応答したかを示す最も強い手がかりです。

試行をサーバーと突き合わせる

プロファイル、公開アドレス、トランスポート、クライアントが使ったポートを記録してください。次に試行の時刻を、到達しようとしたサーバーのログと照合します。そこに記録がないことは手がかりであり、ファイアウォールが破棄した証明ではありません：配備ごとにログ水準が違うからです。時刻印と送信元アドレスを併せると、どちらか一方より絞り込めます。

出くわした証明書の身元を、管理チャネル経由で期待される身元と比較してください。チャネルの外で比較することが、この検査を信頼できるものに保ちます。

二つのトランスポートが同じバックエンドを共有していると結論づける前に、古い転送ルール、代替のリスナー、負荷分散の経路を確認してください。どれも片方のトランスポートに触れずに流れを別へ向けられます。

誤った相手に合わせて信頼を直さない

予期しない CA を取り込むと症状は消え、クライアントが誰を信頼するかが変わります。これは接続失敗より悪い状態です：食い違いを解決するのではなく隠すからです。トンネルが上がるかどうかだけを見るために検証を切るのも同じです。

相手が正当だが意図していないものだと分かったら、正しい対応はそれを退役させるか、ルールを正しいホストに向けることです。信頼ストアは棚卸しの誤りを突き合わせる場所ではありません。

拒否の文言を保存してください。クライアントが見たものの唯一の記録です。

修正後、新しい流れを試す

対応を直し、そのうえで新しいクライアントセッションで接続してください。状態を持つ変換は既存の流れを古い宛先に向けたままにでき、確立済みの接続が変更を生き延びて判断を誤らせることがあります。新しく開始し、意図したサーバーのログで試行を処理したことを確認してください。

二つのトランスポートが同じサーバーに届くことが示せて、それでも挙動が違うなら、残る違いはそのサーバー自身のリスナーと設定です。トランスポートの比較は、端点の身元が確定して初めて意味を持ちます。