El vostre servidor veu la sortida de la VPN, no el visitant

Un visitant es connecta a través d’una VPN comercial i la vostra aplicació registra l’adreça de sortida. Això no és una identitat oculta: és l’única adreça d’origen que té la connexió TCP. Tota la resta que la gent anomena detecció és una inferència construïda sobre aquest únic fet.

Què porta realment una petició

L’aplicació veu l’adreça i el port d’origen de la connexió, l’aplec de mans que ha completat i els bytes que el client ha triat enviar. Amb un túnel complet, aquest origen és la sortida, compartida per tothom qui la fa servir. Amb un túnel dividit, les peticions poden arribar del túnel o de la connexió local segons la destinació. Si el client i el servidor són dins de la mateixa VPN, l’origen és l’adreça interna del túnel del client, que identifica un extrem i no una ubicació.

Cap camp d’una petició ordinària porta l’adreça que el client tenia abans del túnel. Una capçalera de reenviament és una afirmació del client o d’un servidor intermedi, i es pot ometre o falsificar.

La detecció és classificació, i la classificació és una conjectura

Els mètodes pràctics són llistes de rangs coneguts de VPN i d’allotjament, latència que no concorda amb una regió declarada, formes de traceroute i comportament del compte. Cadascun produeix una probabilitat. Una VPN corporativa pot seure en adreces que semblen residencials, un servidor intermedi residencial pot semblar una línia domèstica, i el NAT de l’operador pot semblar un rang d’allotjament.

Bloquejar una sortida compartida bloqueja tots els usuaris no relacionats que hi ha darrere, cosa que converteix una decisió de detecció en una caiguda col·lateral. Una puntuació de confiança no és una identitat i no hauria de ser mai l’única entrada d’una decisió de prohibició o de devolució.

Si la VPN és vostra, teniu un senyal fiable que no té res a veure amb la detecció: assigneu un pool dedicat i compareu-hi l’origen observat. Funciona perquè controleu els dos extrems i podeu documentar el pool. Però no es generalitza als visitants que no gestioneu, i deixa de ser fiable en el moment que el pool es comparteix amb altres serveis.

Proves locals enfront de proves del costat del servidor

A la mateixa màquina un túnel és visible: un adaptador virtual, una ruta per defecte que apunta a un dispositiu de túnel, un resolutor que ha canviat. El codi que s’hi executa pot enumerar interfícies i buscar PPP, TAP o un controlador de proveïdor.

Una pàgina web no pot llegir res d’això. La solució habitual carrega un recurs servit només des de la xarxa interna i tracta l’èxit com a prova d’ús del túnel. En realitat prova l’abast: un túnel dividit, un fitxer en memòria cau obsolet o un servidor intermedi d’intercepció donen el mateix resultat en tots dos estats. Les proves locals es queden locals.

Trieu controls d’accés que sobrevisquin a l’ambigüitat

Construïu el control d’accés sobre la identitat verificada, la salut del dispositiu i l’autorització per recurs. Aquests predicats descriuen qui pregunta i a què pot arribar, i continuen tenint sentit tant si hi ha un túnel com si no. Si una petició ha arribat per una VPN és un senyal feble que produeix tant acceptacions falses com bloquejos col·laterals. Manteniu la prova i la decisió en camps separats, perquè un bloqueig discutit tingui alguna cosa a revisar.

La geolocalització per IP és una entrada entre diverses, i els serveis d’ubicació del navegador poden fer servir Wi-Fi o GPS que no segueixen mai el túnel. Un mapa que encara mostra la ciutat del visitant és una prova sobre els serveis d’ubicació, no una prova que el túnel hagi fallat.

Anoteu quin senyal ha guiat cada decisió. Quan un client discuteix un bloqueig, aquest registre és la diferència entre una revisió i una discussió.