Serverul tău vede ieșirea VPN, nu vizitatorul

Un vizitator se conectează printr-un VPN comercial, iar aplicația ta înregistrează adresa de ieșire. Aceasta nu este o identitate ascunsă: este singura adresă de origine pe care o are conexiunea TCP. Tot restul pe care oamenii îl numesc detectare este o inferență suprapusă peste acel singur fapt.

Ce transportă de fapt o cerere

Aplicația vede adresa și portul de origine ale conexiunii, strângerea de mână finalizată și octeții pe care clientul a ales să-i trimită. Într-un tunel complet, acea origine este ieșirea, partajată de toți cei care o folosesc. Într-un tunel divizat, cererile pot sosi din tunel sau din conexiunea locală, în funcție de destinație. Dacă clientul și serverul sunt amândoi în același VPN, originea este adresa internă a tunelului clientului, care identifică un punct final, nu o locație.

Niciun câmp al unei cereri obișnuite nu transportă adresa pe care clientul o avea înainte de tunel. Un antet de redirecționare este o afirmație a clientului sau a unui proxy și poate fi omis sau falsificat.

Detectarea este clasificare, iar clasificarea este o presupunere

Metodele practice sunt liste de intervale cunoscute de VPN și de găzduire, latență care nu se potrivește cu o regiune declarată, forme de traceroute și comportamentul contului. Fiecare produce o probabilitate. Un VPN corporate poate sta pe adrese care par rezidențiale, un proxy rezidențial poate arăta ca o linie de acasă, iar NAT-ul operatorului poate arăta ca un interval de găzduire.

Blocarea unei ieșiri partajate blochează fiecare utilizator nelegat de acesta din urmă, ceea ce transformă o decizie de detectare într-o întrerupere colaterală. Un scor de încredere nu este o identitate și nu ar trebui să fie niciodată singura intrare a unei decizii de interdicție sau de rambursare.

Dacă VPN-ul este al tău, ai un semnal fiabil care nu are nimic de-a face cu detectarea: alocă un pool dedicat și compară sursa observată cu el. Funcționează pentru că controlezi ambele capete și poți documenta pool-ul. Dar nu se generalizează la vizitatorii pe care nu-i administrezi și încetează să mai fie fiabil în momentul în care pool-ul este partajat cu alte servicii.

Dovezi locale versus dovada de la server

Pe mașina însăși un tunel este vizibil: un adaptor virtual, o rută implicită care indică un dispozitiv de tunel, un resolver care s-a schimbat. Codul care rulează acolo poate enumera interfețele și poate căuta PPP, TAP sau un driver de furnizor.

O pagină web nu poate citi nimic din toate acestea. Ocolul obișnuit încarcă o resursă servită doar din rețeaua internă și tratează succesul ca dovadă a utilizării tunelului. De fapt testează accesibilitatea: un tunel divizat, un fișier cache învechit sau un proxy de interceptare dau același rezultat în ambele stări. Dovezile locale rămân locale.

Alege controale de acces care supraviețuiesc ambiguității

Construiește controlul accesului pe identitate verificată, sănătatea dispozitivului și autorizare pe resursă. Acele predicate descriu cine întreabă și la ce poate ajunge, și rămân semnificative indiferent dacă un tunel este implicat sau nu. Dacă o cerere a sosit prin VPN este un semnal slab care produce atât acceptări false, cât și blocări colaterale. Ține dovada și decizia în câmpuri separate, astfel încât un blocaj contestat să aibă ce examina.

Geolocalizarea IP este o intrare printre mai multe, iar serviciile de locație ale browserului pot folosi Wi-Fi sau GPS care nu urmează niciodată tunelul. O hartă care încă arată orașul vizitatorului este o dovadă despre serviciile de locație, nu o dovadă că tunelul a eșuat.

Notează care semnal a ghidat fiecare decizie. Când un client contestă un blocaj, acea înregistrare este diferența dintre o revizuire și o ceartă.