Kvifor veit ei nettside framleis kva by du er i, sjølv med VPN
Ei nettside kan bruke posisjonstilgangen til nettlesaren og den offentlege IP-en din uavhengig av kvarandre: sjekk tilgangen for opphavet, OS-innstillinga og den lagra byen.
To mekanismar kan setje ein by på skjermen, og berre éin av dei bryr seg om kvar VPN-en din går ut. Geolocation API i nettlesaren returnerer ein einskildingsposisjon når sida har tilgang, og eit IP-oppslag anslår ein region frå adressa førespurnaden kom frå. Ei nettside som viser den verkelege byen din medan tunnelen køyrer i eit anna land, brukar vanlegvis den første mekanismen, eller les ein by ho lagra for månader sidan. Fem steg skil desse tilfella.
Første steg: avgjer kva mekanisme som kan svare
Byrja med å spørje kva sida i det heile kan vite. Ein einskildingsposisjon krev eit API-kall og ei tilgangsavgjerd, og han gjev ein presis koordinat. Eit IP-anslag krev ingenting av brukaren og gjev i beste fall ein by, ofte ein feil. Ei lagra kontoinnstilling krev ingen av delane og overlever kvar nettverksendring.
Desse tre kjeldene forklarer nesten kvar rapport. Ei kartside som sentrerer på gata di, brukar API-et. Ein butikk som helsar deg på feil språk, brukar eit IP-anslag. Ei nyhendeside som framleis viser heimbyen din etter ei flytting, brukar det kontoen din har lagra.
| 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 steg: les tilgangen for nøyaktig det opphavet
Nettlesarar hugsar tilgangsavgjerda per opphav, så ei nettside du tillét i fjor, opnar utan ei ny førespurnad. Sjå gjennom posisjonsoppføringa for nøyaktig den nettsida i nettstadinnstillingane til nettlesaren i staden for den globale standarden, fordi den globale innstillinga berre avgjer kva som skjer når ingenting er lagra.
Sjekk deretter operativsystemet. Ein nettlesar på ein moderne datamaskin eller telefon treng òg posisjonstilgangen til plattforma, og ein avslått plattformtilgang får API-et til å feile sjølv når nettsida er tillaten. Posisjonen som er tilgjengeleg, kan kome frå tenestene til plattforma, som ikkje har noko med tunnelen å gjere.
To tekniske vilkår forklarer dei fleste feila som ser ut som VPN-problem. API-et krev ein trygg kontekst, så ei vanleg HTTP-side kan ikkje bruke det i det heile, og innebygde rammer kan blokkerast av Permissions Policy til sida. Ei avslått førespurnad er difor langt oftare eit resultat av nettlesaren eller policyen til sida enn av nettverket.
Tredje steg: stadfest utgangsadressa med ei ny førespurnad
Spør ein uavhengig teneste kva adresse ho ser, frå den same nettlesaren du testar. Ei utdatert fane, ein service worker eller ei bufra side kan rapportere gårsdagens svar, og å samanlikne eit ferskt svar med det nettsida viser, fjernar den tvilen.
curl -s https://ifconfig.me
curl -s https://ipinfo.io/jsonKøyr dei frå maskinen, ikkje frå rutaren, og noter adressa og landet kvar av dei returnerer. Viss båe rapporterer VPN-landet og nettsida framleis viser heimbyen din, er ikkje utgangen kjelda, og dei attverande kandidatane er tilgang, lagra data og ein lekkasjeveg.
Lekkasjevegar er den tredje moglegheita: ei nettlesarutviding med sin eigen nettverksstakk, ei split-tunnel-rute som sender nettsida utanfor tunnelen, eller ein IPv6-veg som tunnelen ikkje ber. Kvar av dei er synleg i sjølve førespurnaden, difor kjem utgangssjekken før kvar innstillingendring. Ei utviding med eigne proxy-innstillingar er den folk overser, fordi ho kan omgå tunnelen for éi einskild fane.
Fjerde steg: sjå kva kontoen allereie har lagra
Attkalling av tilgang påverkar framtidig åtgang etter reglane til nettlesaren og slettar ikkje ein posisjon tenesta allereie har lagra. Ein lagra heimby, ei leveringsadresse eller ein profilregion blir ståande til bruksprogrammet oppdaterer han, og nettsida kan framleis gjere eit omtrentleg anslag frå utgangsadressa.
Sjå etter den eigne posisjonsstyringa til nettsida før du konkluderer med at nettlesaren er skulda. Mange bruksprogram har ein manuell regionveljar som overstyrer kvart automatisk anslag, og ein støttemedarbeidar som les kontooppføringa, ser den verdien i staden for den noverande tilkoplinga di.
Der den lagra verdien betyr noko, endre han på kontoen og noter datoen. Det gjev deg eit andre datapunkt når den gamle byen dukkar opp att. Eit skjermbilete av kontosida før endringa er verdt meir enn ei skildring av ho etterpå.
Femte steg: endre éin variabel om gongen
Test i ein fast rekkjefølgje: fersk utgangssjekk, opphavstilgang, plattformtilgang, kontoinnstilling, deretter ein annan nettlesarprofil. Endrar du fleire ting samstundes, blir kjelda uidentifiserbar, og det er slik eit svar på fem minutt blir ei veke med gissing.
Noter kva du endra og kva sida viste etterpå. Viss visinga berre endrar seg i eit privat vindauge, er årsaka lagra tilstand; viss ho aldri endrar seg, brukar sida eit IP-anslag eller ein kontoverdi nettlesaren ikkje kan påverke. Hald før og etter i same notatet, fordi mønsteret er provet.
Ver ærleg i konklusjonen: ein VPN endrar adressa ein førespurnad kjem frå, og Geolocation API er ein eigen kanal med tilgang som tunnelen ikkje rører. Båe fakta kan vere sanne samstundes, og dei fleste forvirrande rapportane kjem av å handsame dei som alternativ.