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 инкапсулација го решава проблемот со преведување за текови што постојат; таа не создава влезна патека каде што операторот не нуди таква.

Затоа споредете мрежи наместо да погодувате. Однесете го истиот уред и профил во друга дозволена мрежа и видете која фаза таму откажува. Ако работи на друго место, разликата е во патеката, и тоа го стеснува пребарувањето на трите фази погоре наместо на целата конфигурација.