Jakou zdrojovou adresu vidí STUN s VPN na routeru?

Otázka vypadá jako jedno vyhledání a ve skutečnosti jde o tři rozhodnutí. Kterou trasu binding request zvolí, jaký zdroj jádro pro tuto trasu vybere a zda něco cestou tento zdroj přepíše. Změňte jedno z nich a adresa, kterou server STUN hlásí, se změní s ním. Proto tvrzení, že VPN sedí na routeru, samo o sobě neříká téměř nic.

Rozhodnutí stojí na třech faktech

Za prvé trasa: pravidla politiky a směrovací tabulka rozhodují, zda požadavek odejde tunelem nebo běžným WAN, a vyloučený cíl zvolí druhou cestu i při aktivním tunelu. Za druhé zdroj: jádro vybere zdroj pro zvolenou trasu a tato volba závisí na preferovaném zdroji trasy a na každém pravidle, které odpovídalo. Za třetí překlad: NAT cestou nahradí zvolený zdroj. Odražená adresa je součinem všech tří, nikoli vlastností tunelu.

Změňte jedno ze tří a odpověď se změní, zatímco každá komponenta ve svém vlastním logu stále vypadá zdravě. To je obvyklý důvod, proč tato diagnóza uvízne.

Zapište tři fakta pro tok, který testujete, než začnete. Rozhraní, trasa a pravidlo překladu stačí k předpovědi výsledku a právě předpověď dělá z překvapení informativní věc. Pokud nedokážete jedno ze tří vyplnit, je tato mezera skutečným zjištěním.

Sledujte jeden binding request po cestě

Binding request STUN žádá server, aby nahlásil pozorovanou zdrojovou transportní adresu. Odpověď popisuje cestu, kterou požadavek prošel, nikoli inventář rozhraní na klientském stroji. Dva požadavky po dvou cestách poctivě nahlásí dvě různé adresy.

Čtěte tu tabulku jako soubor podmínek, ne jako menu poskytovatelů. Prostřední řádek vyžaduje, aby byl soukromý reflektor dosažitelný pod vlastním směrováním a peer politikou tunelu; to je konfigurační fakt, který můžete ověřit, a ne něco, co implikuje úroveň účtu. Spodní řádek je obvykle ten, na kterém záleží pro politiku, protože tento provoz měl zůstat v tunelu. Mezi nimi leží běžný případ, kdy výstup překládá a reflektor vidí jen výstup.

Hostitelské kandidáty a serverově reflexivní kandidáty vznikají z různých mechanismů, takže seznam kandidátů neříká, kterou cestu média skutečně použila. Čtěte vybranou dvojici, ne log shromažďování, když chcete vědět, kam relace šla.

Čím adresa tunelu routeru není

Adresa tunelu přidělená routeru patří rozhraní na routeru. Prohlížeč na hostiteli v LAN má vlastní adresy rozhraní a žádný přímý pohled na tunelové rozhraní routeru. Když se s oběma zachází jako se zaměnitelnými, vznikají sebevědomé nesprávné odpovědi na to, co se webová stránka může dozvědět.

Předávání je to, co je spojuje. Požadavek prochází routerem jako směrovaný provoz a jeho zdrojem je to, co vytvořily směrování a překlad.

Pokud tunelová cesta zachovává zdroj z LAN, soukromý reflektor se může dozvědět tuto adresu LAN, což je skutečné prozrazení a jiné než adresa tunelu. Pokud cesta překládá na adresu tunelu, reflektor se místo toho dozví adresu tunelu. Oba výsledky jsou slučitelné se stejným prohlížečem na stejném hostiteli, a proto musí být pozorování svázáno s konkrétním tokem. Zeptejte se jádra, jaký zdroj by použilo, než obviníte aplikaci.

Prozrazení versus obejití: dvě zjištění, dvě opravy

Odražená adresa tunelu prozrazuje interní identifikátor po cestě, kterou jste povolili. Požadavek přímo přes WAN obchází cestu, kterou jste chtěli vyžadovat. První je otázka informace, druhá vymáhání, a opravují se na různých místech. Jejich slití do jednoho slova dává opravu, která neřeší ani jedno.

WebRTC to činí viditelnějším, aniž by to činilo chybným, protože shromáždit kandidáta není totéž jako ho vybrat.

ip route get 203.0.113.7 from 192.0.2.25
ip rule show

Spusťte dotaz na trasu pro každou povolenou adresu reflektoru se zdrojem, který má tento tok podle vás nést, a poté jej spusťte znovu pro vyloučené rozsahy, abyste viděli, co zvolí záložní varianta. Porovnejte obě odpovědi s politikou, kterou jste zapsali. Když se liší způsobem, který jste nezamýšleli, našli jste místo opravy, aniž byste vůbec museli interpretovat seznam kandidátů prohlížeče.