Hotell-Wi-Fi: VPN feiler før det i det hele tatt når serveren

VPN-klienten spinner, rapporterer så at den ikke når serveren, og alle konkluderer med at hotellet blokkerer VPN. Vanligvis har ingenting så dramatisk skjedd: nettet har ikke sluppet deg ut ennå. En captive-portal holder hver tilkobling tilbake til du logger på, og en tunnel kan ikke fullføres mens en innloggingsside fanger pakkene dens. Gå gjennom påloggingen før du gir tunnelen skylden.

Myten: hotellet blokkerer VPN

De fleste hotellnett filtrerer ikke tunneler spesielt. De fanger netttrafikk til gjesten autentiserer seg, og de kan også begrense enheter, la økter utløpe eller strupe gjennomstrømningen. Hver av disse gir en feil som innenfra en VPN-klient ser ut som en blokkering.

Tunnelen er et dårlig diagnoseverktøy her, fordi den er den eneste applikasjonen som garantert feiler mens portalen ikke er autorisert. Vanlig nettilgang er en bedre indikator, fordi den kan vise deg selve innloggingssiden.

Den rekkefølgen betyr noe av en annen grunn: en klient med kill switch eller alltid-på-modus vil nekte å laste portalen, og brukeren konkluderer med at nettet er ødelagt og ikke innstillingen. Begge fakta er sanne samtidig, og bare ett av dem kan endres på hotellet. Slå av beskyttelsen via klientens egen kontroll, logg på, og slå den på igjen. Alt annet er en omvei som skjuler den virkelige rekkefølgen.

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

Spør personalet om det offisielle nettverksnavnet og påloggingsmetoden. En overbevisende SSID er ikke bevis på eierskap, og et andre nett med lignende navn er et vanlig triks på offentlige steder. Bruk operativsystemets egen påloggingsforespørsel der den tilbys, eller hotellets dokumenterte side.

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 forespørselen spør et kjent deteksjonsendepunkt for captive-portaler over vanlig HTTP; en omdirigering eller uventet innhold betyr at du fortsatt er bak portalen. Den andre tester et normalt HTTPS-nettsted. Hvis den første viser avskjæring og den andre feiler, er påloggingen ufullstendig og VPN har ingenting med det å gjøre.

På en personlig enhet må kanskje kill switch eller alltid-på-VPN slås av via klientens støttede kontroll slik at portalen kan lastes. Lukk sensitive apper i det tidsvinduet og slå beskyttelsen på igjen umiddelbart etterpå. På en administrert enhet bruker du prosedyren administratoren har godkjent i stedet for å fjerne en policy selv.

Omgå aldri en sertifikatadvarsel, og installer aldri et ukjent sertifikat eller hjelpeprogram for å komme på nett. Hvis portalen krever noe uventet, bekreft det med personalet, og med administratoren hvis enheten tilhører en arbeidsgiver.

Ta vare på den opprinnelige profilen og feilen dens

Når vanlig tilgang virker, kobler du til den opprinnelige profilen og noterer den nøyaktige feilen. En autentiseringsavvisning er et kontoproblem, en tidsavbrudd under forhandlingen er et veiproblem, og en tunnel som etableres men ikke bærer noe, er et ruting- eller policyproblem.

Disse tre trenger ulike neste steg, og et skjermbilde av feilen er verdt mer enn en beskrivelse. Noter også tiden, fordi hotellets øktsgrenser kan utløpe innen en time og gi en feil som virker tilfeldig. Hvis klienten tilbyr en logg, tar du vare på avsnittet rundt den første feilen og ikke hele filen. Det utdraget er vanligvis nok for den som eier profilen, til å identifisere fasen.

Hvis vanlig tilgang virker og forhandlingen fortsatt utløper, spør hotellet om det støtter trafikken, og sammenlign med et pålitelig hotspot med enheten og profilen uendret. Arbeid på hotspotet snevrer oppmerksomheten inn mot hotellets vei uten å bevise noe om profilen.

Bruk bare alternativene operatøren leverer

En samsvarende TCP-profil kan lykkes der den tilbudte UDP-veien ikke virker, men bare hvis serveren faktisk lytter på den transporten og porten. TCP-port 443 behandles ikke automatisk som vanlig HTTPS, og det er ingen garanti for passasje gjennom et restriktivt nett.

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

Å kjøre den leverte profilen med høyere detaljnivå holder den første nyttige feilen synlig i stedet for å presse den sammen i en generisk feildialog. Bruk filen operatøren ga, i stedet for å redigere porter eller protokoller selv, fordi en lokal endring ikke kan skape en samsvarende lytter på den andre siden.

Hvis tunnelen tilbakestilles gjentatte ganger, noter om portalen dukker opp igjen eller det lokale signalet faller, og følg stabilitetssjekkene i stedet for å bytte flere protokoller på en gang. Test deretter appen du faktisk trenger, og gjenopprett de normale personvernkontrollene. En tilkobling som bærer ett nettsted men ikke et annet, er et ruting- eller policyspørsmål, ikke et portalspørsmål.

Til slutt, sjekk gjenopprettingen etter at laptopen har sovet. Portalautorisasjonen kan utløpe uavhengig av tunnelen, så en enhet som kobler til automatisk igjen, kan komme tilbake til et nett som allerede har glemt den. Å åpne portalsiden på nytt er et normalt steg, ikke et tegn på at VPN er ødelagt.