Hotel-Wi-Fi: VPN fejler, før den overhovedet når serveren

VPN-klienten snurrer, rapporterer så at den ikke kan nå serveren, og alle konkluderer, at hotellet blokerer VPN. Normalt er der ikke sket noget så dramatisk: netværket har ikke lukket dig ud endnu. En captive-portal holder hver forbindelse, indtil du logger ind, og en tunnel kan ikke fuldføres, mens dens pakker opfanges af en login-side. Gå igennem login, før du bebrejder tunnelen.

Myten: hotellet blokerer VPN

De fleste hotelnetværk filtrerer ikke tunneler specifikt. De opfanger webtrafik, indtil gæsten godkender sig, og de kan også begrænse enheder, udløbe sessioner eller drosle gennemstrømningen. Hver af disse giver en fejl, der indefra en VPN-klient ligner en blokering.

Tunnelen er et dårligt diagnostisk værktøj her, fordi den er den ene applikation, der med sikkerhed fejler, mens portalen ikke er godkendt. Almindelig webadgang er den bedre indikator, fordi den kan vise dig selve login-siden.

Den rækkefølge betyder noget af en anden grund: en klient med kill switch eller altid-til-tilstand vil nægte at indlæse portalen, og brugeren konkluderer, at netværket er i stykker snarere end indstillingen. Begge fakta er sande på én gang, og kun det ene kan ændres på hotellet. Slå beskyttelsen fra via klientens egen betjening, log ind, og slå den til igen. Alt andet er en omvej, der skjuler den rigtige rækkefølge.

Færdiggør portalen først, og test så almindelig HTTPS

Spørg personalet om det officielle netværksnavn og login-metoden. Et overbevisende SSID er ikke bevis på ejerskab, og et andet netværk med et lignende navn er et almindeligt trick på offentlige steder. Brug operativsystemets egen login-anmodning, hvor den tilbydes, eller hotellets dokumenterede 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 anmodning spørger en kendt detektionsendpoint for captive-portaler over almindelig HTTP; en omdirigering eller uventet indhold betyder, at du stadig er bag portalen. Den anden tester et normalt HTTPS-site. Hvis den første viser aflytning, og den anden fejler, er login ufuldstændigt, og VPN har intet med det at gøre.

På en personlig enhed kan kill switch eller altid-til-VPN skulle slås fra via klientens understøttede betjening, så portalen kan indlæses. Luk følsomme programmer i det tidsrum, og slå beskyttelsen til igen med det samme bagefter. På en administreret enhed bruger du den procedure, administratoren har godkendt, i stedet for selv at fjerne en politik.

Omgå aldrig en certifikatadvarsel, og installer aldrig et ukendt certifikat eller hjælpeprogram for at komme online. Hvis portalen kræver noget uventet, så bekræft det med personalet, og med administratoren hvis enheden tilhører en arbejdsgiver.

Behold den oprindelige profil og dens fejl

Når almindelig adgang virker, skal du tilslutte den oprindelige profil og notere den præcise fejl. En afvisning af godkendelse er et kontoproblem, en timeout under forhandlingen er et vejproblem, og en tunnel, der etableres men ikke bærer noget, er et routing- eller politikproblem.

De tre kræver forskellige næste skridt, og et skærmbillede af fejlen er mere værd end en beskrivelse. Noter også tidspunktet, fordi hotellets sessionsgrænser kan udløbe inden for en time og give en fejl, der virker tilfældig. Hvis klienten tilbyder en log, så behold afsnittet omkring den første fejl i stedet for hele filen. Det uddrag er som regel nok for den, der ejer profilen, til at identificere fasen.

Hvis almindelig adgang virker, og forhandlingen stadig udløber, så spørg hotellet, om det understøtter trafikken, og sammenlign med et betroet hotspot med enheden og profilen uændret. Arbejde på hotspotet indsnævrer opmærksomheden til hotellets vej uden at bevise noget om profilen.

Brug kun de alternativer, operatøren leverer

En matchende TCP-profil kan lykkes, hvor den tilbudte UDP-vej ikke gør, men kun hvis serveren faktisk lytter på den transport og port. TCP-port 443 behandles ikke automatisk som almindelig HTTPS, og det er ikke en garanti for passage gennem et restriktivt netværk.

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

At køre den leverede profil med højere detaljeringsgrad holder den første brugbare fejl synlig i stedet for at presse den sammen i en generisk fejldialog. Brug den fil, operatøren gav, i stedet for selv at redigere porte eller protokoller, fordi en lokal ændring ikke kan skabe en matchende lytter på den anden side.

Hvis tunnelen nulstilles gentagne gange, så noter, om portalen dukker op igen, eller om det lokale signal falder, og følg stabilitetstjekkene i stedet for at skifte flere protokoller på én gang. Test derefter det program, du faktisk har brug for, og genskab de normale privatlivskontroller. En forbindelse, der bærer det ene site men ikke det andet, er et routing- eller politikspørgsmål, ikke et portalspørgsmål.

Til sidst skal du kontrollere gendannelse, efter at computeren har været i dvale. Portalens godkendelse kan udløbe uafhængigt af tunnelen, så en enhed, der automatisk genopretter forbindelsen, kan vende tilbage til et netværk, der allerede har glemt den. At åbne portalsiden igen er et normalt skridt, ikke et tegn på, at VPN er i stykker.