Motyw

Popularne narzędzia

Test wycieku WebRTC

WebRTC może dać stronie adresy, których twoja przeglądarka inaczej by nie wysłała — także ten, który kryje się za twoim VPN. Ten test pyta trzy serwery STUN prowadzone przez Cloudflare i Google, pokazuje każdy adres, który wrócił, i czym on jest, a potem porównuje je z adresem, który strona i tak widzi. Gdy czegoś nie da się przetestować, mówi to wprost, zamiast pokazywać zielonego ptaszka.

Działa w twojej przeglądarce, z serwerami STUN Cloudflare i Google · nic nie zapisujemy · typy kandydatów według RFC 8445

Uruchom go raz z wyłączonym VPN, a raz z włączonym. Różnica jest odpowiedzią.

Twoja przeglądarka pyta trzy serwery STUN, prowadzone przez Cloudflare i Google, jaki adres widzą. Żaden adres znaleziony przez WebRTC nie trafia do nas.

Co strona widzi i takIPv4IPv6Sprawdzam twoje połączenie…
Każdy adres, który podał WebRTC

  1. Każdy adres, który poda WebRTC, pojawi się tutaj w osobnym wierszu, w miarę jak serwery STUN odpowiadają.

Żaden adres znaleziony przez WebRTC nie trafia do nas. Twoja przeglądarka sama pyta serwery STUN, tak jak przy każdej rozmowie wideo. Żeby pokazać, co widzi strona internetowa, nasza strona pyta ipify.org i nasz własny serwer o twoje adresy i ich sieci, tak jak robi to Test Wycieku DNS.

Czym jest wyciek WebRTC?

WebRTC to funkcja przeglądarki, na której działają rozmowy wideo. Żeby połączyć dwie osoby bezpośrednio, zbiera każdy adres, pod którym da się dotrzeć do twojego komputera, i oferuje je stronie — także adresy, których przeglądarka nigdy nie wysłałaby w zwykłym żądaniu.

To zbieranie kandydatów ICE opisuje RFC 8445. Przeglądarka wypisuje adresy twoich własnych interfejsów sieciowych, potem pyta serwer STUN: „z jakiego adresu mnie widzisz?” i dodaje też ten. Każda strona w internecie może to uruchomić kilkoma linijkami JavaScriptu i odczytywać każdego kandydata, gdy tylko się pojawi, bez pytania o zgodę — tak to zaprojektowano, bo rozmowa musi działać bez niego.

Wyciekiem staje się to wtedy, gdy któryś z tych adresów jest czymś, co ukrywasz. VPN zmienia drogę, którą idą żądania przeglądarki, ale WebRTC może pytać system operacyjny o każdy interfejs, więc na komputerze, na którym fizyczne połączenie wciąż działa, prawdziwy adres może pojawić się obok adresu VPN. Nic się nie zepsuło: funkcja robi dokładnie to, do czego ją stworzono.

Co może uruchomić każda stronajedno zbieranie, krok po kroku

TWOJE URZĄDZENIEINTERNETTwój router (NAT)Skrypt stronyTwoja przeglądarkaSerwer STUNstun.cloudflare.comnew RTCPeerConnection()bez pytania o zgodęwypisuje każdy interfejs sieciowy192.168.1.20 → 8b7f4e2a-….localz jakiego adresu mnie widzisz?192.168.1.20:54400203.0.113.7:54400203.0.113.7:54400adres, który zobaczyłkażdego kandydata, gdy tylko się pojawionicecandidateTWOJE URZĄDZENIEINTERNETSkrypt stronyTwoja przeglądarkaSerwer STUNnew RTCPeerConnection()bez pytania o zgodęwypisuje każdy interfejs sieciowy192.168.1.20 → 8b7f4e2a-….localz jakiego adresu mnie widzisz?192.168.1.20203.0.113.7203.0.113.7:54400adres, który zobaczyłkażdego kandydata, gdy tylko się pojawionicecandidateTwój router (NAT)

Cały skrypt

const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.cloudflare.com:3478" }],
});
pc.createDataChannel("");
pc.onicecandidate = (e) => e.candidate && console.log(e.candidate.candidate);
await pc.setLocalDescription(await pc.createOffer());

Co wypisał

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0candidate:1467250027 1 udp 1686052607 203.0.113.7 54400 typ srflx raddr 0.0.0.0 rport 9 generation 0

Czym jest każdy wiersz

  • hostNa tym komputerze8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.localZamaskowany przez przeglądarkę
  • srflxWidziany przez serwer STUN203.0.113.7Routowalny w internecie
Jedno zbieranie na domowym łączu, z adresami dokumentacyjnymi. Prywatny adres nigdy nie opuszcza przeglądarki w niezmienionej postaci; serwer STUN widzi zewnętrzny adres routera, a nie komputer, a obie odpowiedzi trafiają do skryptu, który pytał.
Wynik testu wycieku WebRTC: każdy kandydat ICE z typem, rodzajem każdego adresu i werdyktemWynik testu wycieku WebRTC: każdy kandydat ICE z typem, rodzajem każdego adresu i werdyktemWerdyktWyciek, Brak wycieku albo — uczciwie — Nie przetestowano, wraz z powodem.Każdy adresZ typem kandydata, bo kandydat typu host znaczy co innego niż kandydat typu server-reflexive.Czym jestPrywatny, NAT na poziomie operatora, tunel albo routowalny. Tylko adres routowalny może być wyciekiem.SerweryKażdy serwer STUN w osobnym wierszu. Serwer, który nic nie powiedział, to test, który się nie odbył.Co widzi stronaAdresy, które twoja przeglądarka i tak wysyła; z nimi porównujemy adresy z WebRTC.
Przykładowy test: co odpowiedział każdy serwer STUN, każdy adres ujawniony przez WebRTC, jakiego rodzaju to adres i czy strona już go widzi. Wybierz numer, aby zobaczyć, co pokazuje każda część.

Jak sprawdzić, czy masz wyciek WebRTC

Uruchom test powyżej. Zbiera kandydatów z trzech serwerów STUN, ustala, czym jest każdy adres, i porównuje te routowalne z adresem, który strona i tak widzi.

Możliwe są trzy wyniki, a nie dwa. Brak wycieku oznacza, że każdy routowalny adres, który podał WebRTC, strona już ma. Wyciek oznacza, że co najmniej jednego nie ma — albo że adres twojego własnego komputera został podany bezpośrednio. Nie przetestowano oznacza, że WebRTC jest wyłączony lub zablokowany albo że żaden serwer STUN nie odpowiedział, i to właśnie ten wynik większość narzędzi po cichu zamienia w zaliczony test.

Jeśli używasz VPN, uruchom test dwa razy: raz z wyłączonym, żeby zobaczyć swoje zwykłe adresy, i raz z włączonym. Liczy się drugi test, a różnica między nimi jest odpowiedzią. Strona zachowuje pierwszy wynik, więc możesz porównać bez zapisywania czegokolwiek.

Trzy wyniki, nie dwaco oznacza każdy

  1. Brak wycieku

    Każdy routowalny adres, który podał WebRTC, strona już ma.

    WebRTC podał

    • 198.51.100.23Widziany przez serwer STUNJuż widziany przez strony
    • 8b7f4e2a-….localNa tym komputerzeZamaskowany przez przeglądarkę

    Strona widzi

    198.51.100.23
  2. Wyciek

    Co najmniej jednego adresu strona jeszcze nie ma albo adres twojego własnego komputera został podany bezpośrednio.

    WebRTC podał

    • 198.51.100.23Widziany przez serwer STUNJuż widziany przez strony
    • 2001:db8:4a1f:7c00::1cNa tym komputerzeNiewidziany przez strony

    Strona widzi

    198.51.100.23
  3. Nie przetestowano

    WebRTC jest wyłączony lub zablokowany albo żaden serwer STUN nie odpowiedział. Niczego nie zmierzono.

    stun.cloudflare.comBrak odpowiedzi

    stun.l.google.comBrak odpowiedzi

    Co pokazuje tu większość narzędziBrak wycieku

Uruchom dwa razy

VPN wyłączony

WebRTC podał203.0.113.7

Strona widzi203.0.113.7

Brak wycieku

VPN włączony

WebRTC podał198.51.100.23203.0.113.7

Strona widzi198.51.100.23

Wciąż jest przy włączonym VPN

Wyciek
Każdy wynik z testem, który go daje. Przy wyłączonym VPN adres z WebRTC i adres widziany przez stronę są takie same; przy włączonym oba powinny się zmienić, a ten, który zostaje, jest odpowiedzią.

Czy VPN zatrzymuje wyciek WebRTC?

Sam z siebie nie. VPN zmienia to, dokąd idzie twój ruch; WebRTC może pytać system operacyjny, jakie interfejsy istnieją, a ten fizyczny zwykle nadal tam jest.

Opis samego IETF jest precyzyjny: „jeśli klient próbuje ukryć swoją fizyczną lokalizację za pomocą wirtualnej sieci prywatnej (VPN), a VPN i lokalny system operacyjny obsługują routing przez wiele interfejsów, WebRTC może odkryć nie tylko publiczny adres VPN, ale też publiczny adres dostawcy internetu, przez którego działa VPN”. Oferowane są oba adresy, a strona, która ich szuka, może odczytać oba.

Niektóre aplikacje VPN łatają tę lukę, kierując cały ruch na poziomie systemu operacyjnego albo dołączając rozszerzenie przeglądarki, które ogranicza WebRTC. Oba sposoby działają i oba trzeba sprawdzić, a nie zakładać — do tego właśnie służy ta strona. VPN, którego własna strona z testem wycieków mówi, że twoje połączenie jest chronione, nie jest niezależnym dowodem.

VPN włączony, Wi-Fi wciąż działadwa interfejsy, dwie odpowiedzi

Twój laptopVPN10.64.0.2Wi-Fi192.168.1.20TUNEL VPNSerwer VPN198.51.100.23Stronatwoje przeglądanieSerwer STUNRouter (NAT)Twój dostawca203.0.113.7WebRTC pyta przez obaTwój laptopVPN10.64.0.2Wi-Fi192.168.1.20TUNEL VPNSerwer VPN198.51.100.23Router (NAT)Twój dostawca203.0.113.7twoje przeglądanieStronaSerwer STUNWebRTC pyta przez oba

Co dostaje strona

  • 198.51.100.23srflxWidziany przez serwer STUNprzez VPNJuż widziany przez strony
  • 203.0.113.7srflxWidziany przez serwer STUNprzez Wi-Fi, poza tunelemNiewidziany przez strony

RFC 8828

Co łata lukę

  • Routing na poziomie systemuNic nie wychodzi poza tunel, więc serwer STUN może zobaczyć tylko adres VPN.
  • Rozszerzenie przeglądarki od VPNOgranicza WebRTC w przeglądarce, więc drugi interfejs nigdy nie jest pytany.
  • Potem sprawdź, nie zakładajUruchom ten test z włączonym VPN. Własna strona z testem wycieków od dostawcy VPN nie jest niezależnym dowodem.
Przypadek, który IETF opisuje w RFC 8828: VPN i system operacyjny kierują ruch przez więcej niż jeden interfejs, więc WebRTC znajduje publiczny adres VPN i, pod nim, adres dostawcy.

Host, server-reflexive i relay: który kandydat jest który?

Kandydat typu host to adres na twoim własnym komputerze. Kandydat typu server-reflexive to to, co zobaczył serwer STUN — zewnętrzny adres twojego NAT. Kandydat typu relay to adres serwera TURN, a nie twój.

To rozróżnienie ma znaczenie, a większość testów wycieków je pomija. Kandydat typu server-reflexive z twoim publicznym IPv4 zwykle niczego nowego nie mówi: to ten sam adres, który strona dostaje z połączenia, które i tak nawiązujesz. Kandydat typu host z adresem routowalnym to co innego — to adres samego komputera, podany stronie bezpośrednio. Identyfikuje ten komputer, a nie tylko router twojego domu, i zmienia się, gdy zmienia się sieć.

Strona pokazuje typ obok każdego adresu, razem z transportem, portem i powiązanym adresem, który podaje kandydat typu server-reflexive. Kandydat typu relay to własny adres serwera TURN i nic o tobie nie zdradza; ten test nie używa serwera TURN, więc pojawienie się takiego kandydata oznaczałoby, że skonfigurowało go coś innego na stronie.

Jeden kandydat, pole po polutak, jak dostaje go strona

  1. candidate:1467250027Foundation
  2. 1Komponent
  3. udpTransport
  4. 1686052607Priorytet
  5. 203.0.113.7Adres
  6. 54400Port
  7. typ srflxTyp
  8. raddr 0.0.0.0 rport 9Powiązany adres
  9. generation 0Rozszerzenie

Zastąpiony przez 0.0.0.0, port 9, tam gdzie adresy lokalne są maskowane

Cztery typy

  • typ hostNa tym komputerze

    Adres na jednym z twoich własnych interfejsów sieciowych.

    Prywatny jest maskowany. Routowalny to samo urządzenie: najpoważniejsze znalezisko.

    Najpoważniejszy, gdy routowalny

  • typ srflxWidziany przez serwer STUN

    Zewnętrzny adres twojego routera, tak jak zobaczył go serwer STUN.

    Zwykle adres, który strona ma już z twojego połączenia.

    Zwykle nic nowego

  • typ prflxWidziany przez drugą stronę

    Zewnętrzny adres twojego routera, tak jak zobaczyła go druga strona rozmowy.

    Znajdowany dopiero przy łączeniu z drugą stroną, więc test bez rozmowy nigdy go nie widzi.

    Tylko w trakcie rozmowy

  • typ relayWłasny adres serwera przekaźnikowego

    Adres serwera TURN, który przekazuje ruch za ciebie.

    Adres serwera, nie twój. Ten test nie używa serwera TURN, więc taki kandydat został tu skonfigurowany przez coś innego.

    Nic o tobie

Adres kandydata porównujemy z tym, co widzi strona; jego typ mówi, jak poważna jest różnica. Definicje z RFC 8445, sekcja 4.

Czym jest adres mDNS z .local i czy mnie chroni?

Nowoczesne przeglądarki zastępują twoje prywatne adresy losową nazwą zakończoną na .local, zanim zaoferują je stronie. To działa — dla adresów prywatnych. Nigdy nie miało ukrywać adresu publicznego.

Chrome robi to domyślnie od wersji 76, a Firefox ma media.peerconnection.ice.obfuscate_host_addresses ustawione na true: zamiast 192.168.1.20 strona dostaje coś w rodzaju 8b7f4e2a-….local, co poza twoją siecią nikomu nic nie mówi. Safari idzie dalej: dopóki strona nie ma dostępu do kamery lub mikrofonu, w ogóle nie oferuje kandydatów typu host. Test powyżej rozpoznaje takie losowe nazwy i pokazuje je jako działającą ochronę, a nie jako znalezisko.

Szkic IETF, który to definiuje, mówi wprost, czego ten mechanizm nie robi: „adres, który jest już widoczny w internecie, nie musi być chroniony przez mDNS, bo serwer WWW może go bez trudu zaobserwować”. Kandydat typu server-reflexive nadal niesie więc twoje publiczne IPv4, a — co wielu zaskakuje — komputer z routowalnym adresem IPv6 nadal może zaoferować ten adres jako kandydata typu host. Jest jeszcze jedna luka, o której warto wiedzieć: Chrome wyłącza ochronę dla każdej strony, która ma już dostęp do kamery lub mikrofonu, więc strona do rozmów wideo, z której już korzystasz, widzi twoje prawdziwe adresy lokalne.

Co zastępuje nazwa .locali czego nie rusza

Co ma twoja przeglądarka

candidate:3442447574 1 udp 2122260223 192.168.1.20 54400 typ host generation 0

Co dostaje strona

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0

Co każda przeglądarka robi domyślnie

  • ChromeOd wersji 76, sierpień 2019
  • Firefoxmedia.peerconnection.ice.obfuscate_host_addresses = true
  • SafariBrak kandydatów typu host, dopóki strona nie ma dostępu do kamery lub mikrofonu

Mechanizm to szkic IETF, nigdy nie opublikowany jako RFC; ostatnia wersja: grudzień 2021. draft-ietf-mmusic-mdns-ice-candidates-03

Adres, który WebRTC mógłby zaoferowaćZamaskowany?
192.168.1.20Twoje prywatne IPv4 jako kandydat typu hostZamaskowanyZastąpione losową nazwą: strona nie dowiaduje się niczego o twojej sieci.
203.0.113.7Twoje publiczne IPv4 jako kandydat od serwera STUNWidocznyJuż publiczne, więc zostaje. Zastępowany jest tylko powiązany adres.
2001:db8:4a1f:7c00::1cRoutowalne IPv6 jako kandydat typu hostWidocznyTeż publiczne, więc maskowanie nigdy nie miało go obejmować.
2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07Tymczasowy adres IPv6Może być widocznySzkic pozwala przeglądarce z wyboru zostawić go niezamaskowanym.
192.168.1.20Każdy adres lokalny na stronie z dostępem do kamery lub mikrofonuMaskowanie wyłączoneChrome wyłącza tam maskowanie: strona widzi twoje prawdziwe adresy lokalne.
Maskowanie ukrywa to, co wie tylko twoja własna sieć. To, co strona i tak mogłaby zobaczyć, zostawia bez zmian: celowo, a nie przez pomyłkę.

Dlaczego IPv6 to wyciek, który zostaje

Globalny adres IPv6 należy do jednego komputera, a nie do całego domu za NAT, i mDNS celowo go nie rusza. To najbardziej identyfikująca rzecz, jaką WebRTC wciąż oddaje.

Przy IPv4 NAT twojego domowego routera chowa wszystko za jednym adresem, więc kandydat typu server-reflexive mówi stronie mniej więcej to, co mówi jej już twoje zwykłe połączenie. IPv6 nie ma NAT: każde urządzenie ma własny routowalny adres, a kandydat typu host, który go niesie, wskazuje urządzenie, a nie łącze. Jeśli twój VPN przenosi tylko IPv4 — a wiele tak robi — ten adres IPv6 jest do tego całkowicie poza tunelem.

Pomagają rozszerzenia prywatności, bo tymczasowy adres IPv6 regularnie się zmienia. Nie ukrywają go jednak: szkic mDNS mówi, że takie adresy mogą zostać niezamaskowane. Test powyżej uznaje routowalnego kandydata IPv6 typu host za najpoważniejsze znalezisko, jakie może zrobić, a Test IPv6 powie ci, czy twoje połączenie w ogóle ma IPv6.

Kogo wskazuje adreste same trzy urządzenia, dwa razy

RouterIPv4, za NATIPv6, bez NAT
Laptop192.168.1.202001:db8:4a1f:7c00::1c
Telefon192.168.1.212001:db8:4a1f:7c00::2b
TV192.168.1.222001:db8:4a1f:7c00::3d
Router203.0.113.7Jeden adres na całe łączeJeden adres na urządzenie

Globalny adres IPv6 w dwóch połowach

2001:db8:4a1f:7c00Prefiks sieci: twoje łącze /64:8d3:5e2f:a41c:9b07Identyfikator interfejsu: to urządzenie

  • Stały2001:db8:4a1f:7c00::1c
  • Tymczasowy: zmienia się2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07

VPN, który przenosi tylko IPv4

  • IPv4198.51.100.23W tunelu
  • IPv62001:db8:4a1f:7c00::1cPoza tunelem
Za NAT w IPv4 cały dom dzieli jeden adres; w IPv6 każde urządzenie ma własny, a kandydat typu host podaje go bezpośrednio. Test uznaje routowalnego kandydata IPv6 typu host za najpoważniejsze znalezisko.

Jak zatrzymać wyciek WebRTC w każdej przeglądarce

Firefox ma ustawienia, które działają. Edge ma zasadę dla firm. Safari już ogranicza kandydatów. Rozszerzenia, które ludzie wciąż polecają, nic już nie dają.

W Firefoksie about:config → media.peerconnection.ice.default_address_only wysyła tylko jeden adres zamiast wszystkich, a media.peerconnection.ice.relay_only ogranicza zbieranie do kandydatów typu relay, co psuje bezpośrednie połączenia, ale ukrywa wszystko inne. Oba są domyślnie wyłączone; maskowanie mDNS adresów prywatnych (media.peerconnection.ice.obfuscate_host_addresses) jest już włączone. W Edge zasada WebRtcLocalIpsAllowedUrls decyduje, które strony mogą widzieć adresy lokalne; własna dokumentacja Microsoftu zaznacza, że dodanie strony „osłabia ochronę”. Chrome nie ma podobnego ustawienia dla zwykłego użytkownika. Safari bez pytania ogranicza najwięcej: bez dostępu do kamery lub mikrofonu WebKit oferuje tylko kandydatów typu server-reflexive i relay, a kandydatów typu host wcale.

Dwie rzeczy, które wciąż często się poleca, są martwe. Opcję „Prevent WebRTC from leaking local IP addresses” w uBlock Origin usunięto w wersji 1.38 z adnotacją, że „nie jest już potrzebna w nowoczesnych przeglądarkach, z wyjątkiem Firefoksa na Androida”. A rozszerzenie Google WebRTC Network Limiter, wciąż widoczne w sklepie, nie może działać: rozszerzenia Manifest V2 są wyłączone dla wszystkich użytkowników Chrome od Chrome 138 w lipcu 2025 roku. Jeśli jakaś strona każe ci zainstalować jedno z nich, nie była aktualizowana od lat.

Co oferuje każda przeglądarkasprawdzone w dokumentacji każdego producenta

  • FirefoxUstawienia, które działają

    about:config

    • media.peerconnection.ice.obfuscate_host_addressesDomyślnie trueMaskuje adresy prywatne. Już włączone.
    • media.peerconnection.ice.default_address_onlyDomyślnie falseUstaw na trueWysyła jeden adres zamiast wszystkich.
    • media.peerconnection.ice.relay_onlyDomyślnie falseUstaw na trueTylko kandydaci typu relay. Ukrywa najwięcej i psuje bezpośrednie połączenia.

  • EdgeZasada dla firm

    WebRtcLocalIpsAllowedUrls

    Lista stron, które mogą widzieć adresy lokalne.

    Nieskonfigurowana: adresy lokalne pozostają zamaskowane.

    Uwaga samego Microsoftu: dodanie strony osłabia ochronę.

    Windows i macOS, od wersji 80

  • ChromeBrak ustawienia

    Brak ustawienia dla zwykłego użytkownika.

    Adresy prywatne domyślnie maskowane od wersji 76.

    Nie na stronie z dostępem do kamery lub mikrofonu.

  • SafariŚcisłe ustawienia domyślne

    Bez dostępu do kamery lub mikrofonu tylko kandydaci od serwera STUN i typu relay.

    Żadnych kandydatów typu host.

Rady, które już nie działają

  • Prevent WebRTC from leaking local IP addresses

    uBlock Origin

    Usunięta w wersji 1.38

    Według uBlock Origin niepotrzebna w nowoczesnych przeglądarkach, z wyjątkiem Firefoksa na Androida.

  • WebRTC Network Limiter

    Google · Chrome Web Store

    Wciąż w sklepie, nie może działać

    Rozszerzenia Manifest V2 są wyłączone dla wszystkich użytkowników Chrome od Chrome 138 (lipiec 2025).

Dokumentacja każdego producenta, przeczytana w dniu sprawdzenia tej strony. Strona, która wciąż każe ci zainstalować jedno z dwóch ostatnich, nie była aktualizowana od lat.

Wyciek WebRTC, wyciek DNS i wyciek IP: czym się różnią?

To trzy różne sposoby na obejście VPN. Wyciek WebRTC pokazuje adres; wyciek DNS pokazuje, kto odpowiada na twoje zapytania; wyciek IP to prosty przypadek, w którym twój ruch w ogóle nie wszedł do tunelu.

Wyciek WebRTC dotyczy adresów, które przeglądarka sama podaje przez funkcję zaprojektowaną po to, by je podawać. Wyciek DNS dotyczy tego, który resolver odpowiada na twoje zapytania: twój ruch może iść przez VPN, a zapytania nadal trafiać do resolvera twojego dostawcy, który w ten sposób poznaje każdą stronę, którą odwiedzasz. Nasz Test Wycieku DNS sprawdza to własnym serwerem nazw, więc widzi dokładnie, które resolvery pytały.

Wyciek IP w ogólnym sensie to adres, który strona po prostu widzi; sprawdzisz go na stronach Jaki Jest Mój IP lub Jaki Jest Mój ISP. Po każdej zmianie VPN uruchom wszystkie trzy: zawodzą niezależnie od siebie, a czysty wynik jednego nic nie mówi o pozostałych.

Trzy drogi obok VPNkażda zawodzi osobno

TyTUNEL VPNPrzez tunelWyciek IP · twój ruchStrona203.0.113.7Wyciek DNS · twoje zapytaniaResolver twojego dostawcy203.0.113.53Wyciek WebRTC · twoje adresySkrypt strony203.0.113.7TyTUNEL VPNPrzez tunelWyciek IPtwój ruchStrona203.0.113.7Wyciek DNStwoje zapytaniaResolver twojego dostawcy203.0.113.53Wyciek WebRTCtwoje adresySkrypt strony203.0.113.7

  • Wyciek IP

    Co wyciekaAdres, który niesie każde żądanie

    Kto się dowiadujeKażda strona, którą odwiedzasz

    Sprawdź za pomocąJaki Jest Mój IPJaki Jest Mój ISP

  • Wyciek DNS

    Co wyciekaKtóry resolver odpowiada na twoje zapytania

    Kto się dowiadujeTwój dostawca, dla każdej sprawdzanej strony

    Sprawdź za pomocąTest Wycieku DNS

  • Wyciek WebRTC

    Co wyciekaAdresy, które przeglądarka oferuje stronie

    Kto się dowiadujeKażda strona, która zapyta, bez pytania o zgodę

    Sprawdź za pomocąTest Wycieku WebRTC

Zawodzą niezależnie od siebie: czysty wynik jednego nic nie mówi o dwóch pozostałych. Po każdej zmianie VPN uruchom wszystkie trzy.

Dlaczego ten test pyta więcej niż jeden serwer STUN

Bo „żaden adres nie wrócił” i „żaden adres nie istnieje” wyglądają tak samo, a tylko jedno z nich jest dobrą wiadomością.

Firmowa zapora, restrykcyjny VPN albo sieć blokująca UDP mogą sprawić, że serwer STUN nie odpowie. Test, który pyta jednego dostawcę i nic nie widzi, niczego się nie dowiedział — a mimo to zwykle pokazuje zielonego ptaszka. Ten pyta udokumentowany punkt końcowy STUN Cloudflare i serwer Google, raportuje każdy osobno i pokazuje „Nie przetestowano”, gdy żaden nie odpowiedział.

Wybór serwerów jest celowy. Cloudflare publikuje stun.cloudflare.com:3478 jako część produktu, więc są warunki do przeczytania. stun.l.google.com:19302 od Google jest udokumentowany tylko jako domyślny serwer własnego walidatora WebRTC Google, bez opublikowanych warunków, więc służy jako druga opinia, a nie jedyne źródło. Serwer Twilio wymaga danych logowania, a Mozilla nie dokumentuje żadnego publicznego serwera STUN, choć często przypisuje się jej taki serwer.

Publiczne serwery STUNi które z nich pyta ten test

  • CloudflarePytany

    stun.cloudflare.com:3478

    Udokumentowany punkt końcowy, część produktu, z warunkami do przeczytania.

  • GooglePytany, jako druga opinia

    stun.l.google.com:19302

    Udokumentowany tylko jako domyślny serwer własnego walidatora WebRTC Google. Brak opublikowanych warunków.

  • TwilioNiepytany

    global.stun.twilio.com:3478

    Wymaga danych logowania z API Twilio: nie jest otwarty dla każdej strony.

  • MozillaNiepytany

    Brak publicznego serwera

    Nie dokumentuje żadnego publicznego serwera STUN. Firefox w ogóle nie ma domyślnych serwerów ICE.

Gdy serwer nic nie mówi

CloudflareGoogle
OdpowiedziałOdpowiedziałWynik jest ważny
OdpowiedziałMilczyWynik jest ważny; milczący serwer jest wymieniony
MilczyOdpowiedziałWynik jest ważny; milczący serwer jest wymieniony
MilczyMilczyNie przetestowano
Dwaj operatorzy, pytani osobno. Jeden milczący serwer zostaje wymieniony, a wynik jest ważny; gdy nie odpowiada żaden, niczego nie zmierzono, a test mówi to wprost, zamiast pokazywać zaliczenie.

Czy mój adres IP to dane osobowe?

W UE dynamiczny adres IP jest daną osobową dla operatora strony, który mógłby cię zidentyfikować dzięki informacjom, jakie ma dostawca internetu. Trybunał Sprawiedliwości orzekł tak w 2016 roku.

Chodzi o sprawę Breyer, C-582/14, rozstrzygniętą 19 października 2016 roku, a komunikat prasowy Trybunału streszcza ją tak: „Dynamiczny adres protokołu internetowego osoby odwiedzającej stanowi dla podmiotu prowadzącego witrynę dane osobowe, gdy ten podmiot dysponuje środkami prawnymi umożliwiającymi mu zidentyfikowanie danej osoby odwiedzającej dzięki dodatkowym informacjom, jakimi dysponuje dostawca dostępu do Internetu osoby odwiedzającej”. Ten sam komunikat zauważa, że strona może mieć uzasadniony interes w przechowywaniu części tych danych, by bronić się przed atakami.

Właśnie dlatego ta strona wykonuje swoją pracę w twojej przeglądarce. Kandydaci ICE są zbierani przez twoją przeglądarkę, porównywani w twojej przeglądarce i pokazywani tobie; żaden adres znaleziony przez WebRTC nie trafia do nas, więc nie ma z niego niczego, co moglibyśmy przechować, przekazać albo zgubić. Podczas testu możesz obserwować kartę Sieć w narzędziach deweloperskich.

Wyrok w sprawie BreyerTrybunał Sprawiedliwości Unii Europejskiej

C-582/14Breyer v Bundesrepublik Deutschland19 października 2016

  1. Operator stronyadres i godzina z jego logów203.0.113.7 · 14:02:37
  2. środki prawne, by to uzyskać
  3. Dostawca dostępu do internetukto używał tego adresu w tym czasie203.0.113.7 · 14:02:37 →
  4. Dane osobowe dla tego operatora

Komunikat prasowy Trybunału: strona może mieć uzasadniony interes w przechowywaniu części tych danych, by bronić się przed atakami.

Na tej stronie

Twoja przeglądarka

  1. Zbiera
  2. Klasyfikuje
  3. Porównuje
  4. Pokazuje
  • Widzą twój publiczny adres, jak przy każdej rozmowie
  • dnsrobot.netŻaden kandydat nie jest wysyłany
Sprawa C-582/14, Breyer. Dynamiczny adres IP jest daną osobową dla operatora strony, który ma środki prawne, by zidentyfikować cię dzięki danym dostawcy. Ta strona trzyma kandydatów w twojej przeglądarce.

Test wycieku WebRTC: pytania i odpowiedzi

Czym jest wyciek WebRTC?

WebRTC to funkcja przeglądarki, na której działają rozmowy wideo. Żeby połączyć dwie osoby bezpośrednio, zbiera każdy adres, pod którym da się dotrzeć do twojego komputera, i oferuje je stronie bez pytania o zgodę. Wyciekiem staje się to wtedy, gdy któryś z tych adresów jest tym, który ukrywasz — zwykle twoim prawdziwym adresem przy włączonym VPN, bo WebRTC może pytać o każdy interfejs sieciowy, a nie tylko o ten, którego używa twoje przeglądanie.

Jak przetestować wyciek WebRTC?

Uruchom test na tej stronie. Pyta trzy serwery STUN dwóch operatorów, wypisuje każdy adres, który podał WebRTC, z informacją, czym jest każdy z nich, i porównuje te routowalne z adresem, który strona i tak widzi. Jeśli używasz VPN, uruchom go raz z wyłączonym VPN i raz z włączonym: różnica między tymi dwoma testami jest odpowiedzią.

Czy VPN zatrzymuje wyciek WebRTC?

Sam z siebie nie. VPN zmienia to, dokąd idzie twój ruch, ale WebRTC może pytać system operacyjny, jakie interfejsy istnieją, a fizyczne połączenie zwykle wciąż jest jednym z nich. Sam tekst IETF mówi, że WebRTC może odkryć „nie tylko publiczny adres VPN, ale też publiczny adres dostawcy internetu, przez którego działa VPN”. Niektóre aplikacje VPN łatają tę lukę; ten test powie ci, czy twoja to zrobiła.

Co oznacza adres .local w wynikach?

To mDNS i to dobra wiadomość. Nowoczesne przeglądarki zastępują twoje prywatne adresy losową nazwą zakończoną na .local, zanim zaoferują je stronie, więc strona nie dowiaduje się z nich niczego o twojej sieci domowej. Chrome robi to od wersji 76, a Firefox robi to samo; Safari idzie dalej i w ogóle nie oferuje kandydatów typu host, dopóki strona nie ma dostępu do kamery lub mikrofonu. Test oznacza takie adresy jako działającą ochronę, a nie jako znalezisko.

Jeśli mDNS ukrywa moje lokalne IP, czy to mnie chroni?

Częściowo. mDNS zaprojektowano, by ukrywał adresy prywatne, i wyraźnie nie po to, by ukrywał adres już publiczny — mówi to szkic IETF, który go definiuje. Twoje publiczne IPv4 nadal pojawia się jako kandydat typu server-reflexive, a komputer z routowalnym adresem IPv6 nadal może podać ten adres bezpośrednio. Chrome wyłącza też ochronę dla każdej strony, która ma już dostęp do kamery lub mikrofonu.

Dlaczego test czasem pokazuje „Nie przetestowano”?

Bo taka jest prawda. Jeśli WebRTC jest wyłączony, zablokowany przez rozszerzenie lub zasadę albo żaden serwer STUN nie odpowiedział — zapora, restrykcyjny VPN, sieć blokująca UDP — to niczego nie zmierzono. Większość narzędzi pokazuje w takiej sytuacji zielonego ptaszka, a to najbardziej myląca rzecz, jaką może zrobić test wycieków. Ten mówi, co się stało, i wymienia serwery, które milczały.

Jak wyłączyć WebRTC w Firefoksie?

Udokumentowane ustawienia Firefoksa ograniczają WebRTC, ale go nie wyłączają. W about:config ustawienie media.peerconnection.ice.default_address_only wysyła jeden adres zamiast wszystkich, a media.peerconnection.ice.relay_only ogranicza zbieranie do kandydatów typu relay: to ukrywa najwięcej, ale psuje bezpośrednie połączenia. Maskowanie adresów prywatnych, media.peerconnection.ice.obfuscate_host_addresses, jest domyślnie włączone. Po każdej zmianie uruchom test ponownie, żeby zobaczyć, co ci dała.

Jak zatrzymać wycieki WebRTC w Chrome?

Chrome nie daje zwykłemu użytkownikowi żadnego ustawienia; maskowanie mDNS adresów prywatnych jest domyślnie włączone i to jest cała ochrona, jaką masz. Edge, który korzysta z tego samego silnika co Chrome, ma zasadę dla firm WebRtcLocalIpsAllowedUrls. Wciąż często polecane rozszerzenia nie działają: uBlock Origin usunął swoją opcję WebRTC w wersji 1.38, a WebRTC Network Limiter od Google nie może działać, odkąd w Chrome 138 wyłączono Manifest V2.

Czym różni się kandydat typu host od kandydata typu server-reflexive?

Kandydat typu host to adres na twoim własnym komputerze. Kandydat typu server-reflexive to to, co zobaczył serwer STUN — zewnętrzny adres twojego NAT, zwykle ten sam, który strona ma już z twojego połączenia. Routowalny kandydat typu host to poważniejsze znalezisko, bo jest adresem samego urządzenia, a w IPv6 identyfikuje urządzenie, a nie cały dom.

Czy wyciek WebRTC to to samo co wyciek DNS?

Nie. Wyciek WebRTC ujawnia adres; wyciek DNS ujawnia, który resolver odpowiada na twoje zapytania, przez co twój dostawca poznaje każdą stronę, którą odwiedzasz, nawet gdy sam ruch idzie przez VPN. Zawodzą niezależnie od siebie, więc czysty wynik jednego nic nie mówi o drugim. Po każdej zmianie VPN uruchom też nasz Test Wycieku DNS.

Czy ten test wysyła gdzieś mój adres IP?

Tylko tam, gdzie widziałaby go każda strona. Twoja przeglądarka łączy się z serwerami STUN, jak każda rozmowa wideo: na tym polega test. Żeby ustalić, co widzi strona internetowa, nasza strona pyta ipify.org i nasz własny serwer o twoje adresy i ich sieci, tak jak robi to Test Wycieku DNS. Adresy znalezione przez WebRTC zostają w twojej przeglądarce: żaden nie trafia do nas. Otwórz kartę Sieć w narzędziach deweloperskich i patrz, jak przebiega test.

Czy mój adres IP to dane osobowe w świetle prawa UE?

Dla operatora strony w UE dynamiczny adres IP jest daną osobową, gdy ten operator ma środki prawne, by zidentyfikować cię dzięki informacjom, jakie ma dostawca internetu. Tak orzekł Trybunał Sprawiedliwości w sprawie Breyer, C-582/14, w październiku 2016 roku. To jeden z powodów, dla których ta strona przeprowadza część testu dotyczącą WebRTC w twojej przeglądarce, a nie na naszym serwerze.

Czegoś brakuje?Zaproponuj funkcję lub nowe narzędzie

Powiązane narzędzia