Serveren din ser VPN-utgangen, ikke den besøkende

En besøkende kobler til gjennom en kommersiell VPN, og applikasjonen din logger utgangsadressen. Det er ikke en skjult identitet: det er den eneste kildeadressen TCP-forbindelsen har. Alt annet folk kaller deteksjon, er slutninger lagt oppå den ene kjensgjerningen.

Hva en forespørsel faktisk bærer

Applikasjonen ser forbindelsens kildeadresse og port, håndtrykket den fullførte, og bytene klienten valgte å sende. Under en full tunnel er den kilden utgangen, delt av alle som bruker den. Under en delt tunnel kan forespørsler komme fra tunnelen eller fra den lokale forbindelsen avhengig av destinasjonen. Hvis klienten og serveren begge er inne i samme VPN, er kilden klientens indre tunneladresse, som identifiserer et endepunkt og ikke en plassering.

Ingen felt i en vanlig forespørsel bærer adressen klienten hadde før tunnelen. En videresendingsheader er klientens eller en proxys påstand, og den kan utelates eller forfalskes.

Deteksjon er klassifisering, og klassifisering er gjetning

De praktiske metodene er lister over kjente VPN- og hostingområder, ventetid som ikke stemmer med en påstått region, traceroute-former og kontoadferd. Hver av dem gir en sannsynlighet. En bedrifts-VPN kan ligge på adresser som ser bolig ut, en boligproxy kan se ut som en hjemmelinje, og operatørens NAT kan se ut som et hostingområde.

Å blokkere en delt utgang blokkerer hver ubeslektet bruker bak den, noe som gjør en deteksjonsbeslutning om til en følgefeil. En tillitsscore er ikke en identitet og bør aldri være det eneste innspillet til en beslutning om utestengelse eller refusjon.

Hvis du eier VPN-en, har du et pålitelig signal som ikke har noe med deteksjon å gjøre: tildel en dedikert pool og match den observerte kilden mot den. Det virker fordi du kontrollerer begge ender og kan dokumentere poolen. Men det generaliserer ikke til besøkende du ikke administrerer, og det slutter å være pålitelig i det øyeblikket poolen deles med andre tjenester.

Lokale bevis mot bevis på serversiden

På selve maskinen er en tunnel synlig: en virtuell adapter, en standardrute som peker på en tunnelenhet, en resolver som er endret. Kode som kjører der, kan liste opp grensesnitt og se etter PPP, TAP eller en leverandørdriver.

En nettside kan ikke lese noe av dette. Den vanlige omveien laster en ressurs som bare serveres fra det interne nettverket, og behandler suksess som bevis på tunnelbruk. Den tester i stedet tilgjengelighet: en delt tunnel, en utdatert bufret fil eller en avlyttingsproxy gir samme resultat i begge tilstander. Lokale bevis forblir lokale.

Velg tilgangskontroller som overlever uklarheten

Bygg tilgangskontroll på verifisert identitet, enhetshelse og autorisasjon per ressurs. Disse predikatene beskriver hvem som spør og hva de kan nå, og de forblir meningsfulle enten en tunnel er involvert eller ikke. Om en forespørsel kom over en VPN, er et svakt signal som gir både falske godkjenninger og følgeblokkeringer. Hold beviset og beslutningen i separate felt, slik at en omstridt blokkering har noe å gjennomgå.

IP-geolokasjon er ett innspill blant flere, og nettleserens posisjonstjenester kan bruke Wi-Fi eller GPS som aldri følger tunnelen. Et kart som fortsatt viser den besøkendes by, er bevis om posisjonstjenester, ikke bevis for at tunnelen sviktet.

Skriv ned hvilket signal som styrte hver beslutning. Når en kunde bestrider en blokkering, er den registreringen forskjellen mellom en gjennomgang og en diskusjon.