Il tuo server vede l’uscita VPN, non il visitatore

Un visitatore si connette tramite una VPN commerciale e la tua applicazione registra l’indirizzo di uscita. Non è un’identità nascosta: è l’unico indirizzo di origine che la connessione TCP possiede. Tutto il resto che le persone chiamano rilevamento è un’inferenza costruita su quell’unico fatto.

Che cosa trasporta davvero una richiesta

L’applicazione vede l’indirizzo e la porta di origine della connessione, la stretta di mano completata e i byte che il client ha scelto di inviare. Con un tunnel completo, quell’origine è l’uscita, condivisa da tutti coloro che la usano. Con un tunnel diviso, le richieste possono arrivare dal tunnel o dalla connessione locale a seconda della destinazione. Se il client e il server sono entrambi dentro la stessa VPN, l’origine è l’indirizzo interno del tunnel del client, che identifica un estremo e non una posizione.

Nessun campo di una richiesta ordinaria porta l’indirizzo che il client aveva prima del tunnel. Un’intestazione di inoltro è un’asserzione del client o di un proxy, e può essere omessa o falsificata.

Il rilevamento è classificazione, e la classificazione è una congettura

I metodi pratici sono elenchi di intervalli noti di VPN e di hosting, latenza che non concorda con una regione dichiarata, forme di traceroute e comportamento dell’account. Ognuno produce una probabilità. Una VPN aziendale può trovarsi su indirizzi che sembrano residenziali, un proxy residenziale può sembrare una linea domestica, e il NAT di un operatore può sembrare un intervallo di hosting.

Bloccare un’uscita condivisa blocca ogni utente non correlato che sta dietro, il che trasforma una decisione di rilevamento in un disservizio collaterale. Un punteggio di confidenza non è un’identità e non dovrebbe mai essere l’unico input di una decisione di ban o di rimborso.

Se la VPN è tua, hai un segnale affidabile che non ha nulla a che fare con il rilevamento: assegna un pool dedicato e confronta con esso l’origine osservata. Funziona perché controlli entrambe le estremità e puoi documentare il pool. Ma non si generalizza ai visitatori che non gestisci, e smette di essere affidabile nel momento in cui il pool viene condiviso con altri servizi.

Prove locali contro prova lato server

Sulla macchina stessa un tunnel è visibile: un adattatore virtuale, una rotta predefinita che punta a un dispositivo di tunnel, un resolver che è cambiato. Il codice in esecuzione lì può enumerare le interfacce e cercare PPP, TAP o un driver del fornitore.

Una pagina web non può leggere nulla di tutto ciò. Il solito espediente carica una risorsa servita solo dalla rete interna e considera il successo come prova dell’uso del tunnel. In realtà verifica la raggiungibilità: un tunnel diviso, un file in cache obsoleto o un proxy di intercettazione danno lo stesso risultato in entrambi gli stati. Le prove locali restano locali.

Scegli controlli di accesso che sopravvivano all’ambiguità

Costruisci il controllo degli accessi su identità verificata, integrità del dispositivo e autorizzazione per risorsa. Questi predicati descrivono chi chiede e a che cosa può arrivare, e restano significativi che un tunnel sia coinvolto o no. Se una richiesta è arrivata tramite VPN è un segnale debole che produce sia accettazioni errate sia blocchi collaterali. Tieni la prova e la decisione in campi separati, così che un blocco contestato abbia qualcosa da riesaminare.

La geolocalizzazione IP è un input tra diversi, e i servizi di localizzazione del browser possono usare Wi-Fi o GPS che non seguono mai il tunnel. Una mappa che mostra ancora la città del visitatore è una prova sui servizi di localizzazione, non la prova che il tunnel abbia fallito.

Annota quale segnale ha guidato ogni decisione. Quando un cliente contesta un blocco, quel registro è la differenza tra una revisione e una discussione.