Kaip patikrinti, ar Mesh Wi-Fi palydovas naudoja VPN maršrutizatorių

Palydovas, kuris atsako į tą patį Wi-Fi vardą kaip bazinis maršrutizatorius, beveik nieko nesako apie tai, kur keliauja jo klientų paketai. Mazgas yra radijas ir tiltas, kol neįrodyta priešingai. Išėjimą lemia numatytoji tinklų sietuva, kurią gauna kiekvienas klientas, ir prieš jį esančio mazgo persiuntimo režimas. Atlikite šiuos penkis patikrinimus nuo kliento į išorę ir turėsite atsakymą, kurį galite apginti, o ne greičio testo įspūdį.

Perskaitykite tinklų sietuvą, kurią klientas iš tikrųjų gavo

Kliente atspausdinkite maršrutų lentelę ir kaimynų lentelę. Numatytasis maršrutas nurodo adresą, kuris persiunčia srautą; kaimyno įrašas nurodo MAC, kuriam priklauso tas adresas. Naudokite klientą, o ne maršrutizatoriaus įrenginių sąrašą, nes įrenginių sąrašas rodo priskyrimus, o ne kelius.

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

Windows tuos pačius faktus pateikia kita forma: ipconfig /all nurodo numatytąją tinklų sietuvą, o arp -a nurodo MAC. macOS sistemoje route -n get default ir arp -an apima tą patį.

Palyginkite šią tinklų sietuvą su dviem adresais, kuriuos jau žinote: bazinio maršrutizatoriaus LAN adresu ir palydovo valdymo adresu. Jei tinklų sietuva yra maršrutizatoriaus LAN adresas, klientas pririštas prie maršrutizatoriaus tiltu ir maršrutizatoriaus politika tam tinklui galioja nepakitusi. Jei tinklų sietuva yra palydovo adresas, palydovas maršrutizuoja ir maršrutizatorius niekada nemato kliento paketų kaip LAN srauto; sprendimas turi būti priimtas mazge, kitaip jis visai nepriimamas.

Patvirtinkite, kokiame režime mazgas iš tikrųjų yra

Mesh gaminiai naudoja tris žodžius skirtingam elgesiui, todėl labiau pasitikėkite paketo keliu nei programėlės žyme. Tiltų ar prieigos taško režimas persiunčia kadrus. Maršrutizatoriaus režimas užbaigia potinklį ir paleidžia DHCP. Svečių režimas paprastai talpina klientus atskirame VLAN su savo taisyklėmis. Mazgas maršrutizatoriaus režime už kito maršrutizatoriaus yra dvigubas NAT, o jo klientai pasiekia VPN maršrutizatorių jau išversti, kas silpnina politiką, pagrįstą šaltinio adresu.

Norėdami nustatyti MAC, perskaitykite etiketę ant mazgo ir palyginkite ją su ip neigh. Gamintojai spausdina bazinį MAC ir išveda kiekvieno radijo MAC, padidindami vieną baitą, todėl paskutinis šešioliktainis skaitmuo skiriasi; lyginkite priešdėlį, o ne visą adresą. Jei tinklų sietuvos MAC priklauso maršrutizatoriaus LAN sąsajai, mazgas tam klientui nemaršrutizuoja.

Įrodykite išėjimą maršrutizatoriuje, o ne greičio testu

Vertimo nesimato niekur kitur, tik maršrutizatoriaus pusės būsenoje. OpenWrt sistemoje išvardykite politikos taisykles ir maršrutų lenteles, tada patvirtinkite, kad tunelis turi naują handshake:

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

pfSense arba OPNsense sistemoje tie patys įrodymai yra pfctl -sr taisyklėms, pfctl -ss aktyvioms būsenoms ir WireGuard būsenos puslapyje lygiaverčių skaitikliams, pagal WireGuard kliento dokumentaciją. Filtruokite būsenų lentelę pagal kliento adresą. Jei būsena rodo klientą išverstą į tunelio adresą, srautas yra tunelio viduje; jei rodo WAN adresą, jo nėra, ką bebūtų sakoma prietaisų skydelio ženkle.

Traceroute iš kliento prideda vieną faktą, kurio būsenų lentelė negali duoti: pirmą šuolį. Jei pirmas šuolis yra maršrutizatoriaus LAN adresas, klientas pasiekė maršrutizatorių tiesiogiai. Jei tai mazgo adresas, po kurio eina dar vienas privatus šuolis, esate maršrutizuotame segmente, ir tas antrasis šuolis yra įrenginys, kuris turi laikyti politiką.

Pažiūrėkite, ką mazgas dalija be adreso

DHCP parinktys keliauja su nuoma, todėl mazgas su savo DHCP gali dalyti ir savo DNS, ir savo IPv6 maršrutizatoriaus skelbimus. Todėl klientas gali išeiti per tunelį ir vis tiek siųsti užklausas mazge esančiam sprendėjui arba gauti globalų IPv6 adresą, kurio tunelio politika niekada neapima. Atspausdinkite abu kliente:

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

Jei sprendėjas yra mazgas ir mazgas persiunčia maršrutizatoriui, DNS seka tunelį. Jei mazgas sprendžia vietoje arba nurodo teikėjo sprendėją, užklausos išeina už tunelio ribų, net kai HTTP to nedaro. IPv6 nusipelno to paties bandymo: globalus adresas ir numatytasis maršrutas, aplenkiantis tunelį, yra nuotėkis, o Mesh programinė įranga dažnai palieka IPv6 įjungtą, kai VPN politika apima tik IPv4.

Tyčia nutraukite tunelį, tada užrašykite rezultatą

Nuleiskite tunelį ir stebėkite klientą, prijungtą prie to mazgo, o ne klientą šalia maršrutizatoriaus. ping ir curl su trumpu laiko limitu pakanka; klausimas, ar srautas sustoja, ar grįžta į WAN. Sustabdykite tunelį paties maršrutizatoriaus paslaugos komanda, pavyzdžiui wg-quick down wg0 arba sustabdę OpenVPN paslaugą, ir laikykite bandymą trumpą.

Jei klientas veikia toliau, mazgas arba maršrutizatorius tame segmente sugenda atvirai, ir mesh tyliai atšaukė kill switch. Grąžinkite tunelį, patvirtinkite, kad handshake skaitiklis pajudėjo, ir pakartokite trečio žingsnio būsenų lentelės patikrinimą.

Užrašykite po vieną eilutę kiekvienam mazgui: žymė, SSID, tinklų sietuvos adresas, MAC priešdėlis, išėjimas patvirtintas taip arba ne, IPv6 apimta ir elgsena nuleidus tunelį. Roamingas yra vieta, kur atsakymas keičiasi, todėl išbandykite kambarius, kuriuos tikrai naudojate. Kai viena eilutė nesutampa su kitomis, tirti reikia būtent tą mazgą, o pataisa priklauso įrenginiui, kuriam priklauso tos eilutės tinklų sietuva.