Proxy może obsługiwać ruch HTTP, podczas gdy WebRTC wymienia adresy kandydatów przez STUN/ICE w UDP. Artykuł wyjaśnia, kiedy mogą zostać ujawnione adresy lokalne i prywatne oraz jak zachować spójność wyjścia sieciowego i środowiska przeglądarki.
Proxy jest już skonfigurowane, a strona sprawdzająca IP pokazuje oczekiwany region i operatora. Tożsamość sieciowa wygląda poprawnie. Jednak po otwarciu testu wycieków sekcja WebRTC świeci się na czerwono i pokazuje adres rzeczywistego łącza internetowego.
Nie trzeba od razu zmieniać proxy. Najczęściej problem nie leży w jego jakości, lecz w ruchu, którego proxy nie przejmuje.
Proxy obsługuje HTTP, a WebRTC korzysta z innej drogi
Proxy działa na warstwie sieciowej. Niezależnie od tego, czy jest to rozszerzenie przeglądarki, czy tunel systemowy, przetwarza żądania HTTP/HTTPS i kieruje ten ruch przez wyjście proxy.
WebRTC działa inaczej. To wbudowana w przeglądarkę funkcja komunikacji w czasie rzeczywistym. Aby znaleźć odpowiednią trasę dla rozmów audio/wideo i transmisji P2P, przeglądarka może aktywnie wysyłać zapytania STUN do zewnętrznych serwerów — w praktyce pytając: „Jaki adres widzisz po mojej stronie?” — a następnie przekazywać wyniki stronie jako kandydatów ICE. Zapytania te korzystają z UDP, czyli z kanału niezależnego od tunelu HTTP.
W efekcie pojawia się rozbieżność: żądania strony wychodzą przez proxy, a przeglądarka może jednocześnie zgłosić adres lokalny. Założenie, że samo skonfigurowanie proxy automatycznie porządkuje całą tożsamość sieciową, jest najczęstszym punktem wyjścia tego problemu.
Ujawniony może zostać nie tylko publiczny adres IP
Kandydaci ICE zwykle zawierają dwa rodzaje adresów. Pierwszy to adres publiczny, czyli wyjście rzeczywistego dostawcy Internetu. Drugi to adres lokalny, na przykład prywatny adres zaczynający się od 192.168; czasem pojawia się także adres wirtualnej karty sieciowej.
Sam adres sieci prywatnej niewiele dowodzi, bo ma go niemal każdy komputer. Może jednak być na tyle stabilny, że powtarzające się pokrywanie kandydatów między kilkoma kontami daje platformie dodatkowy sygnał do powiązania ich z tym samym urządzeniem. Adres publiczny jest bardziej bezpośredni: wskazuje prawdziwego operatora i przybliżony obszar geograficzny. Dokładność zależy od platformy, ale zasada jest prosta: im bardziej rzeczywisty adres, tym łatwiejsze powiązanie.
Kiedy witryna może faktycznie odczytać adres?
Nie każda witryna próbuje to robić. Wymiana adresów wymaga, aby strona aktywnie utworzyła obiekt RTCPeerConnection, czego zwykłe strony z treścią na ogół nie potrzebują.
Najczęściej dotyczy to kilku grup serwisów: usług wymagających komunikacji w czasie rzeczywistym, takich jak wideokonferencje, obsługa klienta online i niektóre transmisje na żywo; serwisów mocno opartych na reklamie lub zapobieganiu oszustwom; oraz platform z rozbudowanymi systemami kontroli ryzyka. Odczyt odbywa się poza widocznym interfejsem, a o późniejszym wykorzystaniu zebranych danych zwykle nie ma osobnego powiadomienia.
Istnieje też sytuacja niezależna od witryny. W krótkim momencie ponownego łączenia proxy albo zmiany węzła zapytanie STUN z przeglądarki może zostać wysłane przez sieć lokalną. Okno czasowe jest krótkie, ale wystarcza do zarejestrowania jednej obserwacji.
Trzy typowe scenariusze niepowodzenia
Proxy działające jako rozszerzenie przeglądarki zwykle przejmuje tylko żądania HTTP/HTTPS. UDP pozostaje poza jego zakresem, a zaznaczenie opcji „globalnej” w interfejsie tego nie zmienia.
Proxy systemowe wydaje się pełniejsze, bo obejmuje ruch całego urządzenia. Zbieranie adresów kandydatów może jednak bezpośrednio wiązać się z lokalnym interfejsem sieciowym i omijać systemową tablicę routingu, przez co na tym etapie tunel pozostaje nieszczelny.
Trzeci problem nie jest wyłącznie techniczny, lecz wynika z rozwoju mechanizmów kontroli. Systemy ryzyka coraz częściej traktują adresy WebRTC jako jeden z sygnałów służących do powiązania kont. Dane, których wcześniej nie mierzono albo które ignorowano, mogą dziś być uwzględniane w ocenie.
Celem jest spójne wyjście sieciowe, a nie tylko wyłączenie jednej funkcji
Istnieje kilka ogólnych podejść. Jeśli dany sposób pracy w ogóle nie wymaga komunikacji w czasie rzeczywistym, najprościej wyłączyć WebRTC. Kosztem jest utrata funkcji takich jak wideorozmowy czy obsługa klienta online.
Jeśli funkcje te muszą pozostać dostępne, często stosuje się dopasowanie adresu zwracanego na poziomie WebRTC do wyjścia proxy. Bardziej niezawodne jest także przekazywanie zapytań STUN przez kanał proxy, aby interfejs nie ujawniał adresu lokalnego. Jeśli potrzebne są P2P lub wideorozmowy, cały ruch UDP powinien przechodzić przez proxy, a nie tylko warstwa HTTP.
Częsty błąd polega na uznaniu, że samo wyłączenie WebRTC czyni środowisko „czystym”. Liczy się wzajemna spójność wyjścia sieciowego, rozwiązywania DNS, przynależności IP i ASN, strefy czasowej i języka oraz cech urządzenia. Każda rozbieżność może pozostawić nietypowy sygnał; WebRTC jest po prostu jednym z elementów, które najłatwiej przeoczyć.
Weryfikacja jest prosta. Wykonaj test po zmianie węzła i ponownie przed normalnym użyciem środowiska: otwórz test wycieków i sprawdź, czy sekcja WebRTC pokazuje wyjście proxy, adres lokalny czy prawdziwy adres publiczny. Zwykła strona do sprawdzania IP tego nie pokaże.
Izolacja środowisk na poziomie silnika przeglądarki pozwala ustawić osobną politykę adresów WebRTC dla każdego środowiska i powiązać ją z jego wyjściem sieciowym. PurpleMark oferuje właśnie tego typu możliwości. Jeśli wiele środowisk korzysta z jednego wyjścia albo ich polityki adresowe są niespójne, wartość izolacji znacząco maleje.
To wyłącznie objaśnienie techniczne. Korzystaj z odpowiednich narzędzi zgodnie z zasadami platform i lokalnym prawem.
