Чому L2TP/IPsec потребує UDP 1701 окрім IPsec

Міжмережеві екрани, які дозволяють IKE і ESP, але не UDP 1701, ламають з'єднання L2TP так, що це виглядає як проблема з обліковими даними. Причина в тому, що L2TP — другий протокол, який рухається всередині першого. IPsec переносить і перевіряє обмін, а L2TP веде власний тунель поверх UDP 1701, який локальний стек усе одно має доставити. Знання того, де з'являється кожен заголовок, пояснює, якому пристрою потрібне яке правило.

Два протоколи, два набори портів

З'єднання L2TP/IPsec використовує IKE на UDP 500, проходження NAT на UDP 4500 там, де є трансляція, і ESP як IP-протокол 50 там, де її немає. Сам L2TP — тунельний протокол на UDP 1701, і він працює після того, як IPsec автентифікував партнера. Дві половини відмовляють по-різному, і рядки журналу, що повідомляють про них, надходять із різних компонентів. Набір правил, який охоплює лише першу половину, дає з'єднання, що домовляється, а потім помирає на етапі тунелю.

Номери портів описують транспортні кінцеві точки, а ESP взагалі не порт. Тому інтерфейс міжмережевого екрана, що пропонує лише правила TCP і UDP, не може виразити повну політику IPsec. Протокол 50 має бути дозволений як протокол, і правило, яке згадує лише UDP, ніколи з ним не збіжиться.

Обгортка пояснює порт

У мережі з'єднання L2TP/IPsec зазвичай показує IKE на 500 та інкапсульований ESP на 4500. Заголовок 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 або локальний фільтр; якщо воно взагалі не домовляється, винні зовнішні порти. Цей єдиний поділ знімає більшість здогадів про те, яке правило додати, а розшарування протоколів робить це передбачуваним, а не загадковим.