Varför captive-portalen blockerar din VPN och hur du loggar in igen

I ett öppet nätverk lämnar din åtkomstpunkt inte bara över paket till internet. En policypunkt längre upp kontrollerar om enheten redan är auktoriserad, och tills den är det kastas nästan allt. Din VPN-klient läser den tystnaden som en död server. Den säger det sällan: WireGuard upprepar ett handslag ut i tomma intet, OpenVPN rapporterar tidsgräns för anslutningen och IKEv2 kommer tillbaka som fel 809 om en fjärrserver som inte svarar.

Vad portalen faktiskt kontrollerar

En captive-portal är två saker hoplimmade: en policybeslutspunkt och en omdirigerare. När din enhet associerar och tar en DHCP-lease sätter nätverket dig i ett tillstånd före auktorisering.

Det tillståndet är en uppsättning brandväggsregler. Den släpper vanligtvis igenom DNS och tillåter HTTP eller HTTPS till en kort lista portalvärdar, och kastar allt annat. Den tillåtna listan är den inhägnade trädgården och innehåller nästan aldrig VPN-slutpunkten.

Ingen av dessa kastningar är artig. Paket riktade mot en VPN-server kastas i stället för att avvisas, så klienten får varken ICMP unreachable eller TCP reset, bara uteblivet svar. Beroende på leverantör kan omdirigeraren svara på port 80 med en omdirigering till inloggningssidan medan port 443 kastas eller avlyssnas. Omdirigeringar är lätta att upptäcka eftersom de bär ett vanligt HTTP-svar; avlyssning på 443 kräver ett certifikat som din webbläsare vägrar lita på.

Själva auktoriseringen är oftast knuten till enhetens MAC-adress, ibland till den leasade IP:n, och den lever i en sessionstabell med en timer. Inloggningen skapar en post. Brandväggsregeln som släpper igenom din trafik finns bara så länge den posten finns, och därför kommer hela problemet tillbaka senare utan att något ändras på din sida.

Varför VPN-handslaget dör innan det börjar

Varje protokoll har sin egen transport, och brandväggen före auktorisering bryter var och en olika. IKEv2 på Windows och iOS går över UDP 500 och UDP 4500; en kastning på dessa portar visar sig som 809, eller som ett namnupplösningsliknande fel hos klienter som rapporterar faserna separat. OpenVPN över UDP 1194 stannar i anslutningstillstånd tills tidsgränsen löper ut. OpenVPN över TCP 443 är det intressanta fallet, eftersom portalen kan slutföra TCP-handslaget och sedan svara med sin omdirigeringssida, så du ser ett TLS-fel i stället för en tidsgräns.

WireGuard visar mekanismen tydligast. Det är bara UDP enligt design, utan TCP-reserv, så en brandvägg som kastar okänt UDP tar bort transporten helt. Klienten fortsätter skicka handslagsinitieringar med växande paus och rapporterar ett handslag som aldrig slutförs. Ingenting i det meddelandet nämner wifi, och ingenting i det antyder att du bör öppna en webbläsare.

Plattformar försöker märka tillståndet före din VPN. Windows hämtar en känd URL för att avgöra om det ska visa sin inloggningsnotis, Android begär en slutpunkt som ska svara 204 No Content, och Apple-enheter öppnar ett litet captive-nätverksfönster. Dessa prober fungerar eftersom portalen svarar med en omdirigering i stället för den förväntade kroppen. Samma beteende förklarar hur en portal kan se helt frisk ut medan din tunnel är död: proben och tunneln bedöms enligt olika regler.

Vad ett sessionsutgång egentligen återställer

Platser låter sessioner gå ut av skäl som inte har med ditt VPN-konto att göra: en inaktivitetsgräns, en maximal sessionslängd, en ny DHCP-lease eller en ny associering till en annan åtkomstpunkt. När timern slår till försvinner posten i sessionstabellen och regeluppsättningen före auktorisering kommer tillbaka exakt som den var vid incheckningen.

En etablerad tunnel överlever ofta tillräckligt länge för att se frisk ut. Keepalive-meddelanden fortsätter gå ut, och om klienten märker det beror på hur den hanterar trafik utan svar, så statuslampan kan förbli grön ett tag efter att vägen försvunnit. Sedan faller tunneln och varje återanslutningsförsök misslyckas på samma blockerade portar.

I det läget berättar klientfelet vilken fas du är i, om du läser det noga:

En detalj lurar folk: när sessionen är knuten till en MAC-adress hjälper det kanske inte att ladda inloggningssidan igen. Du måste släppa associeringen och ansluta på nytt, så att portalen ser ett nytt auktoriseringsförsök i stället för ett utgånget.

Logga in först, höj sedan tunneln

Ordningen som fungerar är: auktorisera enheten, bevisa vägen, starta VPN:en, bevisa tunneln och återställ sedan din vanliga blockering. Det sista steget är viktigt eftersom det tillfälliga tillstånd du behöver för att nå portalen är exakt det tillstånd en kill switch finns för att förhindra.

En skrivbordsklient med alternativet att blockera utanför tunneln måste pausas så att portalsidan laddas, och du bör hålla känsliga appar stängda i det fönstret utanför tunneln; det är det enda intervallet då lokal trafik går ut oskyddad. En hanterad enhet som alltid är på bör använda proceduren som ägaren publicerat i stället för att du tar bort policyn. Om portalen visar en certifikatvarning, stanna: att acceptera den leder sessionen genom platsens avlyssningsproxy, och den proxyn kan läsa allt du skickar. På Android blockerar låset under alltid-på-VPN trafiken innan tunneln är uppe, och vissa byggen kan inte undanta portalflödet; om ditt inte kan, använd platsens alternativa åtkomst eller en annan enhet i stället för att lämna låset av. Apples on-demand-regler kan skrivas så att de nekar tunneln tills en probe lyckas, och det är beteendet du vill ha på hotellnätverk.

Verifiera i ordning med verktygen du redan har. Före tunneln kör du proben med både rubriker och kropp synliga, och ser om din VPN-transport får något svar alls:

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

Före auktorisering ger en normal portal ett av två svar: en 302 vars Location pekar på inloggningssidan, eller en 200 med en HTML-kropp som är portalsidan. Notera vilket du fick. En omdirigering är inte ett misslyckande före inloggning; det är portalen som säger vart du ska gå. När portalen rapporterar framgång upprepar du kommandot och väntar på en 200 vars kropp är det bokstavliga ordet Success. Det är den strängen som gör proben meningsfull. Om värden svarar normalt innan du någonsin loggat in finns ingen avlyssnande portal i det här nätverket. I inspelningen är en kastning före auktorisering utgående paket där ingenting kommer tillbaka, medan en väg som fungerar visar ett svar på samma flöde inom ungefär en sekund. Anslut och upprepa sedan inspelningen.

Om tunneln fortfarande misslyckas efter att portalen sagt ja

Inloggningsframgång är inte samma sak som tillåten transport. Många platser tillåter portalen och vanligt surfande men blockerar UDP helt, vilket lämnar WireGuard och UDP-OpenVPN trasiga och TCP 443 fungerande. Om TCP 443 passerar och UDP inte gör det är det platsens policy och inte en klient du konfigurerat fel, så byt transport eller acceptera gränsen och gå vidare. Om en återanslutning fortfarande misslyckas efter det, spara det exakta felet; det namnger fasen du sitter fast i.

Andra fel bor på enheten. En session som fortfarande är knuten till en gammal MAC, en andra wifi-adapter med sin egen lease, eller en klient som cachelagrat portalens certifikatundantag kan var och en fortsätta misslyckas efter en ren ny auktorisering. Släpp associeringen, auktorisera igen och försök en gång innan du rör klientinställningarna. RFC 8952 är värd att läsa om du vill ha arkitekturen bakom komponenterna du följer.

Om portalen själv vägrar auktorisera ligger problemet i kontot eller enhetstilldelningen och ingen VPN-inställning fixar det. Att byta VPN:ens utgångsland återställer inte platsens lokala åtkomsttillstånd; den tabellen är knuten till din enhet, inte till servern du väljer. Fråga platsens operatör och ge dem tid, för det är sessionstabellen de kommer att titta på.

Före nästa resa skriver du ned tre saker: portalsidan som steg noll, steget att pausa blockeringen för varje enhet du tar med, och en transportreserv du faktiskt testat. När en tunnel som fungerade för tio minuter sedan stannar igen behandlar du det som en utgången auktorisering och kontrollerar portalen på nytt innan du rör VPN-profilen.