Blockerar webbplatsen dig bara med VPN på? Det här ser den
Blocket är oftast utgångsadressen, inte ett läckage. Kontrollera nätverket som trafiken verkar komma från, resolvern en webbplats kan logga och vad sidkoden vet.
Butiken laddar fint hemma och visar en mur av ”ovanlig trafik” i samma stund som tunneln är uppe. Ett forum vägrar logga in dig, och en streamingsida hävdar att du är i ett land du aldrig besökt. Inget av det kräver spionprogram. En webbplats ser adressen som dina paket kommer från, och med ett VPN tillhör den adressen ett datacenter i stället för en hemmaanslutning. Det mesta som kallas VPN-detektering börjar och slutar med det enda faktumet, och resten är slutsatser med en förutsägbar felkvot.
Blocket börjar med varifrån dina paket verkar komma
Varje begäran bär en källadress, och servern som tar emot den kan slå upp den i offentliga data: vilket nätverk som annonserar den, om nätverket är en hostingleverantör, om det förekommit på missbrukslistor och vilket land registret tilldelar. Inget av det identifierar dig, och allt tillsammans räcker för att placera dig i ett fack.
Titta på din egen trafik som en främling skulle göra. Två kommandon täcker större delen av ytan, och det andra är det folk glömmer:
curl -sS https://ipinfo.io/json
dig +short TXT o-o.myaddr.l.google.com @ns1.google.com
Det första returnerar utgångsadressen, dess organisation och land. Det andra returnerar adressen till resolvern som nådde Googles namnserver; den tillhör ofta ett annat nätverk än din utgång, och det är adressen en webbplats ser om den loggar data på resolver-sidan. När dessa två tillhör olika länder betraktar vissa webbplatser avvikelsen som misstänkt, även om det inte är något fel på din konfiguration.
När avvisningen först börjar efter att tunneln är uppe, misstänk utgångsadressen före allt annat. Byt server och försök igen innan du rör webbläsaren. Ett block som följer dig genom tre utgångar från samma leverantör handlar om leverantörens intervall; ett block som försvinner på en annan server handlar om den enda adressen.
Tidszon, språk och klocka stämmer inte med adressen
Sidkoden kan läsa din tidszon, dina språkpreferenser och dina skärminställningar utan någon behörighetsfråga. En webbläsare som rapporterar centraleuropeisk tid medan anslutningen kommer från ett datacenter i Singapore är en starkare signal än adressen ensam, och det är precis den typen av avvikelse som bedrägeripoäng byggts för att märka.
Intl.DateTimeFormat().resolvedOptions().timeZone
navigator.language
Intl.DateTimeFormat().resolvedOptions().locale
De tre raderna i utvecklarkonsolen berättar vad din webbläsare ger frivilligt. En VPN-klient kan ändra din rutt och inget annat, så profilen du bär med dig förblir inhemsk medan din utgång inte är det. Konsekvens är vad som spelar roll här: en bärbar dator inställd på samma region som utgången ser vanlig ut, och en som säger emot sig själv gör det inte.
Det är också därför felet är intermittent. Många webbplatser bryr sig inte, några få poängsätter det, och en medlemssajt beslutar att du är en bedragare. Klienten fungerar korrekt i alla tre fallen, och därför är det vanliga supportssvaret, ”det måste vara din webbläsare”, både irriterande och delvis sant.
Vad sidkoden faktiskt vet om din maskin
JavaScript har inget API som räknar upp nätverksgränssnitt. En sida kan inte fråga vilka adresser din bärbara dator har, så det gamla påståendet att ett skript läser din LAN-adress är mest ett minne från plugineran, när ActiveX-kontroller, Java-applets och annan inbyggd kod kunde göra just det.
| Signal | What it reveals | Status today |
|---|---|---|
| Source address of the request | Exit network, country, hosting status | Always visible; the main signal |
| Time zone and language | Where the profile claims to be | Readable without permission |
| WebRTC candidates | Local addresses, historically | Host candidates are mDNS-obfuscated by default |
| Interface list | All local addresses | Not available to ordinary JavaScript |
WebRTC är det ärliga undantaget från ”inga lokala adressläckor”. Dess kandidatinsamling exponerade en gång lokala adresser för varje sida som frågade, och rättelsen var att ersätta värdkandidater med slumpmässiga mDNS-namn. Den standarden gäller i nuvarande webbläsare, men det är ett webbläsarbeslut och inte en protokollgaranti, så en föråldrad version eller en härdad konfiguration som återaktiverar lokala kandidater kan fortfarande läcka. Att uppdatera webbläsaren hjälper dig mer här än något tillägg.
Din leverantör ser namnen, inte innehållet
HTTPS skyddar innehållet på en sida från ände till ände, och tunneloperatören som vidarebefordrar dessa byte kan inte läsa dem. Operatören kan fortfarande se vilken adress du kontaktade, och i de flesta distributioner servernamnet i handskakningen, eftersom namnet måste vara läsbart för att anslutningen ska dirigeras till rätt webbplats. Encrypted Client Hello finns just för att dölja det fältet, och det hjälper bara när både klienten och webbplatsen stöder det.
Namnuppslagning är den andra halvan. Om din leverantör också tillhandahåller resolvern ser den varje namn du slår upp innan någon anslutning finns. Om din enhet använder en offentlig resolver över HTTPS ser leverantören en anslutning till den resolvern och inget annat, medan resolvern själv ser listan.
En okrypterad HTTP-begäran är läsbar för operatören av samma skäl som den är läsbar för hotellnätet: inget i den är krypterat. En tunnel har aldrig påstått något annat, och den reparerar inte applikationens val.
Skilj på ”det här är ett VPN” och ”det här är jag”
Detektering är billig, probabilistisk och ofta fel. Delade utgångsadresser flaggas eftersom någon annan missbrukat dem, företagsintervall klassas som hosting, och mobiloperatörer producerar geografiska resultat som överraskar alla. Identifiering är ett annat problem: det kräver en bestående koppling som ett konto du loggat in på, en cookie, en betalningsuppgift eller två observatörer som jämför anteckningar.
Bestäm vilken av dem du faktiskt kämpar mot. Om målet är att läsa en sida gör HTTPS redan det jobbet, och tunneln ändrar lite. Om målet är att hindra webbplatsen från att veta vilken stad du är i, är utgången och resolvern det som spelar roll. Om målet är att bryta kopplingen till din riktiga identitet är kontot den svaga punkten, och att byta servrar gör ingenting åt inloggningen du just använde.
En ny utgång loggar inte ut dig från något, och den kan inte radera det en webbplats redan sparat om kontot du använde. Den praktiska ordningen är därför oglamorös: välj en utgång vars nätverk ser vanligt ut, håll webbläsarprofilen konsekvent med den, uppdatera webbläsaren så att läckagebenägna funktioner använder sina moderna standardvärden, och acceptera att ett litet antal webbplatser fortfarande kommer att gissa fel om dig.