Din server ser VPN-utgången, inte besökaren

En besökare ansluter via ett kommersiellt VPN och din applikation loggar utgångsadressen. Det är inte en dold identitet: det är den enda källadress som TCP-anslutningen har. Allt annat folk kallar detektering är en slutsats ovanpå det enda faktumet.

Vad en begäran faktiskt bär

Applikationen ser anslutningens källadress och port, handskakningen som slutfördes och de byte som klienten valde att skicka. Under en full tunnel är den källan utgången, delad av alla som använder den. Under en delad tunnel kan begäranden komma från tunneln eller från den lokala anslutningen beroende på destination. Om klienten och servern båda finns i samma VPN är källan klientens inre tunneladress, som identifierar en slutpunkt och inte en plats.

Inget fält i en vanlig begäran bär den adress klienten hade före tunneln. En vidarebefordringsheader är klientens eller en proxys påstående och kan utelämnas eller förfalskas.

Detektering är klassificering, och klassificering är en gissning

De praktiska metoderna är listor över kända VPN- och hostingintervall, latens som inte stämmer med en påstådd region, traceroute-former och kontobeteende. Var och en ger en sannolikhet. Ett företags-VPN kan ligga på adresser som ser bostadsadresser ut, en bostadsproxy kan se ut som en hemmaanslutning, och operatörens NAT kan se ut som ett hostingintervall.

Att blockera en delad utgång blockerar varje orelaterad användare bakom den, vilket förvandlar ett detekteringsbeslut till ett följdfel. En förtroendepoäng är inte en identitet och bör aldrig vara det enda indata för ett beslut om avstängning eller återbetalning.

Om du äger VPN:et har du en pålitlig signal som inte har något med detektering att göra: tilldela en dedikerad pool och matcha den observerade källan mot den. Det fungerar eftersom du kontrollerar båda ändarna och kan dokumentera poolen. Men det generaliserar inte till besökare du inte administrerar, och det slutar vara pålitligt i samma stund som poolen delas med andra tjänster.

Lokala bevis kontra bevis på serversidan

På själva maskinen är en tunnel synlig: en virtuell adapter, en standardrutt som pekar på en tunnelenhet, en resolver som ändrats. Kod som körs där kan räkna upp gränssnitt och leta efter PPP, TAP eller en leverantörsdrivrutin.

En webbsida kan inte läsa något av detta. Den vanliga omvägen laddar en resurs som bara serveras från det interna nätverket och behandlar framgång som bevis på tunnelanvändning. Den testar i själva verket nåbarhet: en delad tunnel, en inaktuell cachad fil eller en avlyssningsproxy ger samma resultat i båda tillstånden. Lokala bevis förblir lokala.

Välj åtkomstkontroller som överlever otydligheten

Bygg åtkomstkontroll på verifierad identitet, enhetshälsa och auktorisering per resurs. Dessa predikat beskriver vem som frågar och vad den kan nå, och de förblir meningsfulla oavsett om en tunnel är inblandad eller inte. Om en begäran kom via ett VPN är en svag signal som ger både falska godkännanden och följdblockeringar. Håll beviset och beslutet i separata fält, så att en omtvistad blockering har något att granska.

IP-geolokalisering är ett indata bland flera, och webbläsarens platstjänster kan använda Wi-Fi eller GPS som aldrig följer tunneln. En karta som fortfarande visar besökarens stad är bevis om platstjänster, inte bevis för att tunneln misslyckades.

Skriv ned vilken signal som styrde varje beslut. När en kund bestrider en blockering är den posten skillnaden mellan en granskning och en dispyt.