Hotel-Wi-Fi: die VPN misluk voordat dit ooit die bediener bereik

Die VPN-kliënt draai en rapporteer dan dat dit die bediener nie kan bereik nie, en almal kom tot die slotsom dat die hotel VPN's blokkeer. Gewoonlik het niks so dramaties gebeur nie: die netwerk het jou nog nie toegelaat om uit te gaan nie. 'n Vasgevangde portaal hou elke verbinding vas tot jy aanmeld, en 'n tonnel kan nie klaarmaak terwyl sy pakkette deur 'n aanmeldbladsy onderskep word nie. Werk eers deur die aanmelding voordat jy die tonnel blameer.

Die mite: die hotel blokkeer VPN's

Die meeste hotelnetwerke filtreer nie tonnels spesifiek nie. Hulle onderskep webverkeer totdat die gas authentiseer, en hulle kan ook toestelle beperk, sessies laat verstryk of deurset beperk. Elkeen daarvan lewer 'n fout op wat van binne 'n VPN-kliënt soos 'n blokkade lyk.

Die tonnel is hier 'n swak diagnosemiddel, want dit is die een toepassing wat gewaarborgd misluk terwyl die portaal nie gemagtig is nie. Gewone webtoegang is die beter aanduiding, want dit kan vir jou die aanmeldbladsy self wys.

Daardie volgorde maak om nog 'n rede saak: 'n kliënt met 'n doodskakelaar of altyd-aan-modus sal weier om die portaal te laat laai, en die gebruiker kom tot die slotsom dat die netwerk stukkend is eerder as die instelling. Beide feite is gelyktydig waar, en net een van hulle kan by die hotel verander word. Skakel die beskerming af deur die kliënt se eie beheer, meld aan, en skakel dit weer aan. Enigiets anders is 'n ompad wat die werklike volgorde verberg.

Maak die portaal eerste klaar en toets dan gewone HTTPS

Vra die personeel na die amptelike netwerknaam en die aanmeldmetode. 'n Oortuigende SSID is nie bewys van eienaarskap nie, en 'n tweede netwerk met 'n soortgelyke naam is 'n algemene truuk op openbare plekke. Gebruik die bedryfstelsel se eie aanmeldvenster waar dit een bied, of die hotel se gedokumenteerde bladsy.

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/

Die eerste versoek vra 'n bekende vasgevangde-portaal-opsporingseindpunt oor gewone HTTP; 'n herleiding of onverwagte inhoud beteken jy is nog agter die portaal. Die tweede toets 'n normale HTTPS-werf. As die eerste 'n onderskepping wys en die tweede misluk, is die aanmelding onvolledig en het die VPN niks daarmee te doen nie.

Op 'n persoonlike toestel moet die doodskakelaar of altyd-aan-VPN dalk afgeskakel word deur die kliënt se ondersteunde beheer sodat die portaal kan laai. Sluit sensitiewe toepassings gedurende daardie tydperk en skakel die beskerming onmiddellik daarna weer aan. Op 'n bestuurde toestel gebruik die prosedure wat die administrateur goedgekeur het eerder as om self 'n beleid te verwyder.

Omseil nooit 'n sertifikaatwaarskuwing nie en installeer nooit 'n onbekende sertifikaat of hulpprogram om aanlyn te kom nie. As die portaal iets onverwags eis, bevestig dit met die personeel, en met die administrateur as die toestel aan 'n werkgewer behoort.

Hou die oorspronklike profiel en sy fout

Sodra gewone toegang werk, koppel die oorspronklike profiel en teken die presiese fout aan. 'n Magtigingsverwerping is 'n rekeningprobleem, 'n tydversaking tydens onderhandeling is 'n padprobleem, en 'n tonnel wat tot stand kom maar niks dra nie is 'n roetering- of beleidsprobleem.

Daardie drie het verskillende volgende stappe nodig, en 'n skermkiekie van die fout is meer werd as 'n beskrywing. Noteer ook die tyd, want hotel-sessieperke kan binne 'n uur verstryk en 'n fout lewer wat willekeurig lyk. As die kliënt 'n logboek bied, hou die afdeling rondom die eerste fout eerder as die hele lêer. Daardie uittreksel is gewoonlik genoeg vir wie ook al die profiel besit om die stadium te identifiseer.

As gewone toegang werk en die onderhandeling steeds tydversak, vra die hotel of dit die verkeer ondersteun, en vergelyk met 'n betroubare hotspot terwyl die toestel en profiel konstant gehou word. Werk op die hotspot vernou die aandag na die hotelpad sonder om enigiets oor die profiel te bewys.

Gebruik net alternatiewe wat die operateur verskaf

'n Passende TCP-profiel kan slaag waar die aangebode UDP-pad nie werk nie, maar net as die bediener werklik op daardie transport en poort luister. TCP-poort 443 word nie outomaties as gewone HTTPS behandel nie, en dit is nie 'n waarborg van deurgang deur 'n beperkende netwerk nie.

sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4

Om die verskafde profiel met 'n hoër breedsprakigheid te laat loop, hou die eerste nuttige fout sigbaar in plaas daarvan om dit in 'n generiese foutdialoog te laat opgaan. Gebruik die lêer wat die operateur verskaf het eerder as om self poorte of protokolle te wysig, want 'n plaaslike verandering kan nie 'n passende luisteraar aan die ander kant skep nie.

As die tonnel herhaaldelik terugstel, let op of die portaal weer verskyn of die plaaslike sein val, en volg die stabiliteitskontroles eerder as om verskeie protokolle gelyktydig te wissel. Toets dan die toepassing wat jy werklik nodig het en herstel die normale privaatheidskontroles. 'n Verbinding wat een werf dra maar nie 'n ander nie, is 'n roetering- of beleidsvraag, nie 'n portaalvraag nie.

Laastens, kontroleer herstel nadat die skootrekenaar geslaap het. Portaalmagtiging kan onafhanklik van die tonnel verstryk, so 'n toestel wat outomaties weer koppel, kan terugkom by 'n netwerk wat dit al vergeet het. Om die portaalbladsy weer oop te maak is 'n normale stap, nie 'n teken dat die VPN stukkend is nie.