Вашият сървър вижда изхода на VPN, а не посетителя

Посетител се свързва през търговски VPN и приложението ви записва адреса на изхода. Това не е скрита самоличност: това е единственият адрес на източника, който TCP връзката има. Всичко останало, което хората наричат откриване, е извод, надграден върху този единствен факт.

Какво всъщност носи една заявка

Приложението вижда адреса и порта на източника на връзката, завършеното ръкостискане и байтовете, които клиентът е избрал да изпрати. При пълен тунел този източник е изходът, споделен от всички, които го използват. При разделен тунел заявките може да пристигат от тунела или от локалната връзка в зависимост от дестинацията. Ако клиентът и сървърът са в един и същ VPN, източникът е вътрешният адрес на тунела на клиента, който определя крайна точка, а не местоположение.

Никое поле в обикновена заявка не носи адреса, който клиентът е имал преди тунела. Заглавката за препращане е твърдение на клиента или на прокси и може да бъде пропусната или подправена.

Откриването е класификация, а класификацията е догадка

Практическите методи са списъци с известни диапазони на VPN и хостинг, закъснение, което не съответства на заявен регион, форми на traceroute и поведение на акаунта. Всеки от тях дава вероятност. Корпоративен VPN може да е на адреси, които изглеждат жилищни, жилищно прокси може да изглежда като домашен канал, а NAT на оператора може да изглежда като хостинг диапазон.

Блокирането на споделен изход блокира всеки несвързан потребител зад него, което превръща решение за откриване в съпътстващо прекъсване. Оценката на увереност не е самоличност и никога не трябва да бъде единственият вход за решение за забрана или възстановяване на средства.

Ако VPN-ът е ваш, имате надежден сигнал, който няма нищо общо с откриването: задайте отделен пул и сравнете наблюдавания източник с него. Това работи, защото контролирате двата края и можете да документирате пула. Но не се обобщава за посетители, които не управлявате, и престава да бъде надеждно в момента, в който пулът се сподели с други услуги.

Локални доказателства срещу доказателства от страна на сървъра

На самата машина тунелът е видим: виртуален адаптер, маршрут по подразбиране, сочещ към устройство за тунел, променен резолвер. Кодът, който работи там, може да изброи интерфейсите и да търси PPP, TAP или драйвер на доставчик.

Уеб страница не може да прочете нищо от това. Обичайното заобикаляне зарежда ресурс, който се доставя само от вътрешната мрежа, и приема успеха за доказателство за използване на тунел. Всъщност то проверява достъпността: разделен тунел, остарял кеширан файл или прокси за прихващане дават същия резултат и в двете състояния. Локалните доказателства си остават локални.

Изберете контроли за достъп, които издържат на неопределеността

Изграждайте контрол на достъпа върху потвърдена самоличност, изправност на устройството и оторизация за всеки ресурс. Тези предикати описват кой пита и до какво може да достигне, и остават смислени независимо дали участва тунел. Дали заявката е пристигнала през VPN е слаб сигнал, който дава както фалшиви пропуски, така и съпътстващи блокирания. Дръжте доказателството и решението в отделни полета, за да има спорното блокиране какво да се прегледа.

IP геолокацията е един вход сред няколко, а услугите за местоположение на браузъра може да използват Wi-Fi или GPS, които никога не следват тунела. Карта, която все още показва града на посетителя, е доказателство за услугите за местоположение, а не доказателство, че тунелът е отказал.

Записвайте кой сигнал е ръководил всяко решение. Когато клиент оспори блокиране, този запис е разликата между преглед и спор.