PPTP と L2TP/IPsec がユーザー名の入力前に止まるのはなぜですか

ユーザー名の入力要求が出ないことは診断上の贈り物です：PPP がまだ始まっていないので、アカウント、パスワード、ドメイン ポリシーはまだ問い合わせられていません。PPTP または L2TP/IPsec 接続では、クライアントが資格情報を求めるのは、トンネルが存在し、サーバーが PPP セッションを開始した後だけです。その瞬間より前に失敗しうるのは転送、鍵交換、トンネル設定であり、「VPN が壊れている」よりはるかに小さい範囲です。

要求が出ないことで障害は三つの段階に絞られます

目に見えて成功した最後の段階は、それぞれ担当も対処も異なるので、書き留めてください。二段階前で行き詰まっているのにアカウント設定を推測するのは、午後が消える手順です。

要求なしにタイムアウトするクライアントは IPsec の関連付けを一度も得ていないので、障害は IKE か、そもそもパケットがゲートウェイに届くかどうかにあります。資格情報を検証していると表示してから落ちるものは、メッセージが示すより先へ進んでいます。要求のあとに拒否が来るのは PPP 認証であり、それはアカウントの記事に属し、この記事の話ではありません。

第一段階: ファイアウォールが黙って落とすプロトコル

PPTP は制御チャネルに TCP 1723、データ経路に IP プロトコル 47 を必要とし、両者は別々に流れます。多くのネットワークは 1723 を通し、プロトコル 47 を落とすため、交渉はできても何も運ばないトンネルができます。NAT を行うルーターには GRE 対応の通過も必要で、IPv6 だけのアクセス経路ではどのような設定でも PPTP を運べません。

IPsec 上の L2TP は IKE にポート 500、NAT 越えにポート 4500 を使い、そのうえで L2TP の通信自体を 1701 に包み、関連付けができた後は ESP が保護されたペイロードを運びます。二つの制御ポートだけを許可して ESP を許可しないと、まさにタイトルの症状になります：目に見える進行のあと、資格情報のダイアログより前にクライアントが死にます。携帯のテザリングから試すのは、クライアントの問題と経路の問題を切り分ける安価な方法です。

第二段階: 鍵でない鍵、提示されない提案

一致しない事前共有鍵は素早く静かに失敗し、よくあるのは、画面では正しく見えるのに貼り付け時の改行や末尾の空白を抱えた鍵です。Linux クライアントでは ダイアログが必ずしも真実の源ではありません：NetworkManager の L2TP プラグインは /etc/ipsec.d/ 配下のファイルに秘密を保持しており、/etc/ipsec.secrets がまだ取り込んでいる古い接続ごとのファイルが、たった今入力したファイルの代わりに使われます。そのファイルを安全な場所にコピーし、取り込み経路から外してから、鍵を手で入力し直してください。

この段階のもう半分は提案です。両端が同じフェーズ 1 のアルゴリズム群 — 暗号化、完全性、Diffie-Hellman グループ — と、フェーズ 2 に対応する ESP 変換で合意しなければ、関連付けはまったく成立しません。3DES、SHA1、MODP1024 しか提示しないゲートウェイは、より強いアルゴリズム向けに設定されたクライアントを拒否し、そのログは拒否した変換を名指しします。サービスを再起動する代わりにログを読めば、ログが不一致を名指しします。フォーラムのスレッドからアルゴリズム文字列をコピーするのではなく、ゲートウェイに実際にどの変換を交渉するのか尋ねてください：そのアドレスに向けた ike-scan が、交渉する変換を返します。唯一の提示がポリシー上すでに許されない暗号であるなら、修正はゲートウェイ側にあり、クライアントの弱体化ではありません。

Windows では鍵と認証方法が VPN プロファイルにあり、不一致は資格情報の要求の後ではなく前に現れます。受信側が Windows Server の場合は、リモート アクセスの役割がインストールされていること、証明書がクライアントの接続する名前に一致すること、どのポート フィルターも上記のプロトコルより狭くないことを確認してください。

第三段階: トンネルは存在するのに PPP が始まらない

IKE が完了しても要求が現れないときは、ファイアウォールではなくトンネルのデーモンを見てください。L2TP には UDP 1701 で待ち受けるもの — Linux では xl2tpd か kl2tpd、Windows ではリモート アクセス サービス — が必要で、インストール済みでも停止しているサービスは、クライアント側からは落とされたパケットとまったく同じに見えます。すでに確認した規則を開け直す前に、待ち受け側を確認してください。そのあと PPP が交渉する必要があり、最初の LCP 交換が静かな失敗の着地点になることが多いのです。

この段階の罠の一つはネットワークの障害ですらありません：Windows は同じ種類の VPN 接続を同時に一つしか許さないため、二度目の試行はエラー 937「この種類の別の接続が使用中です」を返します。これはローカルの規則で、回避策は別の端末、別のトンネルの種類、またはすでに存在する一つの接続の共有です。

推測するのではなく段階の順にログを読んでください

クライアントを停止し、起動し直し、コンポーネントがログを書く順に読んでください。つまり最初に IPsec のデーモン — strongSwan か Libreswan で、ipsec --version がどちらかを教えてくれます — 次に L2TP のデーモン、次に pppd です。障害の直前に最後に書いたコンポーネントが、その順序で後に来るものはまったく動いていないからこそ、調査すべき段階を示します。

キャッシュから再接続するクライアントは交換の一部を飛ばし古い結果を再現することがあるので、保存されたセッションではなく新しい接続で確認してください。到達性、鍵交換、トンネル、PPP を一つずつ、この順に確認してください。そうすれば出ない要求は謎ではなくなり、実際にたどれる一覧の二行目になります。その一覧は、ネットワーク担当チームに渡すものでもあり、そうでなければ、起動していないデーモンに住む障害のためにファイアウォールを調べるよう頼まれることになります。