MSCHAPv2 は VPN プロトコルではない：まずトンネルを確認する

ユーザー名とパスワードは搬送路の内側を通り、MSCHAPv2 はその中を流れる方式の名前でしかありません。同じアカウント文字列がコードを一行も共有しない構成にも現れるため、クライアントプロファイルを選ぶ前に、どのトンネルが運ぶのかを尋ねてください。渡されたプロファイルはどれも二つの決定を符号化しており、手順書がその片方しか印刷していない場合でも変わりません。以下の順序は、運用担当者が推測せずに答えられる事柄であり、あなたがパケットを取得せずに確認できる事柄です。

認証はトンネルの内側を通る

VPN は一見ひとつに見える二つの決定を下します。両端が保護されたチャネルをどう築くか、そしてその内側で人が身元をどう証明するかです。後者は人が入力するものなので手順書に印刷され、前者はクライアントがそもそも動くかどうかを決めるもので、人々が飛ばしてしまうのはこちらです。運用担当者には、まず搬送路、次に方式の順で名を挙げるよう求めてください。二つの接続が同じアカウント名と同じパスワードを要求しながら、ログイン欄の下では実装をまったく共有していないことがあります。

だからこそ、同僚の動いている端末からコピーした設定が、サーバーが双方の資格情報を受け入れている場合でも自分の端末で失敗することがあります。違いは資格情報ではなく、それを包むプロファイルでした。 双方が正しいのに何もつながらない というのは多くの場合この混同であり、搬送路の名を挙げた瞬間に解けます。

同じ方式が現れる三つの場所

PPP では認証の段階がリンクの存在を待ち、 RFC 2759 が MS-CHAPv2 をその段階として定義しているため、この方式は L2TP や古い PPTP の配備にも現れます。トンネルが先に終端し、PPP の交渉はその内側で起きるので、PPP の段階で失敗してもサーバーログではトンネルが確立したように見えることがあります。資格情報が拒否されたと結論する前に、この二つの段階を別々に読んでください。したがって L2TP 向けに設定されたクライアントは完全に正しくても、IKEv2 しか話さないゲートウェイにとっては誤ったクライアントになり得ます。

IKEv2 は代わりに EAP-MSCHAPv2 を鍵交換の内側に置くので、同じ資格情報が別の時点で失敗し、セッションエラーではなく認証エラーとして現れます。Android のプラットフォーム IKEv2 プロファイルが日常的な例で、PPP のオプションではなくサーバー証明書か識別子を求めます。アカウント名はどちらの構成でも同一なので、どちらを持っているかは分かりません。それを決めるのは運用担当者の対応プロトコル一覧だけです。

TLS ベースの VPN は、独自のユーザー名とパスワードの欄を持ち、やり取りのどこにも MS-CHAPv2 がない第三の構成を加えます。したがってパスワード欄が見えることはその背後にあるプロトコルの証拠にはならず、画面は見慣れた形になるよう作られています。プロトコルはクライアント画面の形ではなく、サーバーの文書で確認してください。

本当に必要な答え

依頼は、半分だけ答えるのが難しい箇条書きで送ってください。トンネルのプロトコル、その内側の方式、そして自分のプラットフォームで運用担当者が対応するクライアントを尋ねます。続いてゲートウェイの身元と信頼の設定、アカウントの形式、接続が上がった後に到達できるべきものを尋ねます。

最初の三つは、動くプロファイルが得られるかどうかを決めます。最後の三つは、そのプロファイルが仕事の求めることを果たすかを決めます。次の担当者も同じ六つの質問をするので、答えはチケットに添えて残してください。答えが欠けている箇所は、運用担当者がまだ下していない決定として扱い、自分が推測できるものとして扱わないでください。

ゲートウェイの検証を緩めない

サーバーもクライアントに対して自分の身元を証明しており、やり取りのその半分は飾りではありません。頑固なプロファイルをつなげるために証明書の検証を切ることは、応答するあらゆる端点を受け入れることであり、誰も到達を意図しなかったものも含まれます。また、実際の不一致を解決せずに隠すので、障害はより遅く、より分かりにくい時点へ押しやられます。検証を切る必要があるプロファイルは、検証できない何かを指しているプロファイルです。

不一致はたいてい名前で、一つのホスト名に発行された証明書は、プロファイルがアドレスを呼ぶと失敗します。検証を切るのではなく名前を呼んでください。非公開の認証局は、端末にルートが一度も渡されていないと失敗し、修正はそのルートを承認された経路で配ることです。管理された環境では、運用担当者が身元と信頼の基点を用意し、プロファイルがその両方を参照することが期待されます。欄が無い場合は、検証を諦めるのではなく成果物を求めてください。

プロファイルを合わせ、次に各段階を証明する

搬送路が分かったら、そのクライアントの文書化された手順に従い、求められた欄だけを入力してください。存在するから埋める追加の欄もやはり誤った値であり、必須の欄より後に失敗します。最初の接続に成功した後はプロファイルを変えずに保存し、後の編集を動作が分かっているものと比べられるようにしてください。

次に、トンネルが確立し、利用者が認証され、割り当てられたアドレスと経路が現れ、許可されたサービスが一つ応答するかを段階ごとに検証します。各段階はサーバーにそれぞれログ行を残し、順に読むことで曖昧な苦情が具体的な所見に変わります。基盤が運用担当者の説明する構成をもう対応していないなら、それは移行の話であり、端末ですべての旧来の選択肢を有効にする理由ではありません。搬送路、方式、プロファイルは三つの別々の答えであり、動く接続では三つが一致しています。