Blokkerer nettstedet deg bare med VPN på? Dette er hva det ser
Blokkeringen er vanligvis utgangsadressen, ikke en lekkasje. Sjekk nettverket trafikken din ser ut til å komme fra, resolveren et nettsted kan logge, og hva sidekoden vet.
Butikken lastes fint hjemme og viser en mur av «uvanlig trafikk» i det øyeblikket tunnelen er oppe. Et forum nekter å logge deg inn, og en strømmeside insisterer på at du er i et land du aldri har besøkt. Ingenting av dette krever spyware. Et nettsted ser adressen pakkene dine kommer fra, og med VPN tilhører den adressen et datasenter i stedet for en hjemmelinje. Det meste av det som kalles VPN-deteksjon begynner og slutter med den ene kjensgjerningen, og resten er slutninger med en forutsigbar feilrate.
Blokkeringen begynner med hvor pakkene dine ser ut til å komme fra
Hver forespørsel bærer en kildeadresse, og serveren som mottar den kan slå den opp i offentlige data: hvilket nettverk som annonserer den, om nettverket er en hostingleverandør, om det har stått på misbrukslister, og hvilket land registreret tildeler. Ingenting av dette identifiserer deg, og alt sammen er nok til å plassere deg i en bås.
Se på din egen trafikk slik en fremmed ville gjort. To kommandoer dekker det meste av overflaten, og den andre er den folk glemmer:
curl -sS https://ipinfo.io/json
dig +short TXT o-o.myaddr.l.google.com @ns1.google.comDen første returnerer utgangsadressen, organisasjonen og landet. Den andre returnerer adressen til resolveren som nådde navnetjeneren til Google; den tilhører ofte et annet nettverk enn utgangen din, og det er adressen et nettsted ser hvis det logger data på resolver-siden. Når disse to tilhører forskjellige land, anser noen nettsteder avviket som mistenkelig, selv om det ikke er noe galt med oppsettet ditt.
Når avvisningen først begynner etter at tunnelen er oppe, mistenker du utgangsadressen før noe annet. Bytt server og prøv igjen før du rører nettleseren. En blokkering som følger deg gjennom tre utganger fra samme leverandør handler om leverandørens områder; en blokkering som forsvinner på en annen server handler om den ene adressen.
Tidssone, språk og klokke stemmer ikke med adressen
Sidekoden kan lese tidssonen din, språkpreferansene dine og skjerminnstillingene uten noen tillatelsesforespørsel. En nettleser som rapporterer sentraleuropeisk tid mens forbindelsen kommer fra et datasenter i Singapore, er et sterkere signal enn adressen alene, og det er nettopp den typen avvik svindelscoring er bygget for å legge merke til.
Intl.DateTimeFormat().resolvedOptions().timeZone
navigator.language
Intl.DateTimeFormat().resolvedOptions().localeDe tre linjene i utviklerkonsollen forteller hva nettleseren din gir frivillig. En VPN-klient kan endre ruten din og ingenting annet, så profilen du bærer med deg forblir innenlandsk mens utgangen din ikke er det. Konsistens er det som betyr noe her: en bærbar datamaskin satt til samme region som utgangen ser vanlig ut, og en som er uenig med seg selv gjør det ikke.
Det er også derfor feilen er periodisk. Mange nettsteder bryr seg ikke, noen få scorer det, og ett medlemsside bestemmer at du er en svindler. Klienten fungerer riktig i alle tre tilfellene, og derfor er det vanlige støttesvaret, «det må være nettleseren din», både irriterende og delvis sant.
Hva sidekoden faktisk vet om maskinen din
JavaScript har ingen API som lister opp nettverksgrensesnitt. En side kan ikke spørre hvilke adresser den bærbare datamaskinen din har, så den gamle påstanden om at et skript leser LAN-adressen din, er mest et minne fra programtilleggsæraen, da ActiveX-kontroller, Java-applets og annen opprinnelig kode kunne gjøre nettopp 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 er det ærlige unntaket fra «ingen lokale adresselekkasjer». Kandidatinnsamlingen eksponerte en gang lokale adresser til enhver side som spurte, og rettelsen var å erstatte vertskandidater med tilfeldige mDNS-navn. Den standarden gjelder i dagens nettlesere, men det er en nettleserbeslutning og ikke en protokollgaranti, så en utdatert versjon eller en herdet konfigurasjon som aktiverer lokale kandidater på nytt, kan fortsatt lekke. Å oppdatere nettleseren hjelper deg mer her enn noen utvidelse.
Leverandøren din ser navnene, ikke innholdet
HTTPS beskytter innholdet på en side ende til ende, og tunneloperatøren som videresender disse bytene, kan ikke lese dem. Operatøren kan fortsatt se hvilken adresse du kontaktet, og i de fleste distribusjoner servernavnet i håndtrykket, fordi navnet må være lesbart for at forbindelsen skal rutes til riktig nettsted. Encrypted Client Hello finnes nettopp for å skjule det feltet, og det hjelper bare når både klienten og nettstedet støtter det.
Navneoppslag er den andre halvdelen. Hvis leverandøren din også leverer resolveren, ser den hvert navn du slår opp før noen forbindelse finnes. Hvis enheten din bruker en offentlig resolver over HTTPS, ser leverandøren en forbindelse til den resolveren og ingenting annet, mens resolveren selv ser listen.
En ukryptert HTTP-forespørsel er lesbar for operatøren av samme grunn som den er lesbar for hotellnettet: ingenting i den er kryptert. En tunnel har aldri påstått noe annet, og den reparerer ikke applikasjonens valg.
Skill «dette er en VPN» fra «dette er meg»
Deteksjon er billig, sannsynlighetsbasert og ofte feil. Delte utgangsadresser flagges fordi noen andre misbrukte dem, bedriftsområder klassifiseres som hosting, og mobiloperatører produserer geografiske resultater som overrasker alle. Identifikasjon er et annet problem: det krever en vedvarende kobling som en konto du har logget på, en informasjonskapsel, en betalingsdetalj eller to observatører som sammenligner notater.
Bestem deg for hvilken av dem du faktisk kjemper mot. Hvis målet er å lese en side, gjør HTTPS allerede den jobben, og tunnelen endrer lite. Hvis målet er å hindre nettstedet i å vite hvilken by du er i, er utgangen og resolveren det som betyr noe. Hvis målet er å bryte koblingen til din virkelige identitet, er kontoen det svake punktet, og det å bytte servere gjør ingenting med påloggingen du nettopp brukte.
En ny utgang logger deg ikke ut av noe, og den kan ikke slette det et nettsted allerede har lagret om kontoen du brukte. Den praktiske rekkefølgen er derfor uglamorøs: velg en utgang der nettverket ser vanlig ut, hold nettleserprofilen konsistent med den, oppdater nettleseren slik at lekkasjeutsatte funksjoner bruker sine moderne standardverdier, og aksepter at et lite antall nettsteder fortsatt vil gjette feil om deg.