L2TP/IPsec caur NAT: kas patiešām lūzt un kāpēc

Apgalvojums, ka NAT salauž L2TP/IPsec, ir puslīdz patiess un tāpēc bezjēdzīgs. Adrešu tulkošana ir normāla, NAT traversal pastāv tieši tāpēc, lai to pārdzīvotu, un miljoniem klientu katru dienu pieslēdzas aiz maršrutētāja. Lūzt konkrēts konkrētas apmaiņas posms: IKE nekad nesaņem atbildi, iekapsulētais tunelis tiek izmests ar politiku, kas atļauj tikai vienu protokolu, vai tulkošanas kartējums beidzas, kamēr tunelis ir dīkstāvē. Kad zināt, kurā posmā esat, labojums parasti ir viens noteikums vai keepalive, nevis jauns VPN dizains.

Mīts ir nepareizais jautājums

Noderīgais jautājums nav „vai NAT to salauž“, bet „kura apmaiņas daļa tiek tulkota un ko ar to dara tulkojošā ierīce“. L2TP/IPsec ir slāņains protokols: IKE pārrunā, ESP aizsargā, un L2TP pārvadā PPP šīs aizsardzības iekšienē. Adrešu tulkošana katru slāni ietekmē citādi, un kļūmes pazīmes var atšķirt, ja skatāties uz pārrunu posmu, nevis kļūdas dialogu.

Maršrutētājs, kas veiksmīgi pārlūko tīmekli, pierāda tikai to, ka TCP ar avota porta tulkošanu darbojas. Tas neko nepasaka par UDP 500, UDP 4500 vai 50. protokolu, un tieši no šiem trim lietām ir atkarīga šī ieviešana.

1. posms: IKE vispār ir jāsaņem atbilde

Pirmā apmaiņa dodas pie atbildētāja UDP 500. Ja atbilde neatgriežas, viss pārējais nav svarīgs: iepriekš koplietotā atslēga, priekšlikums un akreditācijas dati paliek neizlasīti. Vērojiet pieprasījumu un atbildi, nevis seciniet no klienta taimauta:

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

Pieprasījums bez atbildes parasti nozīmē, ka ugunsmūris vai pakalpojumu sniedzējs augstāk izmet paketi, nevis to, ka serveris to noraidīja. Atbilde ar paziņojuma kravu, kas nosauc priekšlikumu vai sertifikāta problēmu, nozīmē, ka paketes ieradās un pārrunas neizdevās satura dēļ, kas ir pavisam cits labojums.

Kad abas puses atrodas aiz tulkošanas, iniciatoram tikai jāsasniedz atbildētājs, tāpēc lielākā daļa klienta puses ieviešanu darbojas no 1. posma. Servera puses hostings ir vieta, kur sākas ienākošā problēma, un tāpēc šīs divas situācijas nekad nevajadzētu apspriest kā vienu.

2. posms: iekapsulēšana maina to, ko redz ugunsmūris

ESP ir IP protokols, nevis TCP vai UDP ports, un parastajai portu adrešu tulkošanai nav porta lauka, ko pārrakstīt. Tāpēc NAT traversal pārvieto aizsargāto kravu UDP 4500: iekapsulēšana dod tulkojošajai ierīcei kaut ko tādu, ko tā prot tulkot. Kad tas notiek, ugunsmūra noteikums, kas rakstīts tikai UDP 500, atļaus pārrunas un izmetīs tuneli, kas rada mulsinošo rezultātu, kur žurnālā redzams veiksmīgs 1. posms un nekāda plūsma.

Pati IKE apmaiņa arī var pārcelties uz UDP 4500 pēc NAT noteikšanas, kas pārsteidz tos, kuri atļāva 500 un neko citu. Atļaujiet abus portus abos virzienos ceļā, un atcerieties, ka stāvokļa ugunsmūris plūsmu notur tikai tik ilgi, kamēr redz plūsmu.

50. protokols joprojām ir svarīgs ceļos bez tulkošanas un ceļos, kur starpierīce ir konfigurēta to atļaut. Ja diagnosticējat ar izslēgšanu, izslēdziet hipotēzi, nevis pievienojiet noteikumus kaudzēm: atļaujiet 500, 4500 un ESP, pārliecinieties, ka tunelis paceļas, pēc tam noņemiet to, kas izrādījās lieks. Noteikums, ko neviens nevar izskaidrot, ir noteikums, ko neviens nenoņems, kad tas kļūs par nākamā pārtraukuma cēloni. Ierakstiet sašaurinājumu izmaiņu žurnālā kopā ar posmu, ko tas laboja, lai nākamais inženieris sāktu no jūsu pierādījumiem, nevis no tā paša īkšķa noteikuma.

3. posms: kartējums beidzas un tunelis mirst

Tulkojošā ierīce glabā stāvokli pārsūtītajām plūsmām, un šim stāvoklim ir dzīves ilgums. L2TP/IPsec tunelis pārvadā maz plūsmas, kad neviens to neizmanto, tāpēc dīkstāvē esošs tunelis var pārdzīvot savu kartējumu un pārstāt saņemt atgriešanās plūsmu. Klients paliek pārliecināts, ka ir savienots, serveris neko neredz, un pirmais simptoms parasti ir lietojumprogrammas taimauts, nevis VPN kļūda.

Mirušā partnera noteikšana un NAT keepalive pastāv tieši tam, un abiem galiem jābūt gataviem tos sūtīt. Ja jūsu serveris atrodas aiz tulkošanas, Windows puses prasība ir dokumentēts reģistra iestatījums, kas liek serverim pieņemt UDP iekapsulēšanu savām izejošajām paketēm; bez tā atbildētājs sūta ESP, ko tulkojošā ierīce nevar kartēt atpakaļ. Tas ir servera konfigurācijas jautājums, nevis klienta.

WAN adreses maiņa dod tādu pašu iznākumu no citas puses: kartējums tiek pārbūvēts ap jaunu adresi, un vecā drošības asociācija tagad norāda uz kortežu, kas vairs neeksistē. Atkārtotas savienošanas uzvedība pieder klienta ieviešanai, tāpēc „pieslēdzies atkārtoti pēc maršrutētāja pārstartēšanas“ darbojas vienam klientam, bet citam nepieciešams manuāls slēdzis.

Hostings aiz operatora līmeņa NAT ir cita problēma

Ja vēlaties mājās mitināt L2TP/IPsec serveri un sasniegt to no ārpuses, prasība ir nepieprasīta ienākošā sasniedzamība, un to NAT traversal nenodrošina. Operatora līmeņa NAT jūsu maršrutētāja priekšā nozīmē, ka nav porta, ko varētu pārsūtīt un kļūt sasniedzamam, jo publiskā adrese tiek koplietota un kartējums ir tikai izejošs.

Neviena IPsec pass-through atzīmēšanas rūtiņa to nemaina, un neviena klienta konfigurācija to nekompensē. Atbalstītās atbildes ir patiešām sasniedzama adrese, mitināts galapunkts vai arhitektūra, kurā katrs dalībnieks izveido izejošu savienojumu. UDP iekapsulēšanas specifikācija atrisina tulkošanas problēmu esošajām plūsmām; tā neveido ienākošu ceļu tur, kur operators to nepiedāvā.

Tāpēc salīdziniet tīklus, nevis miniet. Aiznesiet to pašu ierīci un profilu uz citu atļautu tīklu un paskatieties, kurš posms tur neizdodas. Ja citur darbojas, atšķirība ir ceļā, un tas sašaurina meklēšanu līdz trim iepriekš minētajiem posmiem, nevis visai konfigurācijai.