L2TP/IPsec が IPsec に加えて UDP 1701 を必要とする理由

IKE と ESP は許可するのに UDP 1701 を許可しないファイアウォールは、認証情報の問題のように見える形で L2TP 接続を壊します。理由は、L2TP が一つ目の内側を走る二つ目のプロトコルだからです。IPsec が交換を運び、認証し、L2TP は UDP 1701 の上で独自のトンネルを走らせますが、これをローカルのスタックが依然として配送しなければなりません。各ヘッダーがどこに現れるかを知れば、どの機器にどのルールが必要かが分かります。

二つのプロトコル、二つのポート群

L2TP/IPsec 接続は UDP 500 で IKE を、変換がある場所では UDP 4500 で NAT トラバーサルを、変換がない場所では IP プロトコル 50 として ESP を使います。L2TP 自体は UDP 1701 上のトンネルプロトコルであり、IPsec が相手を認証した後に動作します。二つの半分は異なる形で失敗し、それを報告するログ行は別々のコンポーネントから出ます。前半だけを覆うルールセットでは、ネゴシエーションまでは進んでトンネル段階で死ぬ接続になります。

ポート番号はトランスポートの端点を表し、ESP はポートではありません。だからこそ TCP と UDP のルールしか提供しないファイアウォール画面では、完全な IPsec ポリシーを表現できません。プロトコル 50 はプロトコルとして許可する必要があり、UDP だけに言及したルールがそれに一致することは決してありません。

包みがポートを説明する

回線上では、L2TP/IPsec 接続は通常 500 の IKE と 4500 のカプセル化された ESP を示します。UDP 1701 ヘッダーは保護されたペイロードの内側にあるため、外側インターフェースでのキャプチャには現れません。ローカルホストはそのデータグラムを L2TP デーモンに依然として配送する必要があり、配送はカプセル解除後に行われます。したがって 1701 のルールは、中間装置がそのポートを一度も見ないとしても、端点自身のファイアウォールに属します。

処理順序が混乱の大部分を説明します。スタックがホストフィルターより先に IPsec ポリシーを適用すれば、カプセル解除された L2TP パケットは UDP 1701 として照合され、逆に順序が入れ替わっていればルールセットが見るのは外側のポートです。どちらの挙動も実際に存在するため、同じルールセットがあるプラットフォームでは動き、別のプラットフォームでは失敗するように見えます。

順を追って経路を確認する

まず外側インターフェースでキャプチャし、IKE とカプセル化された ESP が両方向に流れていることを確認します。次に、カプセル解除されたトラフィックについてローカルファイアウォールのカウンターを確認します。順序が重要なのは、何も映らないキャプチャは問題がホストより上流にあることを意味するからです。

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

キャプチャは交換の前半を確認し、相手が応答しているかどうかを示します。ルール一覧は 1701 のルールが存在するか、そして破棄ポリシーに対してどこに位置するかを示します。ソケット一覧は L2TP デーモンがバインドされて待ち受けていることを確認し、起動しなかったサービスを除外します。待ち受けがない場合とフィルターされたポートは利用者に同じ苦情をもたらすため、ルールを変える前に三つとも読んでください。

ポートスキャンが示せないもの

正しく構成されたサーバーに対する UDP 1701 の外部スキャンは通常何も報告せず、それが想定された結果です。このポートはインターネットに公開されておらず、IPsec が相手を認証した後にだけ到達できます。閉じた結果を障害として扱うと、閉じたままにすべきポートを開くことになります。スキャンは、アプリケーションのトラフィックを見られないのと同じくらい、トンネルの内側を見られません。

代わりに実際のクライアントで試し、どこまで進むかを読んでください。接続がネゴシエーションしてから止まるなら容疑者は L2TP デーモンかローカルフィルターであり、まったくネゴシエーションしないなら外側のポートが原因です。この一つの切り分けが、どのルールを追加すべきかという推測の大半を取り除き、プロトコルの階層化がそれを神秘ではなく予測可能にします。