L2TP/IPsec í gegnum NAT: hvað raunverulega brotnar og hvers vegna

Fullyrðingin um að NAT brjóti L2TP/IPsec er hálfsönn og þess vegna gagnslaus. Vistfangsþýðing er eðlileg, NAT-traversal er til einmitt til að lifa hana af, og milljónir biðlara tengjast á hverjum degi bak við beini. Það sem brotnar er tiltekið stig tiltekinnar skiptingar: IKE fær aldrei svar, hjúpaða göngin eru hent af stefnu sem leyfir aðeins eitt samskiptareglur, eða þýðingarvörpunin rennur út á meðan göngin eru aðgerðarlaus. Þegar þú veist á hvaða stigi þú ert er lagfæringin venjulega ein regla eða keepalive, ekki ný VPN-hönnun.

Goðsögnin er ranga spurningin

Gagnlega spurningin er ekki „brýtur NAT þetta“ heldur „hvaða hluti skiptingarinnar er þýddur, og hvað gerir tækið sem þýðir við honum“. L2TP/IPsec er lagskipt samskiptareglur: IKE semur, ESP verndar, og L2TP ber PPP innan þeirrar verndar. Vistfangsþýðing hefur áhrif á hvert lag á annan hátt, og hægt er að greina bilanatáknin ef litið er á samningastigið í stað villugluggans.

Beini sem vafrar á vefnum með góðum árangri sannar aðeins að TCP með þýðingu upprunahafnar virki. Hann segir ekkert um UDP 500, UDP 4500 eða samskiptareglur 50, og það eru einmitt þessir þrír hlutir sem þessi uppsetning byggir á.

Stig 1: IKE verður að fá svar yfirleitt

Fyrsta skiptingin fer til svarandans á UDP 500. Ef ekkert svar kemur til baka skiptir ekkert annað máli: fordeildi lykillinn, tillagan og skilríkin verða ólesin. Fylgstu með beiðninni og svarinu í stað þess að álykta út frá tímatakmörkum biðlarans:

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

Beiðni án svars þýðir venjulega að eldveggur eða símafyrirtækið ofar á leiðinni hendi pakkanum, ekki að þjónninn hafi hafnað honum. Svar með tilkynningargreiðslu sem nefnir tillögu eða vandamál með skírteini þýðir að pakkarnir komu og samningaviðræðurnar mistókust vegna innihalds, sem er allt önnur lagfæring.

Þegar báðir aðilar eru bak við þýðingu þarf sá sem byrjar aðeins að ná til svarandans, svo flestar uppsetningar á biðlarahlið virka frá stigi 1. Hýsing á þjónahlið er þar sem vandamálið með innkomandi umferð byrjar, og þess vegna ætti aldrei að ræða þær tvær aðstæður sem eina.

Stig 2: hjúpun breytir því sem eldveggurinn sér

ESP er IP-samskiptareglur, ekki TCP- eða UDP-höfn, og venjuleg hafnarvistfangsþýðing hefur ekkert hafnarsvið til að endurskrifa. Þess vegna færir NAT-traversal verndaða greiðsluna inn í UDP 4500: hjúpunin gefur þýðingartækinu eitthvað sem það veit hvernig á að þýða. Þegar það gerist mun eldveggsregla sem er skrifuð aðeins fyrir UDP 500 leyfa samningaviðræðurnar og henda göngunum, sem gefur ruglandi niðurstöðu þar sem annállinn sýnir árangursríkt stig 1 og enga umferð.

IKE-skiptingin sjálf getur líka færst yfir á UDP 4500 eftir að NAT hefur greinst, sem kemur þeim á óvart sem leyfðu 500 og ekkert annað. Leyfðu báðar hafnir í báðar áttir á leiðinni, og mundu að ástandsbundinn eldveggur heldur flæðinu aðeins á meðan hann sér umferð.

Samskiptareglur 50 skipta enn máli á leiðum án þýðingar, og á leiðum þar sem millibox er stillt til að leyfa þær. Ef þú greinir með útilokun skaltu slökkva á tilgátunni í stað þess að bæta reglum við í bunkum: leyfðu 500, 4500 og ESP, staðfestu að göngin rísi, fjarlægðu svo það sem reyndist óþarft. Regla sem enginn getur útskýrt er regla sem enginn mun fjarlægja þegar hún verður orsök næstu truflunar. Skrifaðu þrenginguna í breytingaskrána ásamt stiginu sem hún lagaði, svo næsti verkfræðingur byrji á sönnunargögnum þínum í stað sömu þumalputtareglunnar.

Stig 3: vörpunin rennur út og göngin deyja

Þýðingartæki heldur stöðu fyrir flæðin sem það sendir áfram, og sú staða hefur líftíma. L2TP/IPsec-göng bera litla umferð þegar enginn notar þau, svo aðgerðarlaus göng geta lifað vörpun sína af og hætt að taka við afturumferð. Biðlarinn er áfram sannfærður um að hann sé tengdur, þjónninn sér ekkert, og fyrsta einkennið er venjulega tímatakmörk forrits en ekki VPN-villa.

Greining dauðs jafnings og NAT-keepalive eru til fyrir þetta, og báðir endar verða að vera reiðubúnir að senda þau. Ef þjónninn þinn er bak við þýðingu er krafan á Windows-hlið að skjalfest stilling í skrá sem lætur þjóninn gera ráð fyrir UDP-hjúpun fyrir eigin útfararpakka; án hennar sendir svarandinn ESP sem þýðingartækið getur ekki varpað til baka. Þetta er stilling þjónsins, ekki biðlarans.

Breyting á WAN-vistfangi gefur sömu niðurstöðu úr annarri átt: vörpunin er endurbyggð í kringum nýtt vistfang, og gamla öryggistengingin bendir nú á tvíeyki sem er ekki lengur til. Endurtengingarhegðun tilheyrir útfærslu biðlarans, og þess vegna virkar „tengdu aftur eftir endurræsingu beinisins“ á einum biðlara og krefst handvirkrar rofa á öðrum.

Hýsing bak við NAT símafyrirtækis er annað vandamál

Ef þú vilt hýsa L2TP/IPsec-þjón heima og ná í hann að utan er krafan óumbeðin innkomandi aðgengi, og það er ekki það sem NAT-traversal býður. NAT símafyrirtækis fyrir framan beininn þýðir að engin höfn er sem þú getur framsent og gert þig aðgengilegan, því almenna vistfangið er deilt og vörpunin er aðeins útfarandi.

Enginn IPsec pass-through-reitur breytir því, og engin biðlarastilling vegur það upp. Studdu svörin eru vistfang sem er raunverulega aðgengilegt, hýst endapunktur, eða arkitektúr þar sem hver þátttakandi gerir útfarandi tengingu. UDP-hjúpunarskráin leysir þýðingarvandamálið fyrir flæði sem eru til; hún býr ekki til innkomna leið þar sem símafyrirtækið býður enga.

Berðu því saman net í stað þess að giska. Farðu með sama tæki og snið á annað leyft net og sjáðu hvaða stig mistekst þar. Ef það virkar annars staðar er munurinn á leiðinni, og það þrengir leitina að þremur stigunum hér að ofan í stað allrar stillingarinnar.