Co prozradí odpověď STUN, když VPN běží na routeru
Adresa tunelu na routeru není místní adresa prohlížeče. Sledujte, jak je každý požadavek směrován a překládán, než začnete číst, co reflektor hlásí.
Když tunel žije na routeru, počítač, na kterém běží prohlížeč, nemá vůbec žádné rozhraní tunelu. Zeptejte se toho počítače na místní adresy a dostanete privátní adresu LAN a adresu zpětné smyčky, nic, co by připomínalo adresu VPN. Přesto STUN server na druhé straně může o cestě hlásit něco smysluplného, a to, co hlásí, závisí zcela na tom, jak byl tento konkrétní požadavek směrován a přeložen.
Právě u této části stojí za to se zastavit. „Prohlížeč nevlastní adresu VPN“ odpovídá na otázku o rozhraních, zatímco odražená adresa je odpovědí o cestě přes překlad. Slučování obojího vede k sebevědomým závěrům o vyzrazení, které důkazy nepodporují.
Dvě zařízení, dvě sady rozhraní
V uspořádání s routerem tunel končí na routeru a klient LAN posílá běžný provoz na svou výchozí bránu. Seznam rozhraní klienta zůstává krátký: jedna privátní adresa, možná druhá pro jinou síť, a zpětná smyčka. Riziko není v tom, že by jedna z nich byla náhodou adresou tunelu; riziko je v tom, že požadavek vychází cestou, kterou jste nezvolili.
Zeptejte se klienta jakou cestu by konkrétní cíl zaujal místo dotazu, jaká rozhraní existují. Odpověď pojmenuje bránu a zdrojovou adresu, kterou by jádro použilo, což je už informativnější než jakýkoli seznam adres.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsDokumentační rozsahy jsou dobré testovací cíle, protože se nikdy nepřeloží na skutečnou službu. Porovnejte, co říká klient, s tím, co říká router, a každý nesoulad berte jako důkaz, že směrování podle zásad, pravidlo rozděleného tunelu nebo druhá výchozí trasa dělá něco, co jste nezohlednili.
Co smí odpověď Binding říct
RFC 8489 definuje požadavek a odpověď Binding, při nichž server hlásí zdrojovou transportní adresu, kterou u tohoto požadavku pozoroval. Je to tvrzení o jedné pětici v jednom okamžiku, ne soupis rozhraní klienta. Vše zajímavé se proto odehrává mezi klientem a bodem pozorování.
Tuto mezeru vyplňují směrování a překlad. Router, který odchozí provoz překládá zdrojovým NAT, nahradí privátní zdroj klienta svou vlastní adresou na odchozím rozhraní. Je-li tím rozhraním tunel, reflektor vidí adresu tunelu. Je-li paket z tunelu vyloučen, reflektor vidí, co vytvořil překlad WAN. Stejný klient, stejný reflektor, jiná odpověď.
Tři případy, které vypadají stejně a nejsou
Užitečný rozdíl není veřejné proti privátnímu, ale to, který vynucovací bod paket zpracoval. Projděte případy s otevřenými vlastními tabulkami routeru, protože jeden prohlížeč může vytvořit všechny tři podle pravidla, které jste zapomněli, že jste napsali.
| 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 |
Jen druhý případ porušuje požadavek, aby určitý provoz nikdy nevycházel přímo, a jen první a třetí prozrazují identifikátor na straně tunelu. Žádný ze tří řádků není tvrzením o chování konkrétního poskytovatele: zda je privátní reflektor vůbec dosažitelný, závisí na směrování, povolených IP adresách protistrany a politice firewallu na obou koncích.
Mít účet u stejného poskytovatele nic z toho neprokazuje. Stojí za to pamatovat i to, že směrovaný požadavek si může ponechat LAN zdroj klienta, pokud jej nic nepřekládá, takže pole zdroje je třeba vysledovat, ne odhadovat z diagramu topologie.
Sbírání není vybírání
WebRTC shromažďuje kandidátní adresy k vyzkoušení a kandidát, který se objeví v diagnostickém seznamu, nemusí nikdy přenášet média. Číst seznam jako „tohle se protistrana dozvěděla“ přeceňuje důkazy. Vybraný pár je to, co sezení skutečně přenášelo, a žije v jiném poli.
Kontrola výstupu přes HTTPS odpovídá na další otázku: zdrojovou adresu, kterou webový server u tohoto požadavku viděl. Je to užitečná křížová kontrola právě proto, že používá jiný protokol a často jiné místo určení než UDP reflektor, a nesoulad mezi nimi obvykle ukazuje na pravidlo směrování, ne na chybu.
Rozhodněte zásady, pak čtěte odpověď
Zapište záměr před testováním: který provoz musí používat tunel, který smí vycházet přímo, které rodiny adres jsou v rozsahu a co se má stát, když je tunel mimo provoz. Bez této základny je každé pozorování nejednoznačné, protože nedokážete oddělit únik od cesty, kterou jste vědomě povolili.
Pak se ptejte po jedné otázce. Jakou cestu tento cíl zaujme. Jakou adresu tento reflektor hlásí. Který kandidátní pár sezení zvolilo. Odpovědi držte vedle zásad a datujte je, protože aktualizace firmwaru může změnit výchozí chování způsoby, které tiše zneplatní loňský závěr.
Router je stále silný vynucovací bod, protože vidí provoz, který klient nemůže obejít, aniž by překonfiguroval sám sebe. Není to slib, že každé pole v každém aplikačním protokolu nic neprozradí, a není to náhrada za zapsání cest, které jste se rozhodli povolit.