L2TP/IPsec через NAT: що насправді ламається і чому

Твердження, що NAT ламає L2TP/IPsec, наполовину правильне, а тому марне. Трансляція адрес — це нормально, NAT traversal існує саме для того, щоб її пережити, і мільйони клієнтів щодня підключаються з-за маршрутизатора. Ламається конкретний етап конкретного обміну: IKE не отримує відповіді, інкапсульований тунель відкидається політикою, що дозволяє лише один протокол, або зіставлення трансляції спливає, поки тунель простоює. Коли ви знаєте, на якому етапі перебуваєте, виправлення зазвичай зводиться до одного правила або keepalive, а не до нової схеми VPN.

Міф — це неправильне питання

Корисне питання не «чи ламає це NAT», а «яка частина обміну транслюється і що робить із нею пристрій, який виконує трансляцію». L2TP/IPsec — багаторівневий протокол: IKE веде переговори, ESP захищає, а L2TP несе PPP усередині цього захисту. Трансляція адрес по-різному впливає на кожен рівень, і ознаки збою можна розрізнити, якщо дивитися на етап переговорів, а не на вікно помилки.

Маршрутизатор, який успішно працює в мережі, доводить лише те, що TCP із трансляцією порту джерела працює. Він нічого не каже про UDP 500, UDP 4500 або протокол 50, а саме від цих трьох речей залежить це розгортання.

Етап 1: IKE взагалі має отримати відповідь

Перший обмін іде до сторони, що відповідає, на UDP 500. Якщо відповідь не надходить, усе інше не має значення: попередньо спільний ключ, пропозиція та облікові дані залишаються непрочитаними. Стежте за запитом і відповіддю, а не робіть висновків із тайм-ауту клієнта:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

Запит без відповіді зазвичай означає, що міжмережевий екран або оператор вище відкидає пакет, а не те, що сервер його відхилив. Відповідь із навантаженням сповіщення, де названо пропозицію або проблему із сертифікатом, означає, що пакети дійшли і переговори провалилися через вміст, а це зовсім інше виправлення.

Коли обидві сторони перебувають за трансляцією, ініціатору треба лише дістатися до сторони, що відповідає, тому більшість розгортань на боці клієнта працюють з етапу 1. Хостинг на боці сервера — це місце, де починається проблема вхідного трафіку, і саме тому ці дві ситуації ніколи не слід обговорювати як одну.

Етап 2: інкапсуляція змінює те, що бачить міжмережевий екран

ESP — це IP-протокол, а не порт TCP чи UDP, і звичайна трансляція адрес портів не має поля порту, яке можна переписати. Тому NAT traversal переносить захищене навантаження в UDP 4500: інкапсуляція дає пристрою, що транслює, те, що він уміє транслювати. Щойно це станеться, правило міжмережевого екрана, написане лише для UDP 500, дозволить переговори й відкине тунель, що дає заплутаний результат: журнал показує успішну фазу 1 і жодного трафіку.

Сам обмін IKE також може перейти на UDP 4500 після виявлення NAT, що дивує тих, хто дозволив 500 і нічого більше. Дозвольте обидва порти в обох напрямках на шляху й пам'ятайте, що міжмережевий екран зі станом утримує потік лише доки бачить трафік.

Протокол 50 досі важливий на шляхах без трансляції та на шляхах, де проміжний пристрій налаштований його дозволяти. Якщо ви діагностуєте виключенням, вимкніть гіпотезу, а не додавайте правила гуртом: дозвольте 500, 4500 і ESP, переконайтеся, що тунель піднімається, а потім приберіть те, що виявилося зайвим. Правило, яке ніхто не може пояснити, — це правило, яке ніхто не прибере, коли воно стане причиною наступного збою. Запишіть звуження в журнал змін разом з етапом, який воно виправило, щоб наступний інженер почав з ваших доказів, а не з того самого емпіричного правила.

Етап 3: зіставлення спливає, і тунель помирає

Пристрій, що транслює, зберігає стан для потоків, які пересилає, і цей стан має строк життя. Тунель L2TP/IPsec передає мало трафіку, коли ним ніхто не користується, тому простоюючий тунель може пережити своє зіставлення й перестати отримувати зворотний трафік. Клієнт залишається впевненим, що підключений, сервер нічого не бачить, і перший симптом зазвичай — тайм-аут застосунку, а не помилка VPN.

Виявлення мертвого партнера та keepalive NAT існують саме для цього, і обидві сторони мають бути готові їх надсилати. Якщо ваш сервер за трансляцією, вимога на боці Windows — це задокументоване налаштування реєстру, яке змушує сервер припускати інкапсуляцію UDP для власних вихідних пакетів; без нього сторона, що відповідає, надсилає ESP, який пристрій трансляції не може зіставити назад. Це питання налаштування сервера, а не клієнта.

Зміна адреси WAN дає той самий результат з іншого боку: зіставлення перебудовується навколо нової адреси, і старий зв'язок безпеки тепер указує на кортеж, якого більше немає. Поведінка перепідключення належить реалізації клієнта, і саме тому «перепідключитися після перезавантаження маршрутизатора» працює на одному клієнті, а на іншому потрібен ручний перемикач.

Хостинг за NAT оператора — це інша проблема

Якщо ви хочете розмістити сервер L2TP/IPsec удома й дістатися до нього ззовні, потрібна незапитана вхідна досяжність, і це не те, що дає NAT traversal. NAT оператора перед вашим маршрутизатором означає, що немає порту, який можна переспрямувати й стати досяжним, бо публічна адреса спільна, а зіставлення лише вихідне.

Жодна позначка IPsec pass-through цього не змінює, і жодне налаштування клієнта це не компенсує. Підтримувані відповіді — це справді досяжна адреса, розміщена кінцева точка або архітектура, у якій кожен учасник встановлює вихідне з'єднання. Специфікація інкапсуляції UDP вирішує проблему трансляції для наявних потоків; вона не створює вхідного шляху там, де оператор його не пропонує.

Тож порівнюйте мережі, а не гадайте. Візьміть той самий пристрій і профіль в іншу дозволену мережу й подивіться, який етап там збивається. Якщо це працює в іншому місці, різниця в шляху, і це звужує пошук до трьох етапів вище, а не всієї конфігурації.