Hvorfor et nettsted fortsatt vet hvilken by du er i, selv med VPN
Et nettsted kan bruke nettleserens posisjonstillatelse og din offentlige IP uavhengig av hverandre: sjekk tillatelsen for opprinnelsen, OS-innstillingen og den lagrede byen.
To mekanismer kan sette en by på skjermen, og bare én av dem bryr seg om hvor VPN-en din går ut. Nettleserens Geolocation API returnerer en enhetsposisjon når siden har tillatelse, og et IP-oppslag anslår en region fra adressen forespørselen kom fra. Et nettsted som viser den virkelige byen din mens tunnelen kjører i et annet land, bruker vanligvis den første mekanismen, eller leser en by det lagret for måneder siden. Fem trinn skiller disse tilfellene.
Første trinn: avgjør hvilken mekanisme som kan svare
Begynn med å spørre hva siden i det hele tatt kan vite. En enhetsposisjon krever et API-kall og en tillatelsesbeslutning, og den gir en presis koordinat. Et IP-anslag krever ingenting av brukeren og gir i beste fall en by, ofte en feil. En lagret kontoinnstilling krever ingen av delene og overlever hver nettverksendring.
Disse tre kildene forklarer nesten hver rapport. Et kartnettsted som sentrerer på gaten din, bruker API-et. En butikk som hilser deg på feil språk, bruker et IP-anslag. Et nyhetsnettsted som fortsatt viser hjembyen din etter en flytting, bruker det kontoen din har lagret.
| What the page shows | Likely source |
|---|---|
| Street-level accuracy | Device position from the Geolocation API |
| City or region only | IP geolocation of the exit address |
| Same city for months | Stored account preference |
| Different result in a private window | Stored permission or cached state |
Andre trinn: les tillatelsen for nøyaktig den opprinnelsen
Nettlesere husker tillatelsesbeslutningen per opprinnelse, så et nettsted du tillot i fjor, åpnes uten en ny forespørsel. Se gjennom posisjonsoppføringen for akkurat det nettstedet i nettleserens nettstedinnstillinger i stedet for den globale standarden, fordi den globale innstillingen bare avgjør hva som skjer når ingenting er lagret.
Sjekk deretter operativsystemet. En nettleser på en moderne datamaskin eller telefon trenger også plattformens posisjonstillatelse, og en avslått plattformtillatelse får API-et til å feile selv når nettstedet er tillatt. Posisjonen som er tilgjengelig, kan komme fra plattformens tjenester, som ikke har noe med tunnelen å gjøre.
To tekniske betingelser forklarer de fleste feilene som ser ut som VPN-problemer. API-et krever en sikker kontekst, så en vanlig HTTP-side kan ikke bruke det i det hele tatt, og innebygde rammer kan blokkeres av sidens Permissions Policy. En avslått forespørsel er derfor langt oftere et resultat av nettleseren eller sidens policy enn av nettverket.
Tredje trinn: bekreft utgangsadressen med en ny forespørsel
Spør en uavhengig tjeneste hvilken adresse den ser, fra den samme nettleseren du tester. En utdatert fane, en service worker eller en bufret side kan rapportere gårsdagens svar, og å sammenligne et ferskt svar med det nettstedet viser, fjerner den tvilen.
curl -s https://ifconfig.me
curl -s https://ipinfo.io/jsonKjør dem fra maskinen, ikke fra ruteren, og noter adressen og landet hver av dem returnerer. Hvis begge rapporterer VPN-landet og nettstedet fortsatt viser hjembyen din, er ikke utgangen kilden, og de gjenværende kandidatene er tillatelse, lagrede data og en lekkasjevei.
Lekkasjeveier er den tredje muligheten: en nettleserutvidelse med sin egen nettverksstakk, en split-tunnel-rute som sender nettstedet utenfor tunnelen, eller en IPv6-vei som tunnelen ikke bærer. Hver av dem er synlig i selve forespørselen, derfor kommer utgangssjekken før enhver innstillingsendring. En utvidelse med egne proxy-innstillinger er den folk overser, fordi den kan omgå tunnelen for én enkelt fane.
Fjerde trinn: se hva kontoen allerede har lagret
Tilbakekalling av tillatelse påvirker fremtidig tilgang etter nettleserens regler og sletter ikke en posisjon tjenesten allerede har lagret. En lagret hjemby, en leveringsadresse eller en profilregion blir stående til applikasjonen oppdaterer den, og nettstedet kan fortsatt gjøre et omtrentlig anslag fra utgangsadressen.
Se etter nettstedets egen posisjonskontroll før du konkluderer med at nettleseren er skylden. Mange applikasjoner har en manuell regionsvelger som overstyrer hvert automatisk anslag, og en supportmedarbeider som leser kontooppføringen, ser den verdien i stedet for den nåværende tilkoblingen din.
Der den lagrede verdien betyr noe, endre den på kontoen og noter datoen. Det gir deg et andre datapunkt når den gamle byen dukker opp igjen. Et skjermbilde av kontosiden før endringen er verdt mer enn en beskrivelse av den etterpå.
Femte trinn: endre én variabel om gangen
Test i en fast rekkefølge: fersk utgangssjekk, opprinnelsestillatelse, plattformtillatelse, kontoinnstilling, deretter en annen nettleserprofil. Endrer du flere ting samtidig, blir kilden uidentifiserbar, og det er slik et svar på fem minutter blir en uke med gjetting.
Noter hva du endret og hva siden viste etterpå. Hvis visningen bare endres i et privat vindu, er årsaken lagret tilstand; hvis den aldri endres, bruker siden et IP-anslag eller en kontoverdi nettleseren ikke kan påvirke. Hold før og etter i samme notat, fordi mønsteret er beviset.
Vær ærlig i konklusjonen: en VPN endrer adressen en forespørsel kommer fra, og Geolocation API er en egen kanal med tillatelse som tunnelen ikke berører. Begge fakta kan være sanne samtidig, og de fleste forvirrende rapportene kommer av å behandle dem som alternativer.