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.

Откриването на мъртъв партньор и NAT keepalive съществуват точно за това и двете страни трябва да са готови да ги изпращат. Ако сървърът ви е зад транслация, изискването от страна на Windows е документирана настройка в регистъра, която кара сървъра да приема UDP инкапсулация за собствените си изходящи пакети; без нея отговарящата страна изпраща ESP, което преобразуващото устройство не може да преобразува обратно. Това е въпрос на конфигурация на сървъра, не на клиента.

Промяната на WAN адреса дава същия резултат от друга посока: преобразуването се изгражда наново около нов адрес и старата асоциация за сигурност вече сочи към кортеж, който не съществува. Поведението при повторно свързване принадлежи на реализацията на клиента и затова „свържи се отново след рестарт на рутера“ работи при един клиент, а при друг иска ръчен превключвател.

Хостинг зад NAT на операторско ниво е различен проблем

Ако искате да хоствате L2TP/IPsec сървър у дома и да го достигате отвън, изискването е непоискана входяща достъпност и това не е, което NAT traversal предоставя. NAT на операторско ниво пред рутера ви означава, че няма порт, който да пренасочите и да ви направи достъпни, защото публичният адрес е споделен и преобразуването е само изходящо.

Никое квадратче за IPsec pass-through не променя това и никаква конфигурация на клиента не го компенсира. Поддържаните отговори са адрес, който наистина е достъпен, хоствана крайна точка или архитектура, в която всеки участник прави изходяща връзка. А спецификацията за UDP инкапсулация решава проблема с транслацията за потоци, които съществуват; тя не създава входящ път там, където операторът не предлага такъв.

Затова сравнявайте мрежи, вместо да гадаете. Занесете същото устройство и профил в друга разрешена мрежа и вижте кой етап се проваля там. Ако работи другаде, разликата е в пътя и това стеснява търсенето до трите етапа по-горе, вместо до цялата конфигурация.