一つのエラー、三つの秘密：どの VPN 資格情報が失敗したのか
クライアントはどの段階でも同じエラーを表示します。誰も確認していないパスワードをリセットする前に、関連付け、ユーザー交換、方式を読んでください。
「認証に失敗しました」というメッセージは、サーバー証明書、マシンの事前共有鍵、ユーザーのパスワードのいずれかを指している可能性があります。どれを指すかはプロトコルによって決まり、プロトコルごとに定義される秘密の組が異なるからです。間違った方をリセットしても、エラーはそのまま残ります。出口は、何かを編集する前に、そのプロトコルが幾つの証明を要求するのかを確定することです。
反対方向を向く二つの証明
トンネルは、正しいゲートウェイに到達したかどうかと、ユーザーが誰かという別々の問いに答える必要があります。ゲートウェイの証明はマシン単位で、サーバー証明書、事前共有鍵、または静的な公開鍵です。ユーザーの証明は人単位で、パスワード、トークン、クライアント証明書、あるいは何もなしです。これらは信頼の逆向きの方向であり、消費する素材も異なります。
IKEv2 はゲートウェイの証明を IKE_AUTH の中で行い、EAP を使う場合はその後でユーザーの証明を別の交換として実行します。IKEv2 の仕様はこれらを別々の節として保っており、一つのメッセージが両方のラウンドを覆うときにどこを見るべきかを示す強い手がかりです。
メッセージではなく段階を読む
どの段階で失敗しても、クライアントは同じ一つのエラー文字列を表示します、だから文字列そのものはほとんど情報を持ちません。情報を持つのは、各段階で確認できる状態、つまり関連付けが存在するか、ユーザー交換が始まったか、クライアントがゲートウェイの求める方式を提示したかです。表は段階をプロトコル名ではなく、その順で並べています。
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
ユーザーが打ち直せる資格情報にかかわるのは二行目だけです。残りの三行は構成上の事実であり、この食い違いこそが、こうした報告の多くが何も変えないパスワードリセットで終わる理由です。フィールドに触れる前に、証拠と一致する行を読んでください。
二つの秘密を持つプロトコルは手の内を見せる
L2TPを IPsec の上で使うと、二つの検査が別々のプロセスで起きるため数が可視化されます。IPsec 層が事前共有鍵か証明書で先に立ち上がり、そのあとで初めて内側の PPP がユーザーログインを試みます。
マシンの秘密が誤っていると関連付けは形成されず、ユーザーの資格情報は決して試されません。マシンの秘密が正しくユーザーの秘密が誤っていると、関連付けは存在し、トンネルがすでに上がったあとで PPP がログインを拒否します。どちらも二つの異なる出来事から画面上は同じメッセージになります。
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pager関連付けの一覧が空ならユーザー層は即座に排除されるので、パスワードより先にそれを確認してください。PPP の失敗が繰り返される確立済みの関連付けは逆方向、つまりユーザー層かその内側の認証プロトコルを指します。どちらの結論もクライアントのエラー文からは得られません。
パスワードのみのアクセスが実際に依存しているもの
パスワードのみのアクセスは L2TP、PPTP、SSTP、EAP を使う IKEv2 では普通です。WireGuard には、相手がユーザーではなく鍵であるため、そもそもその選択肢がありません。OpenVPN では答えはサーバーのクライアント証明書の要求から来て、証明書とパスワードの両方を求めるゲートウェイはフィールドに何を入力してもパスワードのみのクライアントを拒否し続けます。
必要な部品は同じ答えから導かれます。IKEv2 でのパスワードログインには EAP を話すクライアントが必要で、証明書ログインにはクライアントの秘密鍵とサーバーの連鎖が必要です。間違った方を導入すると、認証方式そのものが欠けているのに資格情報のエラーとして読めてしまいます。
一つだけ変えて、再テストする
まず、どのプロトコルが動いているか、秘密を幾つ定義するか、そのうちどれがユーザーではなくマシンに属するかという三つの事実を確定します。マシンは第一段階で失敗し、人は第二段階で失敗しますが、この二つを混同することがこの問題のすべてです。
次にちょうど一つだけ変えて、同じクライアントから再テストします。この規律が、混乱する失敗を次の人に説明できる修正に変え、誰も説明できない動く接続より役に立ちます。