L2TP のデバッグログが空？ エラーはおそらく journal にある

デバッグ付きで L2TP ヘルパーを起動し、ターミナルを見ても、画面に役立つものが出ないまま止まります。壊れたデバッグフラグではありません。NetworkManager の L2TP 接続は協調して動く四つのプロセスであり、そのうちの一部だけが、あなたが見ているターミナルに書き込みます。残りの証拠は journal の中にあり、フィルター一つ分の距離にあります。

四つのプロセス、二つのログ出力先

接続は IPsec から始まります。インストールによって libreswan か strongSwan です。次に L2TP デーモン、伝統的には xl2tpd、一部のビルドでは kl2tpd がトンネルを動かします。最後に pppd がその内部で認証とアドレス指定を担当します。

ヘルパーサービスはこれらの部品を調整し、自身の進捗を出力します。IPsec デーモンと pppd は通常システム journal を通じて報告するため、ターミナルには失敗する接続が表示され、理由はあなたが開いていないファイルの中にあります。

この分離は、PSK のエラーとパスワードのエラーがデスクトップから同じに見える理由も説明します。どちらも一般的な切断を生み、失敗した段階は各プロセスの出力にしか現れません。ここで journal が重要になる理由はまさにそれです。デスクトップには一般的なメッセージが一つ、その背後に四つの候補者がいるのです。

一度の試行を集め、それから順序を読む

既知のプロファイルと既知の時刻で一度再現し、起動全体ではなく狭い時間帯を読みます。設定を変えながら試行を繰り返すと、ログは解釈できない混合物になります。

次のコマンドは現在の起動における参加プロセスを選びます。プラグインのパスはディストリビューションで確認する価値があります。

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

一つの呼び出しで繰り返したフィールドはそれらのプロセスの和集合を選び、時系列の順序を保ちます。Debian ベースのシステムでは同等のクエリは dpkg -L です。要点は、手動で実行する前にヘルパーが実際どこにあるかを見つけることです。

次の一手を決める三つの条件

最初に失敗した段階を読み、それに応じて選びます。IPsec が提案やピア認証の失敗を報告するなら、トンネルは一度も形成されておらず、PPP パスワードを変えても助けになりません。

トンネルが形成され、pppd がログインを拒否したなら、共有秘密はすでに正しく、資格情報の問題は一段上にあります。pppd がアドレスを交渉し、失敗が後から現れるなら、どちらも機能しており、残る問題はルーティング、DNS、サーバー自身のポリシーです。

この三つの分岐はほぼすべての一般的な切断を覆い、どれが最も警告的に見えるエラーかではなく、どのプロセスが最後のエラーを記録したかで決まります。

デバッグ設定に触れる前に、どの IPsec バックエンドがインストールされているかを確認する価値もあります。strongSwan 向けに書かれたログオプションは libreswan が動いているときには何もせず、誰も読まないファイルを編集している間、接続は同じ場所で失敗し続けます。

デバッグモードはファイルを残す

元のデバッグ手順はデバッグフラグ付きでサービスを手動実行し、そのモードは接続が終わると生成された実行時設定ファイルをそのまま残すことがあります。

これらのファイルには認証情報が含まれます。事前共有鍵、資格情報、あるいはその両方です。生成された設定をチャットウィンドウにコピーすることはログの抜粋ではなく、資格情報の漏えいです。共有する前に秘密の行を削除し、調査が終わったらディレクトリを削除してください。秘密として扱い、レポートに必要な特定の行だけを抜き出し、ディレクトリをチケットに貼り付けるのではなく、その後で削除してください。

手動のインスタンスは通常のものと調整する必要もあります。サービスがすでにプラグインを所有しているのにデバッグ用コピーを起動すると、所有者が二人になり、両方を混ぜたログができ、デバッグ出力がまったくないより悪くなります。

その後で通常のヘルパーを復元する

調査が終わったら手動インスタンスを停止し、保持された実行時ファイルを削除し、通常の経路で再接続して、次の人が現実に合った設定を見られるようにします。

次に、失敗した層で結果を検証します。デスクトップのアイコンではなく。

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

認証を通り、アドレスを受け取り、意図した宛先へルーティングされるセッションが、あなたがデバッグしていた結果です。失敗した試行中の静かなターミナルは、出力が書かれなかった場所。