Blokerer siden dig kun, når VPN'et er tændt? Her er, hvad den ser
Blokeringen er normalt udgangsadressen, ikke en lækage. Tjek netværket, som din trafik tilsyneladende kommer fra, resolveren et websted kan logge, og hvad sidekoden ved.
Butikken indlæses fint derhjemme og viser en mur af «usædvanlig trafik», i det øjeblik tunnelen er oppe. Et forum nægter at logge dig ind, og en streaming-side insisterer på, at du er i et land, du aldrig har besøgt. Intet af det kræver spyware. Et websted ser den adresse, dine pakker ankommer fra, og med en VPN tilhører den adresse et datacenter i stedet for en hjemmelinje. Det meste af det, der kaldes VPN-detektion, begynder og slutter med den ene kendsgerning, og resten er slutninger med en forudsigelig fejlrate.
Blokeringen begynder med, hvor dine pakker ser ud til at komme fra
Hver anmodning bærer en kildeadresse, og den modtagende server kan slå den op i offentlige data: hvilket netværk der annoncerer den, om netværket er en hostingudbyder, om det har optrådt på misbrugslister, og hvilket land registret tildeler. Intet af det identificerer dig, og alt sammen er nok til at placere dig i en bås.
Se din egen trafik, som en fremmed ville gøre. To kommandoer dækker det meste af overfladen, og den anden 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 udgangsadressen, dens organisation og dens land. Den anden returnerer adressen på den resolver, der nåede Googles navneserver, og den er ofte et andet netværk end din udgang, og det er den adresse, et websted ser, hvis det logger data på resolver-siden. Når de to tilhører forskellige lande, betragter nogle websteder uoverensstemmelsen som mistænkelig, selv om der ikke er noget galt med din opsætning.
Når afvisningen først begynder, efter at tunnelen er oppe, skal du mistænke udgangsadressen før alt andet. Skift servere, og prøv igen, før du rører browseren. En blokering, der følger dig gennem tre udgange fra samme udbyder, handler om udbyderens områder; en blokering, der forsvinder på en anden server, handler om den ene adresse.
Tidszone, sprog og ur er uenige med adressen
Sidekode kan læse din tidszone, dine sprogpræferencer og dine skærmindstillinger uden nogen tilladelsesprompt. En browser, der rapporterer centraleuropæisk tid, mens forbindelsen kommer fra et datacenter i Singapore, er et stærkere signal end adressen alene, og det er netop den slags uoverensstemmelse, som svindelscoring er bygget til at bemærke.
Intl.DateTimeFormat().resolvedOptions().timeZone
navigator.language
Intl.DateTimeFormat().resolvedOptions().localeDe tre linjer i udviklerkonsollen fortæller, hvad din browser frivilligt giver. En VPN-klient kan ændre din rute og intet andet, så den profil, du bærer, forbliver indenlandsk, mens din udgang ikke er det. Konsistens er det, der betyder noget her: en bærbar computer sat til samme region som udgangen ser almindelig ud, og en bærbar computer, der er uenig med sig selv, gør ikke.
Det er også derfor, fejlen er periodisk. Mange websteder er ligeglade, nogle få scorer den, og et medlemssite beslutter, at du er en svindler. Klienten fungerer korrekt i alle tre tilfælde, og derfor er det sædvanlige support-svar, «det må være din browser», både irriterende og delvist sandt.
Hvad sidekode egentlig ved om din maskine
JavaScript har ingen API, der opregner netværksgrænseflader. En side kan ikke spørge, hvilke adresser din bærbare har, så den gamle påstand om, at et script læser din LAN-adresse, er mest en erindring fra plugin-æraen, hvor ActiveX-kontroller, Java-applets og anden native kode kunne gøre præcis 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 den ærlige undtagelse fra «ingen lokale adresselækager». Dens kandidatindsamling afslørede engang lokale adresser til enhver side, der spurgte, og rettelsen var at erstatte værtskandidater med tilfældige mDNS-navne. Den standard gælder i aktuelle browsere, men det er en browserbeslutning og ikke en protokolgaranti, så et forældet build eller en hærdet konfiguration, der genaktiverer lokale kandidater, kan stadig lække. At opdatere browseren hjælper dig mere her end nogen udvidelse.
Din udbyder ser navnene, ikke indholdet
HTTPS beskytter en sides indhold ende til ende, og tunneloperatøren, der videresender de bytes, kan ikke læse dem. Operatøren kan stadig se, hvilken adresse du kontaktede, og i de fleste opsætninger servernavnet i håndtrykket, fordi navnet skal være læsbart, for at forbindelsen kan rutes til det rigtige websted. Encrypted Client Hello findes netop for at skjule det felt, og det hjælper kun, når både klienten og webstedet understøtter det.
Navneopløsning er den anden halvdel. Hvis din udbyder også leverer resolveren, ser den hvert navn, du slår op, før nogen forbindelse findes. Hvis din enhed bruger en offentlig resolver over HTTPS, ser udbyderen en forbindelse til den resolver og intet andet, mens resolveren selv ser listen.
En ukrypteret HTTP-anmodning er læsbar for operatøren af samme grund, som den er læsbar for hotelnetværket: intet i den er krypteret. En tunnel har aldrig påstået andet, og den reparerer ikke applikationens valg.
Skeln mellem «dette er en VPN» og «dette er mig»
Detektion er billig, sandsynlighedsbaseret og ofte forkert. Delte udgangsadresser markeres, fordi nogen andre misbrugte dem, virksomhedsområder klassificeres som hosting, og mobilselskaber giver georesultater, der overrasker alle. Identifikation er et andet problem: det kræver et vedvarende link som en konto, du har logget ind på, en cookie, en betalingsoplysning eller to observatører, der sammenligner noter.
Beslut, hvilken af dem du egentlig kæmper imod. Hvis målet er at læse en side, gør HTTPS allerede det arbejde, og tunnelen ændrer lidt. Hvis målet er at forhindre webstedet i at vide, hvilken by du er i, er udgangen og resolveren det, der betyder noget. Hvis målet er at bryde forbindelsen til din rigtige identitet, er kontoen det svage punkt, og at skifte servere gør intet ved det login, du lige brugte.
En ny udgang logger dig ikke ud af noget, og den kan ikke slette, hvad et websted allerede har gemt om den konto, du brugte. Den praktiske rækkefølge er derfor uglamourøs: vælg en udgang, hvis netværk ser almindeligt ud, hold browserprofilen konsistent med den, opdater browseren, så de lækageudsatte funktioner bruger deres moderne standarder, og accepter, at et lille antal websteder stadig vil gætte forkert om dig.