Offentligt Wi-Fi för en enda enhet: varför en VPN-utgång inte kan hjälpa

Den bärbara visar Ansluten, handskakningen lyckas, och portalen vägrar ändå ladda en sida på en andra enhet. Det är inte ett tunnelproblem. En hotspots enhetsgräns hör till dess åtkomstsystem, som räknar de enheter det har auktoriserat och de sessioner det har släppt. En VPN ändrar var trafiken går ut efter auktoriseringen och ändrar ingenting i hur många enheter det systemet släpper in.

Vad portalen egentligen räknar

Captive-portaler spårar ett auktoriseringsbeviljande, och beviljandet är vanligtvis knutet till något nätverket kan identifiera. En MAC-adress är det vanliga valet, en sessionskaka i webbläsaren ett annat, och vissa system kombinerar endera med ett rumsnummer eller en tryckt biljett. Fyra enheter på en rums kod betyder fyra beviljanden, och en femte enhet har inget, vilken programvara den än kör. Att installera en VPN på den femte enheten ändrar svaret från nekad till nekad.

Anslutning och auktorisering är åtskilda tillstånd. En bärbar kan ansluta till åtkomstpunkten, hålla en DHCP-lease och ändå sakna internet, eftersom portalen aldrig gav den något. Att läsa Wi-Fi-ikonen som bevis på portalens framgång är det första felet i hela den här klassen av ärenden.

Bekräfta regeln hos platsen

Ställ två frågor i stället för att gissa: hur många enheter kontot tillåter, och hur en inaktuell session släpps. Det andra är viktigare, eftersom ett beviljande som en enhet som rest lämnar efter sig oftast är det som blockerar nästa. Receptionen kan ofta släppa det eller utfärda en ny kod snabbare än någon lösning på klientsidan. Använd den rutinen innan du ändrar maskinvaruadresser, eftersom kopiering av en annan enhets identifierare bryter mot nätverkets villkor och sätter en dubbel identitet på segmentet.

Beteendet varierar mellan operatörer. Vissa system binder till ett enhetsfingeravtryck, andra till en webbläsarsession, och några få tillåter ett fast antal samtidiga beviljanden som löper ut på en timer. En plats policy förutsäger ingenting om nästa, därför slår platsens svar varje allmän regel.

Håll portal- och VPN-inloggningar åtskilda

En rumskod är inte en gateway-inloggning, och att återanvända en arbetsinloggning i en portal är en dålig affär även när båda skärmarna visar ett användarnamnsfält och ett lösenordsfält. Auktorisera den avsedda enheten först, verifiera en liten vanlig begäran där platsen tillåter det, och anslut tunneln först därefter. Den ordningen ger dig en ren tilldelning när något misslyckas, eftersom portalsteget redan var bevisat innan VPN:en kom in i bilden.

När portalen nekar är tunneln fel plats att felsöka på. Ingenting i VPN-konfigurationen kan ge åtkomst som åtkomstsystemet aldrig utfärdade.

Vad en rese-router ändrar

En rese-router kan hjälpa genom att uppträda som en enhet uppströms medan den betjänar flera lokalt, och den ändrar vad portalen ser. Auktoriseringen binder till routerns identifierare i stället för till varje bärbar, och varje klient bakom den delar ett beviljande och en offentlig adress. Om den ordningen är acceptabel beror på nätverkets villkor, och många platser förbjuder delning uttryckligen. En router är en legitim design där delning är tillåten och en överträdelse där den inte är det, oavsett det tekniska värdet.

Inget av detta tar bort gränsen. Det flyttar det enda beviljandet från en bärbar till en router, vilket är användbart för en resenär med flera enheter och värdelöst för två personer som var och en behöver sin egen auktorisering.

Lös det lokala auktoriseringsproblemet först. En tunnel som fungerar perfekt kan ändå inte tillverka ett beviljande som åtkomstsystemet aldrig utfärdade.