L2TP/IPsec përmes NAT: çfarë thyhet vërtet dhe pse

Pohimi se NAT thyen L2TP/IPsec është gjysmë i vërtetë dhe për këtë arsye është i padobishëm. Përkthimi i adresave është normal, traversal NAT ekziston pikërisht për t’i mbijetuar atij, dhe miliona klientë lidhen çdo ditë pas një ruteri. Ajo që thyhet është një fazë e caktuar e një shkëmbimi të caktuar: IKE nuk merr kurrë përgjigje, tuneli i inkapsuluar hidhet nga një politikë që lejon vetëm një protokoll, ose mapimi i përkthimit skadon ndërsa tuneli është joaktiv. Pasi të dini në cilën fazë jeni, rregullimi zakonisht është një rregull i vetëm ose një keepalive, jo një dizajn i ri VPN.

Miti është pyetja e gabuar

Pyetja e dobishme nuk është «a e thyen NAT këtë», por «cila pjesë e shkëmbimit përkthehet, dhe çfarë bën pajisja që përkthen me të». L2TP/IPsec është një protokoll me shtresa: IKE negocion, ESP mbron, dhe L2TP transporton PPP brenda asaj mbrojtjeje. Përkthimi i adresave ndikon ndryshe në secilën shtresë, dhe nënshkrimet e dështimit dallohen nëse shikoni fazën e negociatave dhe jo dialogun e gabimit.

Një ruter që shfleton web-in me sukses provon vetëm se TCP me përkthim të portës burimore funksionon. Nuk thotë asgjë për UDP 500, UDP 4500 ose protokollin 50, dhe pikërisht këto tre gjëra janë ato nga të cilat varet kjo vendosje.

Faza 1: IKE duhet të marrë patjetër një përgjigje

Shkëmbimi i parë shkon te përgjigjësi në UDP 500. Nëse nuk kthehet asnjë përgjigje, asgjë tjetër nuk ka rëndësi: çelësi i përbashkët paraprak, propozimi dhe kredencialet mbeten të palexuara. Vëreni kërkesën dhe përgjigjen në vend që të nxirrni përfundime nga afati i klientit:

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

Një kërkesë pa përgjigje zakonisht do të thotë se një mur i zjarrit ose operatori më lartë po e hedh paketën, jo se serveri e refuzoi atë. Një përgjigje me ngarkesë njoftimi që përmend një propozim ose një problem certifikate do të thotë se paketat mbërritën dhe negociatat dështuan për shkak të përmbajtjes, gjë që është një rregullim krejt tjetër.

Kur të dyja palët janë pas përkthimit, iniciatori duhet vetëm të arrijë përgjigjësin, kështu që shumica e vendosjeve në anën e klientit funksionojnë nga faza 1. Hosting-u në anën e serverit është vendi ku fillon problemi i hyrjes, dhe për këtë arsye këto dy situata nuk duhet të diskutohen kurrë si një.

Faza 2: inkapsulimi ndryshon atë që sheh muri i zjarrit

ESP është një protokoll IP, jo një port TCP ose UDP, dhe përkthimi i zakonshëm i adresave të portave nuk ka fushë porte për të rishkruar. Prandaj traversal NAT e zhvendos ngarkesën e mbrojtur brenda UDP 4500: inkapsulimi i jep pajisjes përkthyese diçka që ajo di ta përkthejë. Pasi kjo ndodh, një rregull muri zjarri i shkruar vetëm për UDP 500 do të lejojë negociatat dhe do të hedhë tunelin, gjë që prodhon rezultatin konfuz ku regjistri tregon një fazë 1 të suksesshme dhe asnjë trafik.

Vetë shkëmbimi IKE mund të kalojë gjithashtu në UDP 4500 pasi të zbulohet një NAT, gjë që i befason ata që kanë lejuar 500 dhe asgjë tjetër. Lejoni të dy portat në të dy drejtimet në rrugë, dhe mbani mend se një mur zjarri me gjendje e mban rrjedhën vetëm sa kohë sheh trafik.

Protokolli 50 vazhdon të ketë rëndësi në rrugë pa përkthim, dhe në rrugë ku një kuti e ndërmjetme është konfiguruar ta lejojë. Nëse diagnozoni me eliminim, fikni hipotezën në vend që të shtoni rregulla me grumbull: lejoni 500, 4500 dhe ESP, konfirmoni se tuneli ngrihet, pastaj hiqni atë që doli e panevojshme. Një rregull që askush nuk mund ta shpjegojë është një rregull që askush nuk do ta heqë kur të bëhet shkaku i ndërprerjes tjetër. Shkruani ngushtimin në regjistrin e ndryshimeve bashkë me fazën që rregulloi, që inxhinieri i radhës të nisë nga provat tuaja dhe jo nga i njëjti rregull empirik.

Faza 3: mapimi skadon dhe tuneli vdes

Një pajisje përkthyese mban gjendje për rrjedhat që përcjell, dhe ajo gjendje ka jetëgjatësi. Një tunel L2TP/IPsec transporton pak trafik kur askush nuk e përdor, kështu që një tunel joaktiv mund t’i mbijetojë mapimit të tij dhe të ndalojë marrjen e trafikut të kthimit. Klienti mbetet i bindur se është i lidhur, serveri nuk sheh asgjë, dhe simptomi i parë zakonisht është një afat kohor aplikacioni dhe jo një gabim VPN.

Zbulimi i palës së vdekur dhe keepalive-t NAT ekzistojnë pikërisht për këtë, dhe të dy skajet duhet të jenë të gatshme t’i dërgojnë ato. Nëse serveri juaj është pas përkthimit, kërkesa në anën e Windows është një rregullim i dokumentuar i regjistrit që e bën serverin të supozojë inkapsulim UDP për paketat e tij dalëse; pa të, përgjigjësi dërgon ESP që pajisja përkthyese nuk mund ta mapojë mbrapsht. Kjo është çështje konfigurimi i serverit, jo i klientit.

Një ndryshim i adresës WAN jep të njëjtin rezultat nga një drejtim tjetër: mapimi rindërtohet rreth një adrese të re, dhe shoqata e vjetër e sigurisë tani tregon një kortezh që nuk ekziston më. Sjellja e rilidhjes i përket implementimit të klientit, dhe për këtë arsye «rilidhu pas rindezjes së ruterit» funksionon në një klient dhe në një tjetër kërkon një çelës manual.

Hosting-u pas NAT të operatorit është një problem tjetër

Nëse dëshironi të hostoni një server L2TP/IPsec në shtëpi dhe ta arrini nga jashtë, kërkesa është arritshmëri hyrëse e papërshkruar, dhe kjo nuk është ajo që ofron traversal NAT. Një NAT i operatorit përpara ruterit tuaj do të thotë se nuk ka port që mund të përcillni dhe që ju bën të arritshëm, sepse adresa publike ndahet dhe mapimi është vetëm dalës.

Asnjë kuti IPsec pass-through nuk e ndryshon këtë, dhe asnjë konfigurim klienti nuk e kompenson. Përgjigjet e mbështetura janë një adresë vërtet e arritshme, një pikë fundore e hostuar, ose një arkitekturë ku secili pjesëmarrës bën një lidhje dalëse. Specifikimi i inkapsulimit UDP zgjidh problemin e përkthimit për rrjedhat që ekzistojnë; ai nuk krijon një rrugë hyrëse aty ku operatori nuk ofron një.

Prandaj krahasoni rrjetet në vend që të hamendësoni. Çoni të njëjtën pajisje dhe profil në një rrjet tjetër të lejuar dhe shikoni cila fazë dështon atje. Nëse funksionon diku tjetër, ndryshimi është në rrugë, dhe kjo e ngushton kërkimin në tre fazat më sipër në vend të gjithë konfigurimit.