Twój serwer widzi wyjście VPN, nie odwiedzającego

Odwiedzający łączy się przez komercyjny VPN, a Twoja aplikacja rejestruje adres wyjściowy. To nie jest ukryta tożsamość: to jedyny adres źródłowy, jaki ma połączenie TCP. Wszystko inne, co ludzie nazywają wykrywaniem, jest wnioskiem nałożonym na ten jeden fakt.

Co naprawdę niesie żądanie

Aplikacja widzi adres i port źródłowy połączenia, ukończone uzgadnianie oraz bajty, które klient wybrał do wysłania. W pełnym tunelu tym źródłem jest wyjście, współdzielone przez wszystkich, którzy go używają. W tunelu dzielonym żądania mogą przychodzić z tunelu albo z połączenia lokalnego, zależnie od celu. Jeśli klient i serwer są w tym samym VPN, źródłem jest wewnętrzny adres tunelu klienta, który wskazuje punkt końcowy, a nie lokalizację.

Żadne pole zwykłego żądania nie niesie adresu, który klient miał przed tunelem. Nagłówek przekazywania jest twierdzeniem klienta lub proxy i można go pominąć albo sfałszować.

Wykrywanie to klasyfikacja, a klasyfikacja to zgadywanie

Praktyczne metody to listy znanych zakresów VPN i hostingu, opóźnienie niezgodne z deklarowanym regionem, kształty traceroute i zachowanie konta. Każda z nich daje prawdopodobieństwo. Firmowy VPN może siedzieć na adresach wyglądających na domowe, domowe proxy może wyglądać jak linia domowa, a NAT operatora może wyglądać jak zakres hostingu.

Blokowanie współdzielonego wyjścia blokuje każdego niepowiązanego użytkownika za nim, co zamienia decyzję o wykrywaniu w awarię uboczną. Ocena zaufania nie jest tożsamością i nigdy nie powinna być jedynym wejściem decyzji o blokadzie lub zwrocie.

Jeśli VPN należy do Ciebie, masz wiarygodny sygnał, który nie ma nic wspólnego z wykrywaniem: przydziel dedykowaną pulę i porównaj z nią obserwowane źródło. Działa to, ponieważ kontrolujesz oba końce i możesz udokumentować pulę. Nie uogólnia się jednak na odwiedzających, którymi nie zarządzasz, i przestaje być wiarygodne w chwili, gdy pula jest współdzielona z innymi usługami.

Dowody lokalne a dowód po stronie serwera

Na samej maszynie tunel jest widoczny: wirtualny adapter, trasa domyślna wskazująca urządzenie tunelowe, zmieniony resolver. Kod tam uruchomiony może wyliczyć interfejsy i szukać PPP, TAP lub sterownika dostawcy.

Strona internetowa nie może nic z tego odczytać. Zwykłe obejście ładuje zasób serwowany tylko z sieci wewnętrznej i uznaje sukces za dowód użycia tunelu. W rzeczywistości testuje osiągalność: tunel dzielony, nieaktualny plik z pamięci podręcznej lub proxy przechwytujące dają ten sam wynik w obu stanach. Dowody lokalne pozostają lokalne.

Wybierz kontrolę dostępu, która przetrwa niejednoznaczność

Buduj kontrolę dostępu na zweryfikowanej tożsamości, kondycji urządzenia i autoryzacji dla każdego zasobu. Te predykaty opisują, kto pyta i do czego może dotrzeć, i pozostają istotne niezależnie od tego, czy tunel jest w grze. To, czy żądanie przyszło przez VPN, jest słabym sygnałem, który daje zarówno fałszywe akceptacje, jak i blokady uboczne. Trzymaj dowód i decyzję w osobnych polach, aby sporna blokada miała co przejrzeć.

Geolokalizacja IP to jedno z kilku wejść, a usługi lokalizacji przeglądarki mogą używać Wi-Fi lub GPS, które nigdy nie podążają za tunelem. Mapa, która nadal pokazuje miasto odwiedzającego, jest dowodem o usługach lokalizacji, a nie dowodem, że tunel zawiódł.

Zapisz, który sygnał kierował każdą decyzją. Gdy klient kwestionuje blokadę, ten zapis jest różnicą między przeglądem a sporem.