OpenVPN nuk lidhet në Wi-Fi-n e hotelit? Provo TCP 443

Hap klientin, shtyp Lidhu dhe lexo rreshtin e statusit në vend të dialogut që vjen pas tij. Një profil që ngec në Po lidhet ose Në pritje të serverit pas një rrjeti hoteli, kampusi ose celular zakonisht ka humbur transportin diku në rrugë, jo kredencialet. Hapi tjetër i dobishëm është të zbulosh çfarë transporton ai rrjet përpara se të prekësh serverin. Mos ndrysho asgjë derisa i njëjti profil të ketë funksionuar diku tjetër.

Provo fillimisht nga një hotspot telefoni. Nëse tuneli ngrihet atje, serveri, certifikata dhe llogaria janë të gjitha në rregull, dhe e vetmja variabël e mbetur është rrjeti para teje.

Fillo nga klienti: lexo rreshtin e statusit

Rreshti i statusit të tregon se cila etapë dështoi. Një klient i bllokuar në Po lidhet ende po zgjidh emrin e hostit ose po hap socketin e jashtëm; ai që arrin Në pritje të serverit ka rrugë, por nuk ka përgjigje; ai që autentikohet dhe pastaj bie ka një problem krejt tjetër. Regjistri i klientit dhe fushat remote e proto të vetë profilit tregojnë çfarë po përpiqet të bëjë klienti, dhe --verb 4 në një klient të rreshtit të komandës shtyp të njëjtin detaj. Krahasimi i kësaj me rrjetin para teje është ajo që e kthen 'VPN-ja është e bllokuar' në një pohim konkret.

Pastaj heto rrjetin me mjetet që ke tashmë. nc -vzu 203.0.113.10 1194 dërgon një datagram UDP, curl -v telnet://203.0.113.10:443 raporton nëse përfundon shtrëngimi i duarve TCP, dhe një shfletues që ngarkon një faqe HTTPS vërteton vetëm se dalja 443 arrin atë host të vetëm. Hetimet e vogla përgjigjen atë që klienti VPN nuk mundet: cila portë dhe cili protokoll dalin fare nga ky rrjet.

Tre sjellje rrjeti duken njësoj nga klienti dhe kërkojnë përgjigje të ndryshme. Dalja 443 mund të jetë e hapur, mund të lejohet vetëm një proxy, ose 443 mund të përçohet në mënyrë transparente te një kuti inspektimi që nuk mund të lexojë çfarë transporton. E para rregullohet me ndryshimin e profilit më poshtë, e dyta me cilësimet e proxy-t, dhe e treta mund të përfundojë shtrëngimin e duarve dhe pastaj të ngecë kur inspektori vendos se nuk i pëlqen rrjedha. Të dish se me cilën nga të treat përballesh është ndryshimi midis një ndryshimi dhjetë minutash dhe një pasditeje duke reinstaluar klientë.

Zhvendos dëgjuesin dhe profilin së bashku

Nga ana e serverit, vendos dëgjuesin në atë që lejon rrjeti: port 443 dhe proto tcp në konfigurimin e serverit, pastaj rinis shërbimin dhe konfirmo socketin me ss -lntp. Nga ana e klientit, profili duhet të pajtohet, sepse transporti dhe porta qëndrojnë jashtë tunelit: proto tcp dhe port 443 në .ovpn, ose fushat përkatëse në ekranin e cilësimeve të aplikacionit. Një profil ende i drejtuar nga UDP 1194 dështon saktësisht si më parë, dhe tundimi është të fajësosh një firewall që tashmë është rregulluar. Nëse i njëjti host përgjigjet edhe me HTTPS në 443, dy dëgjuesit nuk mund ta ndajnë atë adresë dhe protokoll; jepi VPN-së një adresë të dytë ose vendos përpara një demultiplekser.

Ndiq lidhjen e parë me tcpdump -ni any port 443 në të dy skajet. Paketat që largohen nga klienti dhe nuk mbërrijnë kurrë nënkuptojnë se rrjeti filtron gjithsesi, ose se adresa në profil nuk është ajo që supozon. Paketat që mbërrijnë pa përgjigje të kthejnë te regjistri i serverit, ku një mospërputhje protokolli shfaqet menjëherë si një paketë e hedhur.

Kur vetëm një proxy del nga rrjeti

Disa rrjete mysafirësh nuk lejojnë asgjë përveç një proxy HTTP, që është një kufizim tjetër nga një portë e mbyllur dhe përjashton më shumë se OpenVPN. Klientët që flasin vetëm PPTP, L2TP/IPsec ose IPsec të pastër nuk kanë rrugë përmes tij, sepse ato dizenjime presin që protokolli i tyre i jashtëm të arrijë serverin drejtpërdrejt. OpenVPN mundet, me http-proxy proxy.example.net 8080 në profilin e klientit, me kusht që proxy-t t'i lejojë metodën CONNECT drejt portës tënde. Një proxy SOCKS është edhe më i lehtë, sepse e përçon rrjedhën pa u kujdesur çfarë ka brenda.

Aty ku klienti nuk ka mbështetje proxy, zakonisht mbetet një tunel SSH mbi 443. Ai shton një shtresë të dytë, dhe operatori i rrjetit mund të ketë mendim për këtë, ndaj trajtoje si një urë për një udhëtim dhe jo si arkitekturë.

Vlerëso koston e zgjidhjes rezervë para se ta mbash

TCP brenda TCP ka një kosto të njohur. Kur lidhja e jashtme është TCP dhe ngarkesa është gjithashtu TCP, një segment i humbur shkakton ritransmetim në të dy shtresat, dhe lidhja e brendshme tërhiqet para një humbjeje që nuk mund ta shohë. Shfletimi e duron; sesionet interaktive dhe thirrjet e ndiejnë. Mbaj dëgjuesin TCP 443 si zgjidhje rezervë për rrjetet që e kërkojnë, dhe lëre UDP si parazgjedhje për gjithçka që ende e lejon të kalojë.

Regjistro zgjedhjen në emrin e profilit dhe në shënimet e mbështetjes: cila portë, cili protokoll dhe cili rrjet e shkaktoi. Pastaj pyet administratorin e rrjetit nëse ajo portë mbetet e hapur pas zëvendësimit të ardhshëm të pajisjeve, sepse një zgjidhje rezervë që zhduket në heshtje është më e keqe se sa asnjë zgjidhje rezervë.