Hotell-Wi-Fi: VPN feilar før det i det heile når serveren

VPN-klienten spinner, rapporterer så at han ikkje når serveren, og alle konkluderer med at hotellet blokkerer VPN. Vanlegvis har ingenting så dramatisk skjedd: nettet har ikkje sleppt deg ut enno. Ein captive-portal held kvar tilkopling tilbake til du loggar på, og ein tunnel kan ikkje fullførast medan ei innloggingsside fangar pakkane hans. Gå gjennom pålogginga før du gir tunnelen skulda.

Myten: hotellet blokkerer VPN

Dei fleste hotellnett filtrerer ikkje tunnelar spesielt. Dei fangar netttrafikk til gjesten autentiserer seg, og dei kan òg avgrense einingar, la økter gå ut eller strupe gjennomstrøyminga. Kvar av desse gir ein feil som innanfrå ein VPN-klient ser ut som ei blokkering.

Tunnelen er eit dårleg diagnoseverktøy her, fordi han er den einaste applikasjonen som garantert feilar medan portalen ikkje er autorisert. Vanleg nettilgang er ein betre indikator, fordi han kan vise deg sjølve innloggingssida.

Den rekkjefølgja betyr noko av ein annan grunn: ein klient med kill switch eller alltid-på-modus vil nekte å laste portalen, og brukaren konkluderer med at nettet er øydelagt og ikkje innstillinga. Begge fakta er sanne samstundes, og berre eitt av dei kan endrast på hotellet. Slå av vernet via klienten si eiga styring, logg på, og slå det på att. Alt anna er ein omveg som skjuler den verkelege rekkjefølgja.

Fullfør portalen først, og test deretter vanleg HTTPS

Spør personalet om det offisielle nettverksnamnet og påloggingsmetoden. Ein overtydande SSID er ikkje prov på eigarskap, og eit andre nett med liknande namn er eit vanleg triks på offentlege stader. Bruk operativsystemet si eiga påloggingsforespurnad der ho blir boden, eller den dokumenterte sida til hotellet.

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/

Den første førespurnaden spør eit kjent deteksjonsendepunkt for captive-portalar over vanleg HTTP; ei omdirigering eller uventa innhald betyr at du framleis er bak portalen. Den andre testar eit normalt HTTPS-nettstad. Viss den første viser avskjering og den andre feilar, er pålogginga ufullstendig og VPN har ingenting med det å gjere.

På ein personleg eining må kanskje kill switch eller alltid-på-VPN slåast av via den støtta styringa til klienten slik at portalen kan lastast. Lukk sensitive apper i det tidsvindauget og slå vernet på att med ein gong etterpå. På ei styrt eining brukar du prosedyren administratoren har godkjend i staden for å fjerne ein policy sjølv.

Omgå aldri ei sertifikatåtvaring, og installer aldri eit ukjent sertifikat eller hjelpeprogram for å kome på nett. Viss portalen krev noko uventa, stadfest det med personalet, og med administratoren viss eininga høyrer til ein arbeidsgivar.

Ta vare på den opphavlege profilen og feilen hans

Når vanleg tilgang virkar, koplar du til den opphavlege profilen og noterer den nøyaktige feilen. Ei autentiseringsavvising er eit kontoproblem, ein tidsavbrot under forhandlinga er eit vegproblem, og ein tunnel som blir oppretta men ikkje ber noko, er eit rutings- eller policyproblem.

Desse tre treng ulike neste steg, og eit skjermbilete av feilen er verdt meir enn ei skildring. Noter òg tida, fordi øktsgrensene til hotellet kan gå ut innan ein time og gi ein feil som verkar tilfeldig. Viss klienten tilbyr ein logg, tar du vare på avsnittet rundt den første feilen og ikkje heile fila. Det utdraget er vanlegvis nok for den som eig profilen, til å identifisere fasen.

Viss vanleg tilgang virkar og forhandlinga framleis går ut, spør hotellet om det støttar trafikken, og samanlikn med ein påliteleg hotspot med eininga og profilen uendra. Arbeid på hotspoten snevrar inn merksemda mot hotelvegen utan å bevise noko om profilen.

Bruk berre alternativa operatøren leverer

Ein samsvarande TCP-profil kan lukkast der den tilbodne UDP-vegen ikkje virkar, men berre viss serveren faktisk lyttar på den transporten og porten. TCP-port 443 blir ikkje automatisk handsama som vanleg HTTPS, og det er inga garanti for passasje gjennom eit restriktivt nett.

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

Å køyre den leverte profilen med høgare detaljnivå held den første nyttige feilen synleg i staden for å presse han saman i ein generisk feildialog. Bruk fila operatøren gav, i staden for å redigere portar eller protokollar sjølv, fordi ei lokal endring ikkje kan skape ein samsvarande lyttar på den andre sida.

Viss tunnelen blir tilbakestilt gjentekne gonger, noter om portalen dukkar opp att eller det lokale signalet fell, og følg stabilitetssjekkane i staden for å byte fleire protokollar på ein gong. Test deretter appen du faktisk treng, og gjenopprett dei normale personvernkontrollane. Ei tilkopling som ber éin nettstad men ikkje ein annan, er eit rutings- eller policyspørsmål, ikkje eit portalspørsmål.

Til slutt, sjekk gjenopprettinga etter at laptopen har sove. Portalautorisasjonen kan gå ut uavhengig av tunnelen, så ei eining som koplar til automatisk att, kan kome tilbake til eit nett som allereie har gløymt henne. Å opne portalsida på nytt er eit normalt steg, ikkje eit teikn på at VPN er øydelagt.