L2TPは接続するのにPPPネゴシエーションが失敗する：どのフェーズか

IPsecトンネルが確立し、クライアントは保護されたピアを表示し、その後に何かがプライベートサブネットへ届く前に接続が切れる。この隙間はPPP自身の仕事で、リンクオプション、ユーザー認証、アドレス割り当てはすべて暗号化トンネルが存在した後に起きる。最初のフェーズの交換が成功しても、パスワードや内部アドレスは渡されない。フェーズを順に読めば、失敗はたいてい自分で名乗る。

トンネルは最初の層にすぎない

L2TPはIPsecで保護されたトンネルの中でPPPフレームを運ぶので、パケットをルーティングする前に独立した二つのネゴシエーションが成功しなければならない。外側は両端が鍵と身元について合意していることを示す。内側はリンクパラメータ、ユーザーが認証されるか、クライアントがどのアドレスを受け取るかを決める。

PPP内部の失敗は、ステータスランプを一つしか出さないクライアントでは、壊れたトンネルに見える。トンネルの問題として扱うと、鍵の再生成、サービスの再起動、そして結局は一度も間違っていなかった共有シークレットの交換に至る。役に立つ見分けは安く、ピアとの交換が完了してクライアントがユーザー名の入力を求められたか認証段階に進んだなら、トンネルは正常である。その後のすべてはPPPに属する。

成功した最後のフェーズを読む

ログを前へたどり、完了しなかった最初のフェーズで止まる。まずLCP、次に認証、次にIPv4パラメータのためのIPCPが来る。

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

LCPのタイムアウトは、両端が基本的なリンクオプションで合意しなかったことを意味し、パスワードの誤りではなくプロファイルの不一致か内部プロトコルの遮断である。明示的な認証拒否は逆のケースで、リンクは上がったが片側が資格情報を拒んだ。認証成功後のIPCPタイムアウトはアドレスプールかサーバーポリシーを指す。どれも担当者も修復方法も違うからこそ、最後のエラー文よりフェーズが重要なのだ。

ログの抜粋はフェーズ名と一緒にチケットへ残す。フェーズの境界なしに貼られた末尾は次の読み手に推測を促し、ここでの推測は一時間の損になる。

クライアントとサーバーの合意

両端が同じ認証方式を受け入れる必要があり、保存済みプロファイルはサーバーが前四半期に廃止した方式を要求することがある。管理された配備ではサーバー側も見えず、拒否理由は通常デバイスではなくユーザーに対して記録される。

五つの方式を提示するクライアントはどれが失敗したかを覆い隠すため、すべての旧式オプションではなく対応する方式を一つ有効にする。サーバー側ポリシーと正確な拒否理由を管理者に尋ねるが、これにパスワードの公開は不要である。一つのクライアントを救うために有効にした旧式方式は、そのファイルをコピーした全プロファイルに広がりやすい。

ログインではなくアドレスを確認する

ログインの完了は使用可能なセッションではない。IPCPが内部アドレスを交渉し、プールの枯渇やクライアントを拒否するポリシーがあっても、トンネルは接続したままルーティング先がないことがある。

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

まず内部アドレスを確認し、その次に本当に必要なリソースへのルートとリゾルバを見る。内部アドレスはウェブサイトが報告する公開出口ではなく、この二つを混同すると存在しない漏洩を探し回ることになる。プライベートリソースは名前より先にアドレスで試し、DNSの失敗をルーティングの失敗と誤らないようにする。

フェーズ、方式、アドレスを一つのメモに書き、日付を入れる。同じアカウントが一か月後にまた失敗したら、そのメモが五分の確認と新規調査の差になる。別のフェーズでの失敗は、クライアントが一つのダイアログしか出さなくても別のインシデントである。