Czym jest wyciek WebRTC
WebRTC to wbudowana w przeglądarkę funkcja komunikacji w czasie rzeczywistym, wykorzystywana w wideokonferencjach, rozmowach głosowych, przesyłaniu plików P2P i podobnych zastosowaniach. Aby nawiązać połączenie peer-to-peer, przeglądarka ustala swój adres widoczny od strony Internetu za pomocą serwera STUN. To sondowanie zwykle korzysta z UDP, a zwykłe proxy HTTP / SOCKS niekoniecznie przechwytują UDP.
Jeśli żądanie STUN omija proxy i wychodzi bezpośrednio z sieci lokalnej, skrypt na stronie może uzyskać Twoje prawdziwe publiczne IP. Zwykle nie wymaga to uprawnień do kamery ani mikrofonu i nie wyświetla dodatkowego okna z prośbą o potwierdzenie, dlatego często w ten sposób sprawdza się, czy proxy naprawdę obejmuje ruch komunikacji w czasie rzeczywistym.
Jak to narzędzie wykrywa wyciek
Strona wysyła sondy WebRTC do wielu serwerów STUN, zbiera zwrócone adresy publiczne i porównuje je z wyjściowym IP HTTP. Jeśli zwrócony adres zgadza się z bieżącym wyjściem, ścieżkę UDP najprawdopodobniej obsługuje proxy; jeśli zwracany jest adres lokalnego operatora, trzeba to dokładnie zbadać.
- Sprawdzenie, czy UDP przechodzi przez wyjście proxy
- Wykrycie, czy IPv4 / IPv6 wyciekają niezależnie od siebie
- Obserwacja, czy różne cele STUN trafiają w różne reguły routingu
Rola STUN i UDP
UDP to bezpołączeniowy protokół transportowy, często używany do przesyłania głosu, wideo, w grach i komunikacji w czasie rzeczywistym. Zadanie STUN jest proste: wysyłasz pakiet UDP do serwera, a serwer odpowiada, jaki źródłowy adres IP zobaczył. WebRTC opiera się na tym wyniku przy negocjowaniu połączenia, dlatego adres widziany przez STUN jest kluczowym dowodem przy ocenie wycieku.
Jak interpretować wyniki
Nie wykryto wyciekuPubliczne IP zwrócone przez WebRTC zgadza się z bieżącym wyjściem proxy (dla IPv6 — ta sama sieć /64). Jeśli nie zwrócono żadnego publicznego IP, test po prostu nie otrzymał odpowiedzi; nie jest to dowód bezpieczeństwa.
Podejrzenie wyciekuWebRTC zwróciło inne publiczne IP, a jego lokalizacja, operator lub numer ASN wskazują na Twoją prawdziwą sieć lokalną.
Normalny routing według regułRóżne serwery STUN zwróciły różne wyjścia proxy, ale są one zgodne z Twoją konfiguracją routingu lub tym, czego oczekujesz od reguł.
Co zrobić po wykryciu wycieku
- Przełącz klienta proxy na tryb TUN, aby ruch UDP z WebRTC też przechodził przez wyjście proxy.
- Chrome / Edge: ustaw zasadę dla przedsiębiorstw <code>WebRtcIPHandling</code> = <code>disable_non_proxied_udp</code>; Firefox: włącz <code>media.peerconnection.ice.proxy_only_if_behind_proxy</code> w <code>about:config</code>. Nie usuwaj WebRTC całkowicie, bo przeglądarka bez WebRTC sama w sobie jest rozpoznawalna.
- Brave: ustaw zasadę obsługi adresów IP w WebRTC na „Disable non-proxied UDP”.
- Jeśli potrzebujesz wideokonferencji lub rozmów głosowych, najpierw popraw reguły routingu UDP / STUN w kliencie proxy.
Kilka wyjściowych IP to niekoniecznie wyciek
Jeśli skonfigurowano routing według reguł, różne serwery STUN mogą iść przez różne węzły — na przykład STUN Google przez wyjście w USA, a STUN Cloudflare przez wyjście w Hongkongu. Nie musi to być groźne; liczy się, czy wynik zgadza się z założeniami Twoich reguł. Naprawdę powinno Cię zaniepokoić dopiero to, że wszystkie adresy WebRTC wskazują na Twoją fizyczną lokalizację lub lokalnego dostawcę internetu.
Wycieki DNS są równie ważne
Wyciek WebRTC ujawnia „Twoje prawdziwe IP”, a wyciek DNS — „jakie domeny odpytujesz”. Jeśli żądania DNS nie przechodzą przez proxy, lokalny operator lub nadrzędny resolver nadal widzi, jakie strony odwiedzasz.
Test wycieku DNS na tej stronie korzysta z prawdziwej sondy: CleanIP.io utrzymuje po jednym autorytatywnym serwerze NS w stanie Utah w USA (ns1) i w Los Angeles w USA (ns2), obsługujących strefę dp.cleanip.io. Każdy test rozwiązuje 8 niezależnych subdomen <uuid>.dp.cleanip.io; zapytania te przechodzą przez systemowy stub resolver -> resolver rekurencyjny dostawcy internetu / VPN / publiczny i ostatecznie trafiają na nasz autorytatywny serwer NS, który zapisuje adres IP resolvera wysyłającego zapytanie oraz (jeśli jest) EDNS Client Subnet (podsieć klienta), a potem zwraca je do porównania.
Zwróć uwagę na dwa sygnały: ① podsieć ECS — jeśli resolver rekurencyjny przekazał podsieć Twojego urządzenia (częste w przypadku Google 8.8.8.8), ta podsieć jednoznacznie identyfikuje klienta; ② kraj resolvera — anycast publicznych resolverów rekurencyjnych (1.1.1.1 / 8.8.8.8) w różnych krajach jest normalny; liczy się, czy przy VPN, który uważasz za włączony, lokalizacja resolvera zgadza się z krajem wyjścia HTTP.
Dlaczego tryb proxy i tryb TUN dają różne wyniki
Proxy HTTP / SOCKS zwykle obsługują tylko TCP, więc pakiety UDP potrzebne dla STUN mogą nie zostać wysłane, a strona może pokazać „brak wycieku”. Nie oznacza to, że UDP jest bezpiecznie przekazywane przez proxy — po prostu UDP nie dotarło do serwera STUN. Tryb TUN przechwytuje zarówno TCP, jak i UDP na wirtualnej karcie sieciowej, więc lepiej odzwierciedla rzeczywistą ścieżkę wyjścia UDP.
TrybSTUN UDPZnaczenie wyniku
Proxy HTTP / SOCKSMoże nie zostać wysłane„Brak wycieku” może oznaczać tylko zablokowane UDP
TUN / wirtualna karta sieciowaFaktycznie wysyłaneLepiej nadaje się do weryfikacji wyjścia UDP i reguł routingu
Zalecamy powtórzenie testu w trybie sieci, którego faktycznie używasz: jeśli na co dzień korzystasz z TUN, testuj z TUN; jeśli polegasz na proxy w przeglądarce, upewnij się też, że zablokowane UDP nie jest błędnie uznawane za bezpieczne. Oceniając wyciek WebRTC, zwracaj uwagę na numer ASN i lokalizację zwróconego adresu IP oraz na to, czy zgadza się on z Twoimi regułami routingu.