Pse një profil OpenVPN funksionon në shtëpi por dështon në hotel

Wi-Fi i zyrës dhe një dhomë hoteli mund t'i japin të njëjtit laptop dy rrjete shumë të ndryshme, dhe profili në mes nuk di gjë për këtë. Ajo që funksionon në shtëpi parashikon një lidhje dalëse tolerante, zgjidhje emrash që funksionon dhe një nënrrjet lokal që nuk përplaset me asgjë që transporton tuneli. Secili prej këtyre supozimeve mund të dështojë veçmas.

Mënyra e dobishme për ta korrigjuar këtë është ta trajtoni rrjetin si katër fakte të veçanta dhe më pas t'i provoni me radhë. Të hamendësosh për profilin fillimisht zakonisht prodhon një ndryshim që nuk rregullon asgjë dhe errëson provat.

Katër fakte rrjeti ndryshojnë midis vendndodhjeve

Fakti i parë është nëse rrjeti lokal ju lejon të dilni fare. Një portal hyrjeje e lejon një pajisje në një faqe hyrjeje dhe bllokon gjithçka tjetër derisa ajo faqe të përfundojë, që do të thotë se tuneli nuk mund të nisë, sado i saktë qoftë profili.

I dyti është zgjidhja e emrave. Një portal që përgjon DNS i përgjigjet çdo kërkese me adresën e vet, kështu që emri i hostit të VPN zgjidhet në portal dhe klienti përpiqet të ndërtojë një tunel drejt një faqeje web.

I treti është filtrimi i transportit. Rrjetet që duan të lejojnë vetëm shfletimin lëshojnë TCP 443 drejt destinacioneve arbitrare dhe hedhin pothuajse gjithçka tjetër, përfshirë UDP.

I katërti është adresimi. Nënrrjeti lokal mund të mbivendoset me një rrjet pas tunelit, ose lidhja dalëse mund të mos ofrojë fare një rrugë IPv4 të përdorshme.

Zgjidhja e emrave dhe portali i hyrjes

Zëvendësoni emrin e hostit në profil me adresën numerike të serverit dhe provoni përsëri. Nëse IP-ja lidhet dhe emri jo, faji është te zgjidhja e emrave, dhe vetë profili është në rregull.

Hapni një shfletues dhe provoni një faqe HTTP të zakonshme para se të prekni VPN-në. Një ridrejtim drejt një faqeje hyrjeje do të thotë që portali është ende në pritje; përfundojeni, pastaj rilidhuni. Shumë hotele gjithashtu e skadojnë sesionin pas disa orësh, që duket si një shkëputje në mes të ditës dhe jo si problem hyrjeje.

Nëse edhe adresa numerike dështon, zgjidhja e emrave nuk është shpjegimi, kështu që kaloni te transporti. Mbani adresën që testuat, sepse i tregon kontrollit tjetër nëse paketat e lanë makinën fare.

Filtrimi i transportit: fillimisht UDP, TCP 443 si rezervë

Një rrjedhë OpenVPN mbi UDP 1194 nuk duket si asgjë që njeh një firewall hoteli, kështu që hidhet pa gabim. Klienti përpiqet përsëri derisa të skadojë kohëmatësi i tij, dhe përdoruesi sheh një lidhje që nuk vendoset kurrë në vend të një refuzimi. Firewall-et që sillen kështu rrallë e regjistrojnë hedhjen diku që mund ta shihni. Mungesa e një refuzimi është vetë të dhëna.

TCP 443 është rezerva e besueshme sepse rrjeti nuk mund ta dallojë nga një HTTPS i zakonshëm. Përdorni profilin TCP të operatorit kur ekziston, pasi edhe serveri duhet të dëgjojë në atë transport dhe portë; ndryshimi vetëm i klientit prodhon një lloj tjetër dështimi. Nëse nuk ekziston asnjë profil TCP, pyesni operatorin në vend që të shpikni një duke redaktuar portën. Ana e serverit duhet të pajtohet, dhe një mospërputhje duket përsëri si problem firewall-i.

Prisni një kosto performance. TCP brenda TCP amplifikon ritransmetimet në një lidhje me humbje, kështu që një tunel TCP që funksionon mund të duket ende i ngadaltë në një rrjet hoteli të mbingarkuar. Ky është një shkëmbim për arritshmërinë, jo një defekt për ta ndjekur.

Përplasjet e adresave dhe lidhjet dalëse pa IPv4

Një tunel mund të vendoset dhe prapë të mos transportojë asgjë. Kur LAN-i lokal dhe një rrjet i largët ndajnë një parashtesë si 192.168.1.0/24, klienti e konsideron hostin e largët të lidhur drejtpërdrejt dhe e dërgon paketën te lidhja lokale në vend të tunelit. Simptomi është një lidhje e suksesshme me një nënrrjet të paarritshëm, që lexohet lehtë gabimisht si problem rruge në anën e serverit.

Rregullimi i përhershëm është transferimi i LAN-it të largët në një interval privat të pazakontë. Zgjedhja e një intervali që askush nuk e përdor në shtëpi, si 10.42.0.0/24, e parandalon problemin për çdo vendndodhje të ardhshme në vend të një. Zgjidhja lokale është shmangia e atij hoteli, hotspot-i ose ruteri, që nuk është fare rregullim.

Lidhjet dalëse mobile shtojnë dy variante. NAT në nivel operatori do të thotë që lidhjet hyrëse nuk mbërrijnë, që ka rëndësi nëse strehoni një server, por jo për një klient dalës. Një APN i konfiguruar vetëm me IPv6 dhe përkthim NAT64 mund të dështojë një klient që këmbëngul në një rrugë reale IPv4, dhe ilaçi i zakonshëm është ndryshimi i protokollit të APN-së në IPv4 ose stivë të dyfishtë.

Simptomat pasi tuneli është ngritur

Një tunel që lidhet dhe pastaj hesht është zakonisht një problem keepalive ose MTU, jo një portë e bllokuar. Një lidhje që bie pas një numri fiks minutash tregon një kohëmatës keepalive ose rinegocimi. Vendosni klientin të kontrollojë palën e vet dhe të rinisë kur përgjigjet ndalen, dhe provoni një MTU tuneli më të vogël nëse ping-et kalojnë ndërsa transferimet e mëdha ngecin.

Para se të kërkoni ndihmë, shkruani tri gjëra: adresën që provuat dhe nëse u përgjigj, transportin dhe portën që përdorët, dhe nënrrjetin lokal të rrjetit që dështoi. Së bashku ato ndajnë zgjidhjen e emrave nga filtrimi i transportit dhe nga një përplasje adresash, dhe këto janë shkaqet që i mbijetojnë kontaktit me provat.