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

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