Testa en hotspot innan arbetsinloggningar kommer i närheten
En portal fångar DNS och omdirigerar HTTP innan den auktoriserar något. Gör en färsk HTTPS-kontroll, testa sedan tunneln och håll arbetsinloggningar borta.
Hotspotten delar ut en adress innan den delar ut internet, och förtroendet avgörs i just den luckan. Enheten associerar, ber om en adress, och sedan fångas varje utgående begäran tills en portal säger att sessionen är auktoriserad. Mekanismen förklarar varför en sida kan se ut att laddas medan det inte finns någon riktig anslutning. Testa luckan med något ofarligt innan någon arbetsinloggning rör vid den.
Vad hotspotten gör med din första begäran
Associationen ger enheten en länk, och DHCP ger den en adress, en gateway och oftast en DNS-server som platsen äger. Tills auktoriseringen är klar släpper eller omdirigerar gatewayen utgående trafik, och många portaler svarar på DNS för varje namn med sin egen adress. Därför verkar en uppslagning lyckas: svaret är portalen, inte webbplatsen du bad om. Nätverket beter sig som konstruerat; det är bara inte internet ännu.
Den första HTTP-begäran får vanligtvis en omdirigering till portalen, som operativsystemet kan öppna åt dig. HTTPS kan inte omdirigeras så, så det misslyckas eller hänger, och webbläsaren visar ett certifikatfel eller en tidsgräns. Skillnaden är diagnostisk: en HTTP-omdirigering är portalen som talar, medan ett TLS-fel mot en orelaterad värd är något annat. En inmurad trädgård, där några få domäner släpps igenom för betalning eller inloggning, ger ett tredje mönster.
Bekräfta nätverket innan du loggar in
Bekräfta SSID och inloggningsmetod med platsen via en kanal som inte är nätverket självt. En portal som ber om ett företagslösenord, ett kortnummer och en e-postadress gör tre olika saker, och bara de två sista är vanliga för gäståtkomst. Föredra operativsystemets meddelande om captive portal, som upptäcker omdirigeringen via en känd slutpunkt i stället för att lita på vilken sida som helst som dyker upp. Om platsen inte kan beskriva sin egen portal är det skäl att vänta och inte att improvisera.
En certifikatvarning vid portalinloggning är inte ett steg man klickar sig förbi. Portalen behöver inte låtsas vara en orelaterad värd för att autentisera dig.
Gör den minsta kontroll som bevisar åtkomst
Slutför den legitima auktoriseringen, be sedan om en vanlig offentlig HTTPS-sida som du inte har laddat tidigare, så att svaret inte kan komma från cachen. Skriv ned vad som faktiskt misslyckades om det misslyckas: en namnsökning, en anslutningstidsgräns, ett certifikatfel eller en tjänstvägran. De fyra hör till olika lager, och att skriva ned dem hindrar nästa person att testa igen på känsla. Anslut sedan den avsedda VPN:en och be om en resurs som kräver den.
Håll testet litet. En hastighetstest-nedladdning på mätt åtkomst besvarar en fråga ingen ställde och kan kosta användaren pengar. Ett svar med rubriker räcker för att fastställa nåbarhet, och det drar inte megabyte genom en länk som faktureras per gigabyte.
Om vanlig åtkomst fungerar och tunneln inte, är det en annan undersökning än ett nätverk som aldrig auktoriserade. Håll de två resultaten åtskilda i stället för att ändra flera integritetsinställningar på en gång.
Håll privat arbete utanför jämförelsen
Varje app på enheten är en möjlig observatör, och en captive portal är ögonblicket då alla försöker nå sina servrar. Stäng dem du kan, och behandla en hanterad enhet som alltid är på som en policyfråga och inte en teknisk: använd den godkända metoden för jämförelsen i stället för att ta bort det skydd som gör den hanterad. Om enheten helt förbjuder trafik utanför tunneln, gör kontrollen på en annan, icke-känslig enhet. Poängen med övningen är att lära sig om nätverket utan att utsätta inloggningsuppgifter för det.
Fånga inte andras trafik för att diagnostisera platsen, och håll varje diagnostisk fångst inom din egen enhet och session. Granska adress- och identifierarfält innan du bifogar en fångst till ett ärende, eftersom platsens nätverk inte är ditt bevisskåp.
Bestäm vad resultatet tillåter dig att göra
Tre utfall är möjliga: full åtkomst med en fungerande tunnel, åtkomst bara till portalen med en misslyckad tunnel, eller ingen åtkomst alls. Varje har ett annat nästa steg, och värdet av testet är att veta vilket du är i innan du ändrar inställningar. Full åtkomst betyder att arbetet kan fortsätta genom tunneln; åtkomst bara till portalen tyder på att tunnelns port eller protokoll är blockerad, så ett annat transportlager eller nätverk är svaret; ingen åtkomst betyder att platsen inte kan stödja uppgiften i dag. En enhet som alltid bara prövar ett protokoll kan inte skilja dem.
Skriv ned SSID, utfallet och tiden, så att nästa person på samma plats börjar med bevis. Apples vägledning om captive-nätverk beskriver igenkänningsbeteendet bakom meddelandet, och det är den del som är värd att förstå innan du skyller på VPN:en.