Cum verificați dacă un satelit Mesh Wi-Fi folosește routerul VPN

Un satelit care răspunde la același nume Wi-Fi ca routerul de bază nu spune aproape nimic despre unde ajung pachetele clienților săi. Nodul este un radio și un pod până la proba contrarie. Ce decide ieșirea este gateway-ul implicit pe care îl primește fiecare client și modul de forwarding al nodului din fața lui. Faceți aceste cinci verificări de la client spre exterior și veți avea un răspuns pe care îl puteți apăra, nu o impresie dintr-un test de viteză.

Citiți gateway-ul pe care clientul l-a primit de fapt

Pe client, tipăriți tabelul de rute și tabelul de vecini. Ruta implicită numește adresa care transmite traficul; intrarea de vecin numește MAC-ul care deține acea adresă. Folosiți clientul, nu lista de dispozitive a routerului, pentru că o listă de dispozitive arată asocierea, nu calea.

ip route show default
ip -6 route show default
ip neigh show

Windows tipărește aceleași fapte într-o altă formă: ipconfig /all dă gateway-ul implicit și arp -a dă MAC-ul. Pe macOS, route -n get default și arp -an acoperă același teren.

Comparați acel gateway cu două adrese pe care le știți deja: adresa LAN a routerului de bază și adresa de administrare a satelitului. Dacă gateway-ul este adresa LAN a routerului, clientul este puntat la router și politica routerului pentru acea rețea se aplică neschimbată. Dacă gateway-ul este adresa satelitului, satelitul rutează, iar routerul nu vede niciodată pachetele clientului ca trafic LAN; decizia trebuie luată pe nod, altfel nu se ia deloc.

Confirmați în ce mod se află de fapt nodul

Produsele Mesh refolosesc trei cuvinte pentru comportamente diferite, așa că aveți mai multă încredere în calea pachetului decât în eticheta din aplicație. Modul pod sau punct de acces transmite cadre. Modul router încheie o subrețea și rulează DHCP. Modul oaspete plasează de obicei clienții într-un VLAN separat, cu reguli proprii. Un nod în mod router în spatele altui router este NAT dublu, iar clienții săi ajung la routerul VPN deja traduși, ceea ce subminează politica bazată pe adresa sursă.

Pentru a stabili MAC-ul, citiți eticheta de pe nod și comparați-o cu ip neigh. Producătorii tipăresc MAC-ul de bază și derivă MAC-urile fiecărui radio crescând un octet, așa că ultima cifră hexazecimală diferă; comparați prefixul, nu adresa întreagă. Dacă MAC-ul gateway-ului aparține interfeței LAN a routerului, nodul nu rutează pentru acel client.

Dovediți ieșirea pe router, nu cu un test de viteză

Starea din partea routerului este singurul loc care arată traducerea. Pe OpenWrt, listați regulile de politică și tabelele de rutare, apoi confirmați că tunelul are un handshake recent:

ip rule show
ip route show table all | grep default
wg show

Pe pfSense sau OPNsense aceleași dovezi se află în pfctl -sr pentru reguli, pfctl -ss pentru stări active și în pagina de stare WireGuard pentru contoarele de parteneri, conform documentației clientului WireGuard. Filtrați tabelul de stări după adresa clientului. Dacă starea arată clientul tradus către adresa tunelului, traficul este în tunel; dacă arată adresa WAN, nu este, orice ar spune insigna de pe panou.

Un traceroute de pe client adaugă un fapt pe care tabelul de stări nu îl poate da: primul salt. Dacă primul salt este adresa LAN a routerului, clientul a ajuns direct la router. Dacă este adresa nodului urmată de încă un salt privat, sunteți pe un segment rutat, iar al doilea salt este dispozitivul care trebuie să țină politica.

Verificați ce distribuie nodul în afară de o adresă

Opțiunile DHCP călătoresc împreună cu contractul de închiriere, așa că un nod care servește propriul DHCP poate servi și propriul DNS și propriile anunțuri de router IPv6. Un client poate deci să iasă prin tunel și totuși să trimită interogări către un resolver de pe nod, sau să primească o adresă IPv6 globală pe care politica tunelului nu o acoperă niciodată. Tipăriți ambele pe client:

cat /etc/resolv.conf
ip -6 addr show scope global

Dacă resolverul este nodul și nodul transmite mai departe routerului, DNS-ul urmează tunelul. Dacă nodul rezolvă local sau indică resolverul furnizorului, interogările ies în afara tunelului chiar și atunci când HTTP nu o face. IPv6 merită același test: o adresă globală plus o rută implicită care ocolește tunelul înseamnă scurgere, iar firmware-ul Mesh lasă adesea IPv6 pornit în timp ce politica VPN acoperă doar IPv4.

Rupereți tunelul intenționat, apoi notați rezultatul

Coborâți tunelul și observați un client asociat acelui nod, nu un client aflat lângă router. ping și un curl cu timeout scurt sunt suficiente; întrebarea este dacă traficul se oprește sau cade înapoi pe WAN. Opriți tunelul cu comanda de serviciu a routerului însuși, de exemplu wg-quick down wg0 sau oprirea serviciului OpenVPN, și păstrați testul scurt.

Dacă clientul continuă să funcționeze, nodul sau routerul eșuează deschis pentru acel segment, iar mesh-ul a anulat în tăcere kill switch-ul. Readuceți tunelul, confirmați că numărătorul de handshake s-a mișcat și repetați verificarea tabelului de stări de la pasul al treilea.

Notați un rând pe nod: etichetă, SSID, adresa gateway-ului, prefixul MAC, ieșirea confirmată da sau nu, IPv6 acoperit și comportamentul cu tunelul coborât. Roaming-ul este locul unde răspunsul se schimbă, așa că testați camerele pe care le folosiți realmente. Când un rând nu se potrivește cu celelalte, acel nod trebuie investigat, iar corectarea aparține dispozitivului care deține gateway-ul acelui rând.