Hotell-Wi-Fi: VPN misslyckas innan det ens når servern

VPN-klienten snurrar, rapporterar sedan att den inte når servern, och alla drar slutsatsen att hotellet blockerar VPN. Vanligtvis har inget så dramatiskt hänt: nätverket har inte släppt ut dig ännu. En captive-portal håller varje anslutning kvar tills du loggar in, och en tunnel kan inte slutföras medan en inloggningssida fångar upp dess paket. Gå igenom inloggningen innan du skyller på tunneln.

Myten: hotellet blockerar VPN

De flesta hotellnät filtrerar inte tunnlar särskilt. De fångar upp webbtrafik tills gästen autentiserar sig, och de kan också begränsa enheter, låta sessioner gå ut eller strypa genomströmningen. Var och en av dessa ger ett fel som inifrån en VPN-klient ser ut som en blockering.

Tunneln är ett dåligt diagnostikverktyg här, eftersom den är den enda applikationen som garanterat misslyckas medan portalen inte är auktoriserad. Vanlig webbåtkomst är den bättre indikatorn, eftersom den kan visa dig själva inloggningssidan.

Den ordningen spelar roll av en annan anledning: en klient med kill switch eller alltid-på-läge vägrar ladda portalen, och användaren drar slutsatsen att nätet är trasigt snarare än inställningen. Båda fakta är sanna samtidigt, och bara en av dem kan ändras på hotellet. Stäng av skyddet via klientens egen kontroll, logga in och slå på det igen. Allt annat är en omväg som döljer den verkliga ordningen.

Gör klart portalen först och testa sedan vanlig HTTPS

Fråga personalen om det officiella nätverksnamnet och inloggningsmetoden. En övertygande SSID är inget bevis på ägande, och ett andra nät med liknande namn är en vanlig fälla på offentliga platser. Använd operativsystemets egen inloggningsuppmaning där den erbjuds, eller hotellets dokumenterade sida.

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örsta begäran frågar en känd detektionspunkt för captive-portaler över vanlig HTTP; en omdirigering eller oväntat innehåll betyder att du fortfarande är bakom portalen. Den andra testar en normal HTTPS-sajt. Om den första visar avlyssning och den andra misslyckas är inloggningen ofullständig och VPN har inget med det att göra.

På en personlig enhet kan kill switch eller alltid-på-VPN behöva stängas av via klientens stödda kontroll så att portalen kan laddas. Stäng känsliga program under den perioden och slå på skyddet igen direkt efteråt. På en hanterad enhet följer du proceduren som administratören godkänt i stället för att själv ta bort en policy.

Kringgå aldrig en certifikatvarning och installera aldrig ett okänt certifikat eller hjälpprogram för att komma online. Om portalen kräver något oväntat, bekräfta det med personalen, och med administratören om enheten tillhör en arbetsgivare.

Behåll den ursprungliga profilen och dess fel

När vanlig åtkomst fungerar ansluter du den ursprungliga profilen och noterar det exakta felet. En autentiseringsavvisning är ett kontoproblem, en tidsgräns under förhandlingen är ett vägproblem, och en tunnel som etableras men inte bär något är ett routing- eller policyproblem.

Dessa tre kräver olika nästa steg, och en skärmbild av felet är värd mer än en beskrivning. Notera även tiden, eftersom hotellets sessionsgränser kan gå ut inom en timme och ge ett fel som verkar slumpmässigt. Om klienten erbjuder en logg, behåll avsnittet kring det första felet och inte hela filen. Det utdraget räcker oftast för den som äger profilen att identifiera fasen.

Om vanlig åtkomst fungerar och förhandlingen fortfarande går ut, fråga hotellet om det stöder trafiken, och jämför med en betrodd hotspot med enheten och profilen oförändrade. Att arbeta på hotspoten snävar in uppmärksamheten på hotellets väg utan att bevisa något om profilen.

Använd bara de alternativ som operatören tillhandahåller

En matchande TCP-profil kan lyckas där den erbjudna UDP-vägen inte fungerar, men bara om servern faktiskt lyssnar på den transporten och porten. TCP-port 443 behandlas inte automatiskt som vanlig HTTPS, och det är ingen garanti för passage genom ett restriktivt nät.

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

Att köra den medföljande profilen med högre detaljnivå håller det första användbara felet synligt i stället för att pressa ihop det i en allmän feldialog. Använd filen som operatören gav i stället för att själv redigera portar eller protokoll, eftersom en lokal ändring inte kan skapa en matchande lyssnare på andra sidan.

Om tunneln återställs upprepade gånger, notera om portalen dyker upp igen eller om den lokala signalen faller, och följ stabilitetskontrollerna i stället för att byta flera protokoll på en gång. Testa sedan appen du faktiskt behöver och återställ de normala integritetskontrollerna. En anslutning som bär en sajt men inte en annan är en routing- eller policyfråga, inte en portalfråga.

Kontrollera slutligen återhämtningen efter att datorn har sovit. Portalens auktorisering kan gå ut oberoende av tunneln, så en enhet som återansluter automatiskt kan komma tillbaka till ett nät som redan har glömt den. Att öppna portalsidan igen är ett normalt steg, inte ett tecken på att VPN är trasigt.