VPN のどの段階で失敗したか：IPsec、L2TP 制御、PPP 認証

最後に成功した段階を特定し、その層だけを直します。IPsec、L2TP 制御チャネル、PPP 認証、アドレス割り当てのいずれかです。

パスワードを変えても何も動かなかったのは、障害が PPP にあったわけではないからです。L2TP/IPsec は五つの大きく異なる受け渡しに対して一つの接続エラーを報告し、それぞれの受け渡しに独自の修復があります。逆方向に進み、最後に成功した段階を見つけて、その後に続くものだけを変えてください。以下の順序は、最初にどの証拠を集めるかも決めます。

四つの質問に順番に答える

一部のクライアントはプロファイルを切断して再接続するまで前のエラーを表示し続けるため、新しい試行を強制してください。そのうえで、IPsec のセキュリティ協定は存在したか、L2TP 制御接続と呼び出しは現れたか、PPP は認証の判定に達したか、IPCP はクライアントにアドレスを渡したかと問いかけてください。最初のいいえが直すべき段階です。その先はすべて未検証なので、協定が一度も存在しなければ、拒否されたユーザー名は何も証明しません。

比較する前に両端の時計を合わせてください。IPsec を通過して PPP で失敗した再試行は、クライアントが最後のメッセージだけを表示し、サーバーのログが前の試行をまだ保持していると、一つの障害に見えます。最も騒がしい行ではなく、タイムスタンプで読んでください。

手元にユーザーのスクリーンショットしかないときは、最も安価な切り分けに頼ってください、つまり誤った事前共有鍵と決して応答しない xl2tpd は Windows のダイアログに同じ文言を出すものの、一方は両端で変更する秘密が必要で、もう一方はサーバー側でデーモンを起動するかファイアウォール規則が必要です。中間の装置は、トランスポートモードの IPsec が包んだ後の内側 1701 を落とせないので、存在しない経路フィルタを探さないでください。

各層が実際に担うもの

IPsec は二つのピア間のパケットを保護し、L2TP はその保護された経路の内側で PPP セッションを運ぶため、RFC 3193 は独自のトンネルではなくトランスポートモードを規定しています。クライアントのラベルは L2TP なので、トンネルとログインが一つの仕組みに感じられます。そうではありません、L2TP 制御接続は展開が有効にする場所でトンネルの端点を認証し、PPP はサーバーポリシーに従って CHAP、PAP、MS-CHAPv2 でユーザーを別に認証します。

この分離が、人が混同し続ける二つの秘密を説明します。事前共有鍵は IPsec のピアを認証します。ユーザー名とパスワードは PPP に対してユーザーを識別します。証明書で認証するプロファイルに Windows の共有秘密を再入力しても失敗する段階では何も変わらず、PPP のパスワードを編集しても欠けた保護チャネルは供給できません。同じ自制が身元確認にも当てはまり、トンネルを得るためにピアの身元や証明書検証を切らないでください、そのとき接続するのは経路であり、ピアではないからです。

認証も PPP の終わりではありません。ユーザーが受け入れられた後、IPCP はクライアントのアドレスと、サーバーが渡す用意のある DNS と WINS のオプションを交渉します。CHAP や MS-CHAPv2 を通過してもアドレスなしで終わることがあり、これはルーティングの問題ではなく PPP 内部の障害です。IPsec なしの素の L2TP は有効なまま保護されないので、接続成功はトラフィックが保護されていることを決して証明しません、クライアントのラベルではなく、サーバーが何を強制するかを見てください。

最初に欠けた段階で判断する

表は最初に欠けた項目で、左から右へ読んでください。右の列がその時点で価値のある唯一の作業で、その左はすべて証明済みであり、再試験は情報を加えずに障害対応の時間を焼くだけです。

First thing missingWhat it meansChange this
No IKE reply on 500 or 4500The path or the listener never answeredFirewall, NAT-T forwarding, server listener
IKE runs, no IPsec associationIdentity, key, or proposal mismatchProposal and PFS set, pre-shared key, local and remote ID
Association up, no L2TP control connectionInner signalling never reached xl2tpdUDP 1701, tunnel and session sections, NAT encapsulation
Control connection up, PPP auth refusedThe user or method was rejectedCredential format, allowed auth method, account policy
PPP auth accepted, no address assignedIPCP never completedAddress pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd
Address assigned, applications failThe inner path is wrongRoutes, DNS, MTU or MSS, server forwarding

三つの行には警告が必要です。1701 の行は、NAT 背後の Windows クライアントがたいてい落ちる場所で、協定は完成し、その後に何も届かず、原因は悪いパスワードではなくカプセル化です。IPCP の行は経路問題と誤読される行で、Windows は欠けたアドレスをエラー 720 に包み、トレイのアイコンは接続が失敗したとしか言いません、この障害は認証の後、ルーティングの前にあります。最後の行はまったく IPsec の障害ではありません、トレイのアイコンが切断と言ってもです。

層を分けるコマンド

strongSwan を使う Linux サーバーでは、swanctl --list-sas が確立した協定をピアの身元とともに一覧し、ipsec statusall は古い strongSwan と libreswan のホストを対象にします。その下で ip xfrm state はカーネルの実際の協定を示し、ss -lunp | grep 1701 は xl2tpd がどこに束縛されているかを証明します。xl2tpd -D を前面で実行すると制御接続と呼び出しが現れるのを確認でき、/etc/ppp/options.xl2tpd で pppd のデバッグを有効にすると提示された方式と応答が見えます。

ログが認証成功を示したら、次の問いは IPCP が完了したかです。/etc/xl2tpd/xl2tpd.conf の [lns default] セクションにある ip range にまだ空きアドレスがあるか、クライアントが期待するなら /etc/ppp/options.xl2tpd が本当に ms-dns と ms-wins を持つかを確認します。枯渇したプールと欠けた DNS オプションは回線上で異なって見え、前者はアドレスなしと 720 を残し、後者はアドレスは与えるがリゾルバーがないため、名前は失敗し生のアドレスへの ping は通ります。どちらもパスワードの再入力では直りません。

クライアント側では NetworkManager の L2TP プラグインが pppd の会話をジャーナルに書くので、journalctl -u NetworkManager -b はふつうトンネルは上がり認証が拒否された状態とトンネルがまったくない状態を切り分けます。Windows では Get-VpnConnection がプロファイルの実際の認証設定を報告し、イベントビューアーの Application 配下の RasClient イベントが失敗したコンポーネントを示します。ダイアログが曖昧すぎるときは netsh ras set tracing * enable を有効にします。

キャプチャには一つの注意が要ります。トランスポートモードの IPsec では内側の UDP 1701 が暗号化されるので、外側インターフェースでのキャプチャには ESP、または NAT-T なら UDP 4500 が映り、L2TP はまったく映りません。キャプチャに 1701 がないのは想定内で、ポート遮断の証拠ではなく、ESP や 4500 のカウンタが動くかを見てください。

NAT、MTU、経路：スタックがあなたを誤らせる場所

NAT は何かが認証される前に前提を壊します。ESP は独自の IP プロトコルなので、ピアがカプセル化しない限り変換装置はそれを捨て、UDP 4500 がそれを提供します。自らが家庭用ルーターやクラウド NAT ゲートウェイの背後にある Windows サーバーでは、PolicyAgent キーの下で AssumeUDPEncapsulationContextOnSendRule を 2 に設定してマシンを再起動するまで IPsec 段階はエラー 789 で失敗し、障害は閉じたポートと区別できません。NAT 背後のクライアントは簡単で、サーバーに公開アドレスがあれば UDP 4500 の NAT-T が運び、その値は関与しません。

PPP が上がると、ブラックホール MTU が死んだトンネルを装い、小さなパケットは通り、TLS ハンドシェイクやページ読み込みが止まり、クライアントは接続中と表示したままかもしれません。サーバーを責める前にインターフェースの MTU を下げるか、ゲートウェイで MSS を絞ってください。分割トンネルのルーティングも偽装者で、誤ったマスクで押し出されたサブネットはトンネルを健全なまま一つのアプリを到達不能にします。私有ホスト名は独自の跳躍を加え、問い合わせがローカルリゾルバーを通るなら、どの経路も試される前に名前解決が失敗します。

資格情報に触れる前のチェックリスト

一覧を順に進め、最初に失敗する項目で止まります。どの手順も安価で、それぞれが編集の一つの種類を丸ごと除外します。

  1. 協定が両端に存在することを、接続済みのラベルではなくピアの身元で照合して確認します。
  2. UDP 1701 が xl2tpd に届くことを確認します、呼び出しのない協定があなたの障害です。
  3. パスワードが違うと決める前に、PPP の判定、認証されたなら IPCP の結果を読みます。
  4. ここで初めて、サーバーが期待する形式で資格情報を再入力します、ドメイン接頭辞はアカウントを変えるからです。
  5. それでも失敗するなら、両端を揃えたタイムスタンプでキャプチャし、段階ごとに比較します。

二つ目の手順で止まるのは経路かカプセル化の問題で、パスワードの編集では動きません。三つ目の手順で止まるのは、ログが直すべき方式やアドレスプールをすでに示しているということです。どちらにせよ次の変更は正当化できるものになり、関与していなかった設定を巡るのをやめられます。

関連記事