エラー809はログインの問題より先に経路の問題である

エラー809が何を伝えているかは、プロファイルのプロトコルが想定どおりか、経路がそのプロトコルを通すか、ゲートウェイがその試行をそもそも見たかという三つの条件で決まる。これらに答えるまでは、このエラーはタイムアウトであり、タイムアウトは資格情報への判定ではない。順序が重要で、間違った条件を先に変えると他の二つの証拠が壊れる。

塞がれたポートと誤ったパスワードはまったく違うメッセージを生み、809が後者であることはまれである。

プロファイルが使うプロトコルを確認する

サーバー名、アドレス、トンネルの種類を運用者の現在の指示と照合し、その種類がどのトランスポートに依存するかを記録する。この三つの値は一体であり、古いトンネルの種類を伴う正しい名前は誤った名前と同じように失敗する。IKEv2はUDP 500と4500に依存し、ネイティブのESPトラフィックはTCPやUDPではなく独自のプロトコルとして許可する必要がある。古い設定からコピーしたプロファイルは、サーバーがもはや提供しないトンネルの種類を指していることがある。ダイアログのラベルから推測せず、運用者から値を得ること。

同じホスト名のブラウザーページはまったく別のサービスを検査する。ホストが生きていることは証明できても、失敗したネゴシエーションについては何も証明できない。

資格情報ではなくネットワークを変える

ポリシーが許すなら、同じプロファイルを別の信頼できるネットワークから試し、クライアントとサーバーは変えずにアクセス経路だけを違いにする。他所での成功は元の経路でのフィルタリングを示し、どこでも失敗するならエンドポイントかプロファイル自体を示す。ゲートウェイがその試行を見たかを運用者に尋ねるべきであり、サーバー側に対応するイベントがないクライアントは明示的な拒否とは別の境界だからである。

レジストリの場当たり的な変更やファイアウォールの停止はこのコードについてよく言われる助言だが、どちらも確認された診断から導かれるものではない。この配備における文書化された修正は何かを運用者に尋ねること。

コードを次の段階へたどる

後続の試行が認証まで到達して別のコードを出すなら、その新しい段階に従い、元のタイムアウト診断は捨てる。経路の問題をアカウント調査に持ち込むと双方で時間を無駄にする。プロトコル、失敗した段階、ネットワーク比較を行ったかどうかを記録し、次の担当者がダイアログの文言ではなく証拠から始められるようにする。

コードを判定ではなく段階の目印として扱うべきで、その読み方が五分の確認と失われた午後の差になる。

最初に変えないもの

資格情報、ロックアウト状態、証明書ストアはいずれも最終的には注意に値する。どれも809が通常始まる場所ではなく、一つを先に変えると経路を見つけたはずの比較が失われる。これらの確認はネットワーク試験の後に回すこと。ネットワークを変える間はクライアント、プロファイル、サーバーを固定し、何を変えたかを記録する。

運用者が最近エンドポイントを変えたなら、記憶から再構成せず現在の詳細を求めること。存在しなくなったアドレスはまさにこの種の失敗を生む。

プロトコル、試したネットワーク、ゲートウェイの見え方を記録する。この三つでほとんどの809の報告は片づく。