Co ujawnia odpowiedź STUN, gdy VPN działa na routerze
Adres tunelu routera nie jest adresem lokalnym przeglądarki. Prześledź, jak każde żądanie jest trasowane i tłumaczone, zanim przeczytasz, co raportuje reflektor.
Gdy tunel mieszka na routerze, maszyna uruchamiająca przeglądarkę nie ma żadnego interfejsu tunelu. Zapytaj tę maszynę o jej adresy lokalne, a dostaniesz prywatny adres LAN i pętlę zwrotną, nic, co przypominałoby adres VPN. Mimo to serwer STUN po drugiej stronie nadal może zgłosić coś istotnego o ścieżce, a to, co zgłasza, zależy całkowicie od tego, jak to konkretne żądanie zostało trasowane i przetłumaczone.
To właśnie ta część zasługuje na zwolnienie. „Przeglądarka nie posiada adresu VPN” odpowiada na pytanie o interfejsy, podczas gdy adres odbity jest odpowiedzią o ścieżce przez tłumaczenie. Mieszanie obu daje pewne siebie wnioski o ujawnieniu, których dowody nie wspierają.
Dwa urządzenia, dwa zestawy interfejsów
W konfiguracji opartej na routerze tunel kończy się na routerze, a klient LAN wysyła zwykły ruch do swojej bramy domyślnej. Lista interfejsów klienta pozostaje krótka: jeden adres prywatny, może drugi dla innej sieci, i pętla zwrotna. Ryzyko nie polega na tym, że któryś z nich przypadkiem jest adresem tunelu; polega na tym, że żądanie wychodzi ścieżką, której nie wybrałeś.
Zapytaj klienta jaką ścieżkę obierze konkretny cel, zamiast pytać, jakie interfejsy istnieją. Odpowiedź wskazuje bramę i adres źródłowy, którego użyłoby jądro, a to już jest bardziej pouczające niż jakikolwiek spis adresów.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsZakresy dokumentacyjne są dobrymi celami testów, ponieważ nigdy nie rozwiązują się na prawdziwą usługę. Porównaj to, co mówi klient, z tym, co mówi router, i każdą rozbieżność potraktuj jako dowód, że trasowanie polityk, reguła tunelu dzielonego lub druga trasa domyślna robi coś, czego nie uwzględniłeś.
Co wolno powiedzieć odpowiedzi Binding
RFC 8489 definiuje żądanie i odpowiedź Binding, w których serwer raportuje zaobserwowany adres transportowy źródła dla tego żądania. To stwierdzenie o jednej piątce w jednej chwili, a nie spis interfejsów klienta. Dlatego wszystko, co interesujące, dzieje się między klientem a punktem obserwacji.
Tę lukę wypełnia trasowanie i tłumaczenie. Router, który wykonuje NAT źródłowy na ruchu wychodzącym, zastępuje prywatne źródło klienta własnym adresem na interfejsie wychodzącym. Jeśli tym interfejsem jest tunel, reflektor widzi adres tunelu. Jeśli pakiet został wyłączony z tunelu, reflektor widzi to, co wytworzyło tłumaczenie WAN. Ten sam klient, ten sam reflektor, inna odpowiedź.
Trzy przypadki, które wyglądają podobnie i nie są
Przydatne rozróżnienie nie dotyczy publicznego i prywatnego, ale tego, który punkt egzekwowania obsłużył pakiet. Przejdź przypadki z otwartymi własnymi tabelami routera, ponieważ jedna przeglądarka może wytworzyć wszystkie trzy w zależności od reguły, o której zapomniałeś, że ją napisałeś.
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
Tylko drugi przypadek narusza wymóg, by pewien ruch nigdy nie wychodził bezpośrednio, i tylko pierwszy oraz trzeci ujawniają identyfikator po stronie tunelu. Żaden z trzech wierszy nie jest twierdzeniem o zachowaniu konkretnego dostawcy: czy prywatny reflektor jest w ogóle osiągalny, zależy od trasowania, dozwolonych adresów IP drugiej strony i polityki zapory na obu końcach.
Posiadanie konta u tego samego dostawcy niczego z tego nie dowodzi. Warto też pamiętać, że trasowane żądanie może zachować źródło LAN klienta, jeśli nic go nie tłumaczy, więc pole źródła trzeba prześledzić, a nie zakładać z diagramu topologii.
Zbieranie nie jest wybieraniem
WebRTC zbiera adresy kandydatów do wypróbowania, a kandydat, który pojawia się na liście diagnostycznej, może nigdy nie przenosić mediów. Czytanie listy jako „oto czego nauczyła się druga strona” przecenia dowody. Wybrana para to ta, która faktycznie przenosiła sesję, i znajduje się w innym polu.
Sprawdzian wyjścia HTTPS odpowiada na jeszcze jedno pytanie: adres źródłowy, który serwer webowy widział dla tego żądania. To przydatna kontrola krzyżowa właśnie dlatego, że używa innego protokołu i często innego celu niż reflektor UDP, a rozbieżność między nimi zwykle wskazuje na regułę trasowania, a nie na błąd.
Ustal politykę, potem czytaj odpowiedź
Zapisz intencję przed testowaniem: który ruch musi korzystać z tunelu, który może wychodzić bezpośrednio, które rodziny adresów są w zakresie i co powinno się stać, gdy tunel jest wyłączony. Bez tej linii bazowej każde obserwacja jest niejednoznaczna, bo nie można oddzielić wycieku od ścieżki, którą świadomie dopuściłeś.
Potem zadawaj jedno pytanie na raz. Jaką ścieżkę obiera ten cel. Jaki adres raportuje ten reflektor. Którą parę kandydatów wybrała sesja. Trzymaj odpowiedzi obok polityki i opatruj je datą, ponieważ aktualizacja firmware może zmienić zachowanie domyślne w sposób, który po cichu unieważnia zeszłoroczny wniosek.
Router nadal jest mocnym punktem egzekwowania, ponieważ widzi ruch, którego klient nie może ominąć bez ponownej konfiguracji samego siebie. To nie jest obietnica, że każde pole w każdym protokole aplikacji niczego nie ujawnia, i nie zastępuje zapisania ścieżek, które zdecydowałeś się dopuścić.