Jak zjistit, zda satelit Mesh Wi-Fi používá router VPN
Sledujte výchozí bránu, režim předávání uzlu a tabulku stavů routeru, abyste prokázali, zda klienti satelitu Mesh jdou přes VPN.
Satelit, který odpovídá na stejný název Wi-Fi jako základní router, neříká téměř nic o tom, kam pakety jeho klientů míří. Uzel je rádio a most, dokud se neprokáže opak. O výstupu rozhoduje výchozí brána, kterou každý klient dostane, a režim předávání uzlu před ním. Proveďte těchto pět kontrol od klienta směrem ven a získáte odpověď, kterou můžete obhájit, místo dojmu z testu rychlosti.
Přečtěte si bránu, kterou klient skutečně dostal
Na klientu vypište směrovací tabulku a tabulku sousedů. Výchozí trasa uvádí adresu, která předává provoz; záznam souseda uvádí MAC, které této adrese patří. Použijte klienta, ne seznam zařízení routeru, protože seznam zařízení ukazuje přiřazení, ne cesty.
ip route show default
ip -6 route show default
ip neigh showWindows vypisuje stejná fakta jinou formou: ipconfig /all dává výchozí bránu a arp -a dává MAC. V macOS route -n get default a arp -an pokrývají totéž.
Porovnejte tuto bránu se dvěma adresami, které už znáte: adresou LAN základního routeru a adresou správy satelitu. Je-li brána adresou LAN routeru, je klient přemostěn k routeru a politika routeru pro tuto LAN platí beze změny. Je-li brána adresou satelitu, satelit směruje a router nikdy nevidí pakety klienta jako LAN provoz; rozhodnutí musí padnout na uzlu, jinak nepadne vůbec.
Ověřte, v jakém režimu uzel skutečně je
Produkty Mesh používají tři slova pro různé chování, takže věřte spíše cestě paketu než štítku v aplikaci. Režim mostu nebo přístupového bodu předává rámce. Režim routeru ukončuje podsíť a provozuje DHCP. Režim hosta obvykle umísťuje klienty do samostatného VLAN s vlastními pravidly. Uzel v režimu routeru za jiným routerem je dvojitý NAT a jeho klienti dorazí k routeru VPN už přeložení, což podkopává politiku založenou na zdrojové adrese.
| What you see | What it means | Next check |
|---|---|---|
| Gateway is the router's LAN address, one MAC for every node | The node bridges; the router owns the policy | Router policy for that LAN and VLAN |
| Gateway is the node's address and DHCP comes from the node | The node routes; double NAT | Node's own VPN client, or a static route plus policy on the router |
| Gateway is a different subnet on a guest SSID | Guest VLAN, often client-isolated | Whether that VLAN is inside the tunnel policy |
| Gateway changes when you walk into another room | Roaming across segments | Repeat the check per node |
Pro určení MAC si přečtěte štítek na uzlu a porovnejte ho s ip neigh. Výrobci tisknou základní MAC a odvozují MAC jednotlivých rádií zvyšováním bajtu, takže poslední hexadecimální číslice se liší; porovnávejte prefix, ne celou adresu. Patří-li MAC brány rozhraní LAN routeru, uzel pro tohoto klienta nesměruje.
Dokažte výstup na routeru, ne testem rychlosti
Stav na straně routeru je jediné místo, které překlad ukazuje. V OpenWrt vypište pravidla politiky a směrovací tabulky a poté potvrďte, že tunel má čerstvý handshake:
ip rule show
ip route show table all | grep default
wg showV pfSense nebo OPNsense jsou stejné důkazy v pfctl -sr pro pravidla, pfctl -ss pro aktivní stavy a na stavové stránce WireGuard pro počítadla peerů, podle dokumentace klienta WireGuard. Filtrujte tabulku stavů podle adresy klienta. Ukazuje-li stav klienta přeloženého na adresu tunelu, provoz je v tunelu; ukazuje-li adresu WAN, není, ať si odznak na panelu říká co chce.
Traceroute z klienta přidává fakt, který tabulka stavů dát nemůže: první skok. Je-li prvním skokem adresa LAN routeru, klient dosáhl routeru přímo. Je-li to adresa uzlu následovaná dalším privátním skokem, jste v směrovaném segmentu a tento druhý skok je zařízení, které musí držet politiku.
Zkontrolujte, co uzel přiděluje kromě adresy
Možnosti DHCP cestují s lease, takže uzel s vlastním DHCP může přidělovat i vlastní DNS a vlastní oznámení routeru IPv6. Klient tak může vycházet tunelem a přesto posílat dotazy překladači na uzlu, nebo získat globální adresu IPv6, kterou politika tunelu nikdy nepokrývá. Vypište obojí na klientu:
cat /etc/resolv.conf
ip -6 addr show scope globalJe-li překladačem uzel a uzel předává routeru, DNS následuje tunel. Řeší-li uzel lokálně nebo ukazuje na překladač poskytovatele, dotazy vycházejí mimo tunel, i když HTTP ne. IPv6 si zaslouží stejný test: globální adresa plus výchozí trasa obcházející tunel je únik a firmware Mesh často nechává IPv6 zapnuté, zatímco politika VPN pokrývá jen IPv4.
Přerušte tunel schválně a pak výsledek zapište
Shoďte tunel a sledujte klienta přiřazeného k tomuto uzlu, ne klienta vedle routeru. ping a curl s krátkým časovým limitem stačí; otázka je, zda provoz přestane, nebo spadne zpět na WAN. Zastavte tunel příkazem služby samotného routeru, například wg-quick down wg0 nebo zastavením služby OpenVPN, a test udržte krátký.
Pokud klient funguje dál, uzel nebo router selhává otevřeně pro tento segment a mesh tiše zrušil kill switch. Vraťte tunel, potvrďte, že se počítadlo handshake pohnulo, a zopakujte kontrolu tabulky stavů ze třetího kroku.
Zapište jeden řádek na uzel: označení, SSID, adresa brány, prefix MAC, výstup potvrzen ano nebo ne, IPv6 pokryto a chování při vypnutém tunelu. Roaming je místo, kde se odpověď mění, takže testujte místnosti, které skutečně používáte. Když jeden řádek nesouhlasí s ostatními, je to ten uzel, který je třeba prošetřit, a oprava patří zařízení, které vlastní bránu z toho řádku.