NAT simetrik dhe VPN: matni hartëzimin, jo etiketën

Një fill ndihme përfundon me verdiktin „NAT simetrik, VPN-i nuk do të funksionojë këtu“, dhe pastaj klienti riinstalohet tri herë pa arsye. Etiketa shkakton dëm sepse i përgjigjet një pyetjeje që askush nuk e bëri. Një klient që lidhet nga jashtë me një server fiks krijon një hartëzim në momentin kur dërgon paketën e parë, dhe përgjigjes i lejohet të kthehet sipas rregullave që zbaton pothuajse çdo rrjet. Ajo që hartëzimi i varur nga pika e fundit vërtet e ndërlikon është që dy partnerë të përpiqen të arrijnë njëri-tjetrin në të njëjtën kohë, dhe ky është një test tjetër.

Dy pyetje fshihen pas një etikete

Pyetja e parë është nëse një host pas këtij rrjeti mund të hapë një sesion drejt një adrese publike dhe një porti të njohur. Për një klient tuneli ky është rasti normal, dhe përgjigjja është pothuajse gjithmonë po. Ruteri regjistron burimin e brendshëm, cakton një port të jashtëm dhe e lë përgjigjen të kalojë sepse i përket një sesioni që filloi nga brenda.

Pyetja e dytë është nëse dy hoste pas rrjetesh të ndryshme mund të gjejnë një rrugë të përbashkët dhe t'i dërgojnë njëri-tjetrit pa një server në mes. Kjo varet nga mënyra se si çdo rrjet i cakton ato porte të jashtme, dhe është vendi i vetëm ku sjellja e hartëzimit ka rëndësi.

Përzierja e të dyjave prodhon diagnozën e gabuar klasike: një funksion mes partnerësh dështon, dikush ekzekuton një test të tipit NAT, sheh kategorinë më të keqe dhe përfundon se as tuneli i zakonshëm nuk mund të funksionojë. Tuneli nuk ishte kurrë ajo që dështoi.

Hartëzimi dhe filtrimi janë dy veti të ndara

Terminologjia e RFC është më e saktë se emrat që përdorin furnizuesit, dhe ia vlen të kalohet në tiketë sepse i zgjidh debatet. Hartëzimi është mënyra se si caktohet porti i jashtëm. Filtrimi është cilat paketa hyrëse lejohen të kalojnë. Një rrjet mund të jetë i rreptë në njërën dhe liberal në tjetrën, dhe pikërisht ajo kombinim është ajo që një protokoll mes partnerësh duhet t'i mbijetojë.

Rreshti i tretë është ajo që shumica e ruterëve të konsumatorit dhe operatorëve mobilë nënkuptojnë me simetrik. Vini re se etiketa përshkruan vetëm caktimin. Një rrjet me atë hartëzim dhe filtrim liberal mund të pranojë ende paketa hyrëse drejt portit që sapo caktoi, prandaj shpimi i vrimave funksionon në disa dhe dështon në të tjera.

Filtrimi ka tre rastet e veta dhe emrin e vet për secilin. Të shkruash „NAT simetrik“ në një tiketë kur do të thuash „filtrim i varur nga adresa dhe porti“ e dërgon personin tjetër në kapitullin e gabuar të manualit. Të dyja sillen ndryshe në test, prandaj gabimi nuk është akademik.

Matni hartëzimin në vend që t'i vini emër

Mund ta vëzhgoni portin e caktuar drejtpërdrejt nga ana e serverit të çdo shërbimi UDP që kontrolloni. Nisni një kapje në hostin publik, dërgoni nga klienti dhe lexoni portin burim me të cilin mbërriti paketa:

sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820

Rreshti i pikës së fundit është më i dobishmi nga të tre, sepse WireGuard regjistron adresën dhe portin e fundit që mori nga çdo partner. Krahasoni atë port me atë që klienti mendon se po përdor. Ato do të ndryshojnë sa herë që ndodh ndonjë përkthim, dhe pyetja e rëndësishme është nëse vlera mbetet e qëndrueshme.

Përsëritni vëzhgimin ndaj një porti të dytë destinacioni ose një serveri të dytë dhe krahasoni përsëri. Nëse porti i jashtëm ndryshon sipas destinacionit, hartëzimi varet nga adresa dhe porti. Nëse mbetet i njëjtë, rrjeti ju jep një hartëzim dhe zbulimi ka një shans.

Mjetet e bazuara në STUN raportojnë të njëjtin klasifikim në një hap, dhe mund të përdoren kur rrjeti lejon UDP dalës drejt një serveri publik STUN. Kur nuk e lejon, metoda e kapjes më sipër funksionon ende dhe nuk kërkon asgjë tjetër përveç një hosti që ju tashmë e kontrolloni.

Zgjidhni një rregullim që i përshtatet dështimit

Nëse funksioni që dështon është mes partnerësh, përgjigjet e mbështetura janë një rele, një shërbim takimi që të dy partnerët mund ta arrijnë, ose një topologji tjetër. TURN ekziston pikërisht për këtë, dhe një produkt që sjell relen e vet po ju thotë se pret që disa rrjete të jenë armiqësore.

Nëse funksioni që dështon është një tunel i zakonshëm, sjellja e hartëzimit nuk është problemi juaj dhe asgjë nga sa më sipër nuk zbatohet. Kontrolloni që klienti vërtet dërgon, që serveri e sheh paketën dhe që përgjigjja kthehet. Ai sekuencë janë tre vëzhgime dhe nuk kërkon të dish asgjë për kategorinë NAT të ruterit.

Ajo që nuk funksionon është shpërndarja e ndryshimeve të portit lokal derisa diçka të lidhet. Ndryshimi i portit burim të klientit nuk ndryshon mënyrën se si rrjeti cakton hartëzimet. Një sukses i rastësishëm në përpjekjen e pestë është një pozitiv i rremë, dhe do të citohet si rregullim për muaj me radhë.

Regjistroni arkitekturën, jo verdiktin

Një shënim i dobishëm thotë cili protokoll, në cilin drejtim fillon sesioni, nëse ka një rele në rrugë dhe çfarë u vëzhgua në tel. „NAT simetrik, nuk funksionon“ është i papërdorshëm, sepse është njëkohësisht i gabuar për tunelin dhe joinformativ për rrugën e partnerit.

Përfshini qëndrueshmërinë e matur të portit dhe sjelljen e filtrimit nëse i keni testuar. Këto dy fakte i lejojnë dikujt tjetër të parashikojë nëse një funksion i ri do të funksionojë në atë rrjet pa përsëritur të gjithë hetimin. Ato gjithashtu plaken më mirë se një kategori furnizuesi që në çdo faqe ndihme do të thotë diçka paksa ndryshe.

Së fundi, mbani pranë terminologjinë e RFC 4787 kur e shkruani këtë. Përdorimi i termave të saktë kushton një fjali dhe e pengon lexuesin tjetër të përsërisë të njëjtën diagnozë të gabuar, dhe ky është i gjithë qëllimi i shkrimit të shënimit.