Je server ziet de VPN-uitgang, niet de bezoeker

Een bezoeker verbindt via een commerciële VPN en je applicatie logt het uitgangsadres. Dat is geen verborgen identiteit: het is het enige bronadres dat de TCP-verbinding heeft. Al het andere dat mensen detectie noemen, is een gevolgtrekking bovenop dat ene feit.

Wat een verzoek werkelijk meedraagt

De applicatie ziet het bronadres en de poort van de verbinding, de voltooide handshake en de bytes die de client koos te versturen. Onder een volledige tunnel is die bron de uitgang, gedeeld door iedereen die hem gebruikt. Onder een gesplitste tunnel kunnen verzoeken van de tunnel of van de lokale verbinding komen, afhankelijk van de bestemming. Als de client en de server zich in dezelfde VPN bevinden, is de bron het interne tunneladres van de client, dat een eindpunt aanduidt en geen locatie.

Geen enkel veld in een gewoon verzoek draagt het adres dat de client vóór de tunnel had. Een doorstuurheader is een bewering van de client of van een proxy, en kan worden weggelaten of vervalst.

Detectie is classificatie, en classificatie is een gok

De praktische methoden zijn lijsten met bekende VPN- en hostingbereiken, latentie die niet overeenkomt met een beweerde regio, traceroute-vormen en accountgedrag. Elk ervan levert een waarschijnlijkheid op. Een bedrijfs-VPN kan op adressen zitten die residentieel lijken, een residentiële proxy kan op een thuislijn lijken, en carrier-NAT kan op een hostingbereik lijken.

Een gedeelde uitgang blokkeren blokkeert elke onbetrokken gebruiker erachter, wat een detectiebeslissing in een nevenschade omzet. Een vertrouwensscore is geen identiteit en zou nooit de enige invoer mogen zijn voor een verbannings- of terugbetalingsbeslissing.

Als jij de VPN bezit, heb je een betrouwbaar signaal dat niets met detectie te maken heeft: wijs een toegewijde pool toe en vergelijk de waargenomen bron ermee. Dat werkt omdat je beide uiteinden beheert en de pool kunt documenteren. Maar het generaliseert niet naar bezoekers die je niet beheert, en het is niet langer betrouwbaar zodra de pool met andere diensten wordt gedeeld.

Lokaal bewijs tegenover bewijs aan de serverkant

Op de machine zelf is een tunnel zichtbaar: een virtuele adapter, een standaardroute die naar een tunnelapparaat wijst, een resolver die is veranderd. Code die daar draait kan interfaces opsommen en zoeken naar PPP, TAP of een leveranciersstuurprogramma.

Een webpagina kan daar niets van lezen. De gebruikelijke omweg laadt een bron die alleen vanaf het interne netwerk wordt geleverd en beschouwt succes als bewijs van tunnelgebruik. Het test in feite bereikbaarheid: een gesplitste tunnel, een verouderd gecacht bestand of een onderscheppingsproxy geven in beide toestanden hetzelfde resultaat. Lokaal bewijs blijft lokaal.

Kies toegangscontroles die de onduidelijkheid overleven

Bouw toegangscontrole op geverifieerde identiteit, apparaatgezondheid en autorisatie per bron. Die predicaten beschrijven wie er vraagt en wat diegene mag bereiken, en ze blijven zinvol of er nu een tunnel in het spel is of niet. Of een verzoek via een VPN binnenkwam, is een zwak signaal dat zowel onterechte toelatingen als nevenschade-blokkades oplevert. Houd het bewijs en de beslissing in aparte velden, zodat een betwiste blokkade iets heeft om te herzien.

IP-geolocatie is één invoer naast andere, en locatiediensten van de browser kunnen Wi-Fi of GPS gebruiken die de tunnel nooit volgen. Een kaart die nog steeds de stad van de bezoeker toont, is bewijs over locatiediensten, geen bewijs dat de tunnel faalde.

Schrijf op welk signaal elke beslissing stuurde. Wanneer een klant een blokkade betwist, is dat verslag het verschil tussen een herziening en een ruzie.