Ubuntu 22.04 の L2TP タイムアウト: xl2tpd のトンネル不具合

デスクトップには接続中が表示され、IPsec は成功を報告しているのに、PPP インターフェースは決して現れません。syslog では同じトンネル番号が繰り返され、やがて試行は UDP 1701 でタイムアウトします。事前共有鍵やサーバー設定を編集する前に見極めるべき形はこれです——Ubuntu 22.04 では通常 xl2tpd のパッケージ退行であり、サーバーは最初から正しかったのです。

繰り返される syslog の二行が語っていること

失敗するセッションは一定間隔で二行を出力します——デーモンが受信した制御メッセージのトンネルを見つけられず、渡された呼び出し識別子とトンネル識別子を書き出すのです。やがて再試行カウンターが上限に達し、接続はポート 1701 のタイムアウトで閉じます。アドレスや識別子は偶然であり、形が重要なのです。IKE は完了し、L2TP の制御トラフィックは届いたのに、デーモンはそれを自分がすでに作ったトンネルに関連付けられませんでした。

つまり不具合は L2TP 制御と PPP の間にあります。秘密鍵、PPP オプション、リモートサブネットについてはまだ何も試されていません。

IPsec が本当に成功したか確認する

二つの確認がこれを資格情報の問題から切り分け、どちらもパッケージを変更する前に済ませるべきものです。

ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"

状態の出力には接続とその状態が並び、トンネルが確立していればフェーズ一とフェーズ二が完了しています。共有鍵が見つからないというログ行は秘密鍵だけを指すので、いったん止めてまずそれを直してください。IPsec が確立しているのに L2TP のタイムアウトがまだ出るなら、疑うべきはデーモンだけです。丸一日の再試行ではなく、一度の試行の正確な行を保存しておきましょう。

確認するのは xl2tpd のビルドであり、リリース名ではない

Ubuntu の jammy 版 xl2tpd 1.3.16 のビルドはリンク時最適化を有効にし、サーバーの SCCRP 応答にあるトンネル識別子の解析を壊しました。その結果デーモンは、自分が作ったトンネル宛ての制御パケットを捨ててしまいます。配布名よりもバージョン文字列のほうが重要です。

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

修正済みパッケージは 1.3.16-1ubuntu0.1 なので、この接尾辞のないビルドは修正前です。ポリシーの出力はアップグレードがどの候補を入れるかを示し、保留一覧は修正が届かない理由を説明します。パッケージが入手できる場所では、手作業でファイルを編集するのではなく、アップグレードして通常のプロファイルで再接続してください。古いビルドが入っている間は、モジュールを再構築したり秘密鍵を変えたりしないでください。

変更後に PPP を確認する

アップグレードの成功は、壊れていた層で証明されます。アイコンが変わったかではなく、PPP が上がったかを確認してください。

ip -4 addr show ppp0
ip route | grep ppp

インターフェース一覧にはローカルアドレスとピアアドレスが表示され、ルートテーブルにはトンネルのプレフィックスが載るはずです。syslog には、トンネルが受け入れられ、pppd が両方のアドレスを報告する様子が、トンネル未検出の行を繰り返さずに現れるはずです。PPP が上がっているのに通信が失敗するなら、L2TP の段階はすでに役目を終えているので、次はルーティングか MTU を見てください。動作したパッケージのバージョンをマシンのメモに記録し、将来の再インストールで壊れたビルドに戻らないようにしましょう。

修正済みパッケージが入手できない場合、文書化されている代替案は 1.3.16 または 1.3.17 のローカルソースビルド、kl2tpd への切り替え、固定したダウングレードです。どれも書き留める価値のある保守コストを伴います。