NAT i dyfishtë dhe VPN-i juaj: klienti punon, serveri jo

Ruteri juaj qëndron pas një ruteri tjetër, adresa WAN është private, dhe klienti VPN lidhet gjithsesi. Ky kombinim i befason ata që presin që NAT-i i dyfishtë të thyejë tunelet, por pikërisht lidhjet në dalje janë ato që përkthimi i trajton më mirë. Strehimi i një serveri VPN pas të njëjtave dy shtresa është rasti që zakonisht dështon. Vizatoni drejtimin e lidhjes përpara se të ndryshoni ndonjë gjë.

Fillimisht vizatoni drejtimin e lidhjes

Hapni faqen e statusit të ruterit të brendshëm dhe shkruani adresën e tij WAN, më pas krahasojeni me adresën që ju raporton një shërbim publik. Nëse të dyja ndryshojnë, mes ruterit tuaj dhe internetit qëndron të paktën një përkthyes. Nëse adresa WAN bie brenda 100.64.0.0/10, përkthyesi i jashtëm ndoshta i përket ofruesit tuaj, dhe ju nuk e kontrolloni atë. Këto dy fakte përcaktojnë se cili nga hapat e mëvonshëm mund të funksionojë fare.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

NAT i dyfishtë nuk është VPN i dyfishtë. Përkthimi rishkruan adresat dhe portat; ai nuk shton një tunel të dytë të kriptuar dhe nuk kripton asgjë. Mbajtja e dy ideve të ndara ka rëndësi sepse zgjidhjet janë krejt të ndryshme, dhe njëra prej tyre kërkon një bisedë me ofruesin tuaj në vend të një faqe cilësimesh.

Dalje: klienti pyet, përkthyesit hartëzojnë

Një tunel në dalje fillon me një paketë nga makina juaj, kështu që çdo përkthyes mund të krijojë një hartëzim dhe ta lërë përgjigjen të hyjë përsëri. Protokolli, porta dhe kohëmatësit e papunësisë përcaktojnë nëse ai hartëzim mbijeton mjaft gjatë për të qenë i dobishëm. Shumica e ruterëve të konsumatorit e trajtojnë këtë pa asnjë konfigurim.

Dështimet që shfaqen vërtet zakonisht kanë të bëjnë me afatet kohore dhe mbështetjen e protokolleve, jo me numrin e ruterëve. Një tunel që bie pas disa minutash heshtjeje është një hartëzim që skadon, dhe keepalive është përgjigja standarde. IPsec ka zgjerime standarde NAT-traversal, prandaj pohimi se nuk mund të kalojë përkthimin është thjesht i gabuar. Nëse tuneli nuk vendoset fare, shikoni pikën fundore dhe kredencialet përpara se të fajësoni topologjinë.

wg show
ping -c3 10.8.0.1

Ndaloni nëse tuneli në dalje punon nga një rrjet dhe jo nga një tjetër. Ai krahasim ka të bëjë me rrjetet, jo me numrin e ruterëve.

Hyrje: përcjellja mbulon vetëm pajisjet që zotëroni

Strehimi i një serveri është drejtimi i kundërt: një lidhje e re vjen nga interneti dhe duhet të arrijë makinën tuaj duke kaluar nëpër çdo shtresë. Një rregull përcjelljeje porti në ruterin e brendshëm ndihmon vetëm nëse përkthyesi i jashtëm jua dorëzon edhe atë trafik. Përsëritja e rregullit lokal nuk ju jep kontroll mbi pajisjet e ofruesit.

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

Krahasoni adresën WAN të ruterit të brendshëm me adresën publike që vëzhguat, dhe shënoni nga ka ardhur çdo vlerë. Nëse adresa WAN është private ose në intervalin e përbashkët, shtresa e jashtme po bën një përkthim që ju nuk mund ta konfiguroni. Pyetni ofruesin se çfarë arritshmërie hyrëse mbështet përpara se të kaloni një mbrëmje të tërë me rregulla që nuk mund të hyjnë në fuqi. Heqja e një ruteri ose çaktivizimi i gjerë i një muri zjarri nuk është diagnozë, dhe është një shkëmbim i dobët për një port të vetëm të hapur.

Ndaloni nëse shtresa e jashtme është e ofruesit dhe nuk përcjell. Atëherë përgjigjet e mbështetura janë një metodë tjetër aksesi ose një rele, jo një rregull tjetër nga ana juaj.

Testoni një ndryshore në një herë

Ndryshoni një gjë për test dhe shënoni rezultatin, sepse një rrugë me NAT të dyfishtë ka më shumë ndryshore se një me një ruter të vetëm. Mbani profilin dhe pajisjen fikse, më pas krahasoni një rrjet tjetër aksesi. Vini re nëse negocimi dështon, nëse sesioni bie pas papunësisë, ose nëse dështojnë vetëm destinacionet private. Këto tre vëzhgime tregojnë tre shtresa të ndryshme.

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

Nënrrjetet private që mbivendosen janë një kurth më vete që asnjë sasi përkthimi nuk e rregullon. Nëse rrjeti juaj i shtëpisë dhe rrjeti i largët përdorin të njëjtin interval, shfaqet një konflikt rrugësh pavarësisht sa përkthyes ka në mes. Rinumerimi i njërës anë është përgjigja e vetme e qëndrueshme.

Porta e largët meriton të njëjtin vëmendje, sepse rregullat e saj të përcjelljes dhe rrugët e kthimit mund të jenë pjesa që mungon. Një tunel që vërtetohet mund të mos ketë ende një rrugë të përdorshme aplikacioni, dhe ai dështim duket identik nga ana e klientit. Shëtitja përfundon kur mund të thoni cili drejtim dështon dhe cila shtresë është përgjegjëse për të.