Din server ser VPN-udgangen, ikke den besøgende

En besøgende forbinder gennem en kommerciel VPN, og din applikation logger udgangsadressen. Det er ikke en skjult identitet: det er den eneste kildeadresse, TCP-forbindelsen har. Alt andet, som folk kalder registrering, er slutninger lagt oven på den ene kendsgerning.

Hvad en anmodning faktisk bærer

Applikationen ser forbindelsens kildeadresse og port, det håndtryk den fuldførte, og de bytes klienten valgte at sende. Under en fuld tunnel er den kilde udgangen, delt af alle, der bruger den. Under en delt tunnel kan anmodninger ankomme fra tunnelen eller fra den lokale forbindelse afhængigt af destinationen. Hvis klienten og serveren begge er inde i den samme VPN, er kilden klientens indre tunneladresse, som identificerer et endepunkt frem for en placering.

Intet felt i en almindelig anmodning bærer den adresse, klienten havde før tunnelen. Et videresendelseshoved er klientens eller en proxys påstand, og det kan udelades eller forfalskes.

Registrering er klassificering, og klassificering er et gæt

De praktiske metoder er lister over kendte VPN- og hostingområder, ventetid der ikke stemmer med en påstået region, traceroute-former og kontoadfærd. Hver af dem giver en sandsynlighed. En virksomheds-VPN kan ligge på adresser, der ser private ud, en privat proxy kan se ud som en hjemmelinje, og operatørens NAT kan se ud som et hostingområde.

Blokering af en delt udgang blokerer enhver uvedkommende bruger bag den, hvilket gør en registreringsbeslutning til et følgeafbrud. En tillidsscore er ikke en identitet og bør aldrig være det eneste input til en beslutning om udelukkelse eller tilbagebetaling.

Hvis du ejer VPN'en, har du et pålideligt signal, der intet har med registrering at gøre: tildel en dedikeret pulje og match den observerede kilde mod den. Det virker, fordi du styrer begge ender og kan dokumentere puljen. Men det generaliserer ikke til besøgende, du ikke administrerer, og det holder op med at være pålideligt i det øjeblik, puljen deles med andre tjenester.

Lokale beviser kontra beviser på serversiden

På selve maskinen er en tunnel synlig: en virtuel adapter, en standardrute der peger på en tunneleenhed, en resolver der er ændret. Kode, der kører der, kan opregne grænseflader og lede efter PPP, TAP eller en leverandørdriver.

En webside kan ikke læse noget af det. Den almindelige omvej indlæser en ressource, der kun leveres fra det interne netværk, og betragter succes som bevis for tunnelbrug. Den tester i stedet tilgængelighed: en delt tunnel, en forældet cachet fil eller en aflytningsproxy giver samme resultat i begge tilstande. Lokale beviser forbliver lokale.

Vælg adgangskontroller, der overlever uklarheden

Byg adgangskontrol på verificeret identitet, enhedssundhed og autorisation pr. ressource. Disse prædikater beskriver, hvem der spørger, og hvad de må nå, og de forbliver meningsfulde, uanset om en tunnel er involveret. Om en anmodning ankom over en VPN, er et svagt signal, der giver både falske accepter og følgeblokeringer. Hold beviset og beslutningen i separate felter, så en omstridt blokering har noget at gennemgå.

IP-geolokation er ét input blandt flere, og browserens lokationstjenester kan bruge Wi-Fi eller GPS, der aldrig følger tunnelen. Et kort, der stadig viser den besøgendes by, er bevis om lokationstjenester, ikke bevis for at tunnelen svigtede.

Skriv ned, hvilket signal der drev hver beslutning. Når en kunde bestrider en blokering, er den registrering forskellen mellem en gennemgang og en diskussion.