LinuxでIPsecなしのL2TP：xl2tpd、pppd、NAT

素のL2TPは封筒に入ったPPPにすぎず、それ以外の何ものでもありません。フレームを運ぶだけで、暗号化もせず、相手が誰かの証明もしないため、ほとんどの導入では下にIPsecを敷きます。それでも裸の構成を選ぶ正直な理由は残っています：実験用のベンチ、移行の途中、あるいはすでに別の保護された経路の内側にある回線です。

それでも進めるなら、その注意書きを設計メモに残してください。以下はDebian系とRHEL系のホストで私が使う運用手順です：どのファイルが何を受け持つか、古典的な停止を防ぐMTU、そしてトンネルを意味あるものにする転送規則です。

三つのファイルが仕事を分ける

xl2tpdは制御接続を終端し、各セッションをPPPデーモンに渡すため、設定は互いのファイルを決して読まない二つのプログラムに分かれます。リスナーは/etc/xl2tpd/xl2tpd.confにあり、[lns default]セクションの中でアドレスプールをip range、サーバー側をlocal ip、PPPへの受け渡しをpppoptfileで指定します。require authentication = yesを有効にし、length bitとflow bitは有効のままにし、ホスト上の他の何も使っていないプールを選びます。

PPPの方針は、そのオプションが指すファイル、通常は/etc/ppp/options.xl2tpdに置きます：auth、pap・chap・mschapの拒否、require-mschap-v2、MTUとMRUの1460、そして回線が上がった後にクライアントが到達できるDNSアドレスです。認証情報はさらに三つ目のファイル、/etc/ppp/chap-secretsにあり、二番目のフィールドはLNSセクション名と一致する必要があり、四番目のフィールドではプールから特定のアドレスを固定できます。

トンネルがつながってから止まる理由

1500バイトのEthernetフレームは、自前のヘッダーにすでにバイトを費やす経路には収まりません。外側のIPv4ヘッダーが20、UDPが8、L2TPヘッダーが約12を占めるので、PPPとそのペイロードに残るのは1460です。この小さい値をPPPで広告することが、大きなパケットが断片化されたり、途中で黙って捨てられたりするのを防ぎます。

症状は、実際の通信が来るまで健全に見えるトンネルです：pingや制御メッセージは通り、ファイルコピーは固まり、ログには何も説明が出ません。両端でMTUとMRUを一緒に下げてください。クライアントだけを調整すると、はっきりした停止が断続的な停止に変わり、診断はかえって難しくなります。

一つのポートが二つの会話を運ぶ

UDP 1701はプロトコルの両半分の下にあり、その一事実が設定の他のどの部分よりも多くのファイアウォール規則を壊します。まず制御接続開始の要求とその応答が来て、続くセッション要求と確認は識別子の組以上は確立しません。その後にPPPが引き継ぎ、リンク制御、認証、そしてアドレスを決めるIP制御プロトコルへと進みます。各段階はログで独自の語彙を持ち、どれもL2TPの障害としては名乗りません。

まさにその順番でキャプチャを読めばどの段階で失敗したかが分かり、PPP認証の失敗はxl2tpdを編集しても直りません。共有ポートはもう一つのよくある失敗を説明します：フローの最初のパケットだけを許可する規則は、セッションを確立させてから転送を遮断します。1701は会話全体について、両方向に許可してください。

トンネルを役立てる：転送とNAT

セッションだけではサーバーに届くだけです。クライアントのインターネット接続には、転送、上流側でのプール用NAT規則、そして回線が上がった後に実際に問い合わせできるDNSが必要です。プールはLANの範囲から外しておく必要もあり、そうでなければクライアント宛ての応答はトンネルに戻されず、ローカルで配信されてしまいます。

サーバーではsysctl -w net.ipv4.ip_forward=1で転送を有効にし、iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADEでプールを変換し、-i ppp0 -o eth0向けのFORWARD規則で外向きのトンネル通信を、ミラー規則と-m state --state RELATED,ESTABLISHEDで戻りの通信を受け入れます。再起動をまたいでこれらの規則を永続化してください：それらなしで戻ってきたサーバーは、壊れたL2TP設定とまったく同じに見えます。

サーバー自身のLANに到達するのは別の作業です：LANルーターにプールへの戻り経路を追加するか、サーバーでproxy ARPを使います。LAN内の何かがクライアントに直接宛てる必要があるのに、クライアントをNATの背後に隠すのは、後日の二度目のデバッグ作業を予約するだけです。

裸のスタックがしないこと、そして確認の方法

このスタックのどの部分もPPPフレームを暗号化せず、実際に選んだサーバーとして遠端を認証するものもありません。MS-CHAPv2は見ているだけの傍受者から認証情報の交換を守りますが、経路上に置かれた攻撃者は依然としてセッションに干渉できます。WindowsのネイティブクライアントはIPsecと組み合わせた場合にしかL2TPを提供しないので、Linux、ルーターファームウェア、サードパーティクライアントを相手として見込んでください。裸の設定は診断の足場として扱い、決して止まる場所にしないでください。

決まった順序で確認します：xl2tpd -Dを前景で実行し、PPP段階についてジャーナルを監視し、両端でip addrから割り当てアドレスを読み、最後にUDP 1701をキャプチャしてセッション確立後にデータが流れることを確かめます。四つすべてが一致しても通信が失敗するなら、原因はルーティング、NAT、MTUであり、L2TP自体ではありません。