Waarom die vasgevangde portaal jou VPN afsluit, en hoe om weer aan te meld

Op 'n oop netwerk gee jou toegangspunt nie sommer pakkies aan die internet oor nie. 'n Opstroom-beleidspunt kyk of jou toestel al gemagtig is, en tot dit is, word byna alles laat vaar. Jou VPN-kliënt lees daardie stilte as 'n dooie bediener. Dit sê dit selde: WireGuard probeer 'n handdruk in 'n leemte herhaal, OpenVPN rapporteer 'n verbindingstydsverloop, en IKEv2 kom terug as fout 809 oor 'n afgeleë bediener wat nie reageer nie.

Wat die portaal werklik beheer

'n Vasgevangde portaal is twee dinge wat aan mekaar vasgeheg is: 'n beleidsbeslissingspunt en 'n herverwyser. Wanneer jou toestel assosieer en 'n DHCP-huurkontrak kry, plaas die netwerk jou in 'n toestand voor magtiging.

Daardie toestand is 'n stel firewall-reëls. Dit laat gewoonlik DNS toe en laat HTTP of HTTPS na 'n kort lys portaalhosts toe, en dit verwerp alles anders. Die toegelate lys is die ommuurde tuin, en dit sluit byna nooit 'n VPN-eindpunt in nie.

Nie een van die weglatings is hoflik nie. Pakkies wat op 'n VPN-bediener gemik is, word weggegooi eerder as geweier, so die kliënt kry geen ICMP unreachable en geen TCP reset nie, net die afwesigheid van 'n antwoord. Afhangend van die verskaffer kan die herverwyser poort 80 antwoord met 'n herverwysing na die aanmeldbladsy terwyl poort 443 weggegooi of onderskep word. Herverwysings is maklik om raak te sien omdat hulle 'n gewone HTTP-antwoord dra; onderskepping op 443 vereis 'n sertifikaat wat jou blaaier sal weier om te vertrou.

Magtiging self is gewoonlik gekoppel aan die toestel se MAC-adres, soms aan die gehuurde IP, en dit leef in 'n sessietabel met 'n tydhouer. Aanmelding skep 'n inskrywing. Die firewall-reël wat jou verkeer deurlaat, bestaan net solank daardie inskrywing bestaan, en dit is waarom die hele probleem later terugkeer sonder dat enigiets aan jou kant verander.

Waarom die VPN-handdruk sterf voordat dit begin

Elke protokol het sy eie vervoer, en die firewall voor magtiging breek elkeen anders. IKEv2 op Windows en iOS ry op UDP 500 en UDP 4500; 'n weglating op daardie poorte verskyn as 809, of as 'n naamoplossing-agtige fout op kliënte wat fases afsonderlik rapporteer. OpenVPN oor UDP 1194 bly in die verbindingstoestand totdat sy tydsverloop verstryk. OpenVPN oor TCP 443 is die interessante geval, want die portaal kan die TCP-handdruk voltooi en dan met sy herverwysingsbladsy antwoord, so jy sien 'n TLS-fout eerder as 'n tydsverloop.

WireGuard wys die meganisme die duidelikste. Dit is ontwerp as slegs UDP, sonder TCP-terugval, so 'n firewall wat onbekende UDP weggooi, verwyder die vervoer heeltemal. Die kliënt hou aan om handdruk-inisiasies te stuur met toenemende terugtreding en rapporteer 'n handdruk wat nooit voltooi nie. Niks in daardie boodskap noem Wi-Fi nie, en niks daarin stel voor dat jy 'n blaaier moet oopmaak nie.

Platforms probeer die toestand raaksien voordat jou VPN dit doen. Windows haal 'n bekende URL om te besluit of dit sy aanmeldkennisgewing moet wys, Android versoek 'n eindpunt wat 204 No Content behoort te antwoord, en Apple-toestelle maak 'n klein vasgevangde-netwerkvenster oop. Daardie ondersoeke werk omdat die portaal met 'n herverwysing antwoord in plaas van die verwagte liggaam. Dieselfde gedrag verduidelik hoe 'n portaal heeltemal gesond kan lyk terwyl jou tonnel dood is: die ondersoek en die tonnel word deur verskillende reëls beoordeel.

Wat 'n sessieverval werklik terugstel

Plekke laat sessies verval om redes wat nie met jou VPN-rekening verband hou nie: 'n ledige tydsverloop, 'n maksimum sessielengte, 'n nuwe DHCP-huurkontrak, of 'n herassosiasie met 'n ander toegangspunt. Wanneer die tydhouer afgaan, verdwyn die sessietabel-inskrywing en kom die reëlstel voor magtiging presies terug soos dit by die inklok was.

'n Gevestigde tonnel oorleef dikwels lank genoeg om gesond te lyk. Hou-in-lewe-boodskappe hou aan uitgaan, en of die kliënt dit raaksien, hang af van hoe hy onbeantwoorde verkeer hanteer, so die statuslig kan vir 'n rukkie groen bly nadat die pad weg is. Dan val die tonnel weg en elke herverbindingspoging misluk op dieselfde geblokkeerde poorte.

Op daardie punt vertel die kliëntfout jou in watter fase jy is, as jy dit aandagtig lees:

Een detail vang mense: wanneer die sessie aan 'n MAC-adres gebind is, help dit dalk nie om die aanmeldbladsy te herlaai nie. Jy moet die assosiasie laat vaar en weer aansluit sodat die portaal 'n nuwe magtigingspoging sien in plaas van 'n vervalde een.

Meld eers aan, lig dan die tonnel

Die volgorde wat werk is: magtig die toestel, bewys die pad, begin die VPN, bewys die tonnel en herstel dan jou normale blokkering. Daardie laaste stap is belangrik omdat die tydelike toestand wat jy nodig het om die portaal te bereik, presies die toestand is wat 'n doodskakelaar bestaan om te verhoed.

'n Lessenaarkliënt met 'n blok-buite-die-tonnel-opsie moet onderbreek word sodat die portaalbladsy kan laai, en jy moet sensitiewe programme gesluit hou gedurende daardie buite-die-tonnel-venster; dit is die enigste interval wanneer plaaslike verkeer onbeskermd vertrek. 'n Bestuurde altyd-aan-toestel moet die prosedure gebruik wat sy eienaar gepubliseer het eerder as dat jy beleid verwyder. As die portaal 'n sertifikaatwaarskuwing wys, stop: om dit te aanvaar, lei jou sessie deur die plek se onderskeppingsproksie, en daardie proksie kan alles lees wat jy stuur. Op Android blokkeer die grendel onder altyd-aan-VPN verkeer voordat die tonnel op is, en sommige bouwe kan nie die portaalvloei vrystel nie; as joune nie kan nie, gebruik die plek se alternatiewe toegang of 'n ander toestel eerder as om die grendel af te laat. Apple se op-aanvraag-reëls kan geskryf word om die tonnel te weier totdat 'n ondersoek slaag, wat die gedrag is wat jy op hotelnetwerke wil hê.

Verifieer in volgorde met gereedskap wat jy reeds het. Voor die tonnel, hardloop die ondersoek met die opkoppe en die liggaam albei sigbaar, en kyk of jou VPN-vervoer enige antwoord kry:

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'

Voor magtiging gee 'n normale portaal een van twee antwoorde: 'n 302 waarvan die Location na die aanmeldbladsy wys, of 'n 200 met 'n HTML-liggaam wat die portaalbladsy is. Teken aan watter een jy gekry het. 'n Herverwysing is nie 'n mislukking voor aanmelding nie; dit is die portaal wat jou vertel waar om heen te gaan. Nadat die portaal sukses rapporteer, herhaal die opdrag en verwag 'n 200 waarvan die liggaam die letterlike woord Success is. Daardie string is wat die ondersoek betekenisvol maak. As die gasheer normaal antwoord voordat jy ooit aangemeld het, is daar geen onderskeppende portaal op hierdie netwerk nie. In die opname is 'n weglating voor magtiging uitgaande pakkies met niks wat terugkom, terwyl 'n pad wat werk 'n antwoord op dieselfde vloei binne omtrent 'n sekonde wys. Verbind, en herhaal dan die opname.

As die tonnel steeds misluk nadat die portaal ja sê

Aanmeldingsukses is nie dieselfde as toegelate vervoer nie. Baie plekke laat die portaal en gewone blaai toe terwyl hulle UDP heeltemal blokkeer, wat WireGuard en UDP-OpenVPN stukkend laat en TCP 443 laat werk. As TCP 443 deurgaan en UDP nie, is dit die plek se beleid eerder as 'n kliënt wat jy verkeerd opgestel het, so skakel oor na 'n ander vervoer of aanvaar die beperking en gaan aan. As 'n herverbinding daarna steeds misluk, hou die presiese fout; dit noem die fase waarin jy vas is.

Ander mislukkings woon op die toestel. 'n Sessie wat steeds aan 'n ou MAC gebind is, 'n tweede Wi-Fi-adapter met sy eie huurkontrak, of 'n kliënt wat die portaal se sertifikaat-uitsondering gekas het, kan elkeen aanhou misluk ná 'n skoon hermagtiging. Laat vaar die assosiasie, magtig weer, en probeer een keer voordat jy aan kliëntinstellings raak. RFC 8952 is die lees werd as jy die argitektuur agter die komponente wat jy dophou, wil hê.

As die portaal self weier om te magtig, is die probleem rekening- of toesteltoekenning en geen VPN-instelling sal dit regmaak nie. Om die VPN se uitgangsland te verander, stel nie die plek se plaaslike toegangstoestand terug nie; daardie tabel is aan jou toestel gekoppel, nie aan die bediener wat jy kies nie. Vra die plek se operateur en gee hulle die tyd, want die sessietabel is waarna hulle sal kyk.

Voor jou volgende reis, skryf drie dinge neer: die portaalbladsy as stap nul, die onderbreek-blokkering-stap vir elke toestel wat jy saamdra, en een vervoer-terugval wat jy werklik getoets het. Wanneer 'n tonnel wat tien minute gelede gewerk het, weer stop, hanteer dit as vervalde magtiging en herkontroleer die portaal voordat jy aan die VPN-profiel raak.