Jak sprawdzić, czy satelita Mesh Wi-Fi korzysta z routera VPN
Prześledź bramę domyślną, tryb przekazywania węzła i tablicę stanów routera, aby udowodnić, czy klienci satelity Mesh idą przez VPN.
Satelita, który odpowiada na tę samą nazwę Wi-Fi co router bazowy, nie mówi prawie nic o tym, dokąd trafiają pakiety jego klientów. Węzeł jest radiem i mostem, dopóki nie zostanie dowiedzione inaczej. O wyjściu decyduje brama domyślna, którą otrzymuje każdy klient, oraz tryb przekazywania węzła przed nim. Wykonaj tych pięć kontroli od klienta na zewnątrz, a otrzymasz odpowiedź, której możesz bronić, zamiast wrażenia z testu prędkości.
Odczytaj bramę, którą klient faktycznie otrzymał
Na kliencie wypisz tablicę tras i tablicę sąsiadów. Trasa domyślna wskazuje adres, który przekazuje ruch; wpis sąsiada wskazuje adres MAC, do którego należy ten adres. Użyj klienta, a nie listy urządzeń routera, ponieważ lista urządzeń pokazuje powiązania, a nie ścieżki.
ip route show default
ip -6 route show default
ip neigh showWindows podaje te same fakty w innej postaci: ipconfig /all daje bramę domyślną, a arp -a daje adres MAC. W systemie macOS route -n get default i arp -an obejmują to samo.
Porównaj tę bramę z dwoma adresami, które już znasz: adresem LAN routera bazowego i adresem zarządzania satelity. Jeśli brama jest adresem LAN routera, klient jest mostkowany do routera, a polityka routera dla tej sieci LAN obowiązuje bez zmian. Jeśli brama jest adresem satelity, satelita routuje, a router nigdy nie widzi pakietów klienta jako ruchu LAN; decyzja musi zapaść na węźle, inaczej nie zapada wcale.
Potwierdź, w jakim trybie naprawdę pracuje węzeł
Produkty Mesh używają trzech słów na różne zachowania, więc ufaj raczej ścieżce pakietu niż etykiecie w aplikacji. Tryb mostu lub punktu dostępowego przekazuje ramki. Tryb routera kończy podsieć i uruchamia DHCP. Tryb gościa zwykle umieszcza klientów w osobnym VLAN-ie z własnymi regułami. Węzeł w trybie routera za innym routerem to podwójny NAT, a jego klienci docierają do routera VPN już przetłumaczeni, co podważa politykę opartą na adresie źródłowym.
| 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 |
Aby ustalić adres MAC, odczytaj etykietę na węźle i porównaj ją z ip neigh. Producenci drukują bazowy MAC i wyliczają adresy MAC poszczególnych radiów przez zwiększanie bajtu, więc ostatnia cyfra szesnastkowa się różni; porównuj prefiks, a nie cały adres. Jeśli MAC bramy należy do interfejsu LAN routera, węzeł nie routuje dla tego klienta.
Udowodnij wyjście na routerze, a nie testem prędkości
Stan po stronie routera to jedyne miejsce, które pokazuje tłumaczenie. W OpenWrt wypisz reguły polityki i tablice routingu, a następnie potwierdź, że tunel ma świeży handshake:
ip rule show
ip route show table all | grep default
wg showW pfSense lub OPNsense te same dowody są w pfctl -sr dla reguł, pfctl -ss dla aktywnych stanów oraz na stronie statusu WireGuard dla liczników peerów, zgodnie z dokumentacją klienta WireGuard. Filtruj tablicę stanów po adresie klienta. Jeśli stan pokazuje klienta przetłumaczonego na adres tunelu, ruch jest w tunelu; jeśli pokazuje adres WAN, nie jest, cokolwiek twierdzi plakietka na pulpicie.
Traceroute z klienta dodaje fakt, którego tablica stanów nie poda: pierwszy przeskok. Jeśli pierwszym przeskokiem jest adres LAN routera, klient dotarł do routera bezpośrednio. Jeśli jest to adres węzła, po którym następuje kolejny prywatny przeskok, jesteś w segmencie routowanym, a ten drugi przeskok to urządzenie, które musi trzymać politykę.
Sprawdź, co węzeł rozdaje poza adresem
Opcje DHCP podróżują z dzierżawą, więc węzeł z własnym DHCP może też rozdawać własny DNS i własne ogłoszenia routera IPv6. Klient może więc wychodzić przez tunel i nadal wysyłać zapytania do resolvera na węźle albo otrzymać globalny adres IPv6, którego polityka tunelu nigdy nie obejmuje. Wypisz jedno i drugie na kliencie:
cat /etc/resolv.conf
ip -6 addr show scope globalJeśli resolverem jest węzeł, a węzeł przekazuje do routera, DNS podąża za tunelem. Jeśli węzeł rozwiązuje lokalnie lub wskazuje resolver dostawcy, zapytania wychodzą poza tunel, nawet gdy HTTP tego nie robi. IPv6 zasługuje na ten sam test: globalny adres plus trasa domyślna omijająca tunel to wyciek, a firmware Mesh często zostawia IPv6 włączone, podczas gdy polityka VPN obejmuje tylko IPv4.
Zerwij tunel celowo, a potem zapisz wynik
Zerwij tunel i obserwuj klienta połączonego z tym węzłem, a nie klienta obok routera. ping i curl z krótkim limitem czasu wystarczą; pytanie brzmi, czy ruch się zatrzymuje, czy wraca do WAN. Zatrzymaj tunel poleceniem usługi samego routera, na przykład wg-quick down wg0 lub zatrzymaniem usługi OpenVPN, i utrzymaj test krótko.
Jeśli klient nadal działa, węzeł lub router zawodzi otwarcie dla tego segmentu, a mesh po cichu cofnął kill switch. Przywróć tunel, potwierdź, że licznik handshake się zmienił, i powtórz kontrolę tablicy stanów z trzeciego kroku.
Zapisz jeden wiersz na węzeł: etykieta, SSID, adres bramy, prefiks MAC, wyjście potwierdzone tak lub nie, IPv6 objęte i zachowanie przy wyłączonym tunelu. Roaming to miejsce, w którym odpowiedź się zmienia, więc testuj pomieszczenia, których naprawdę używasz. Gdy jeden wiersz nie zgadza się z resztą, to ten węzeł trzeba zbadać, a poprawka należy do urządzenia, które posiada bramę z tego wiersza.