Kuidas kontrollida, kas Mesh Wi-Fi satelliit kasutab VPN-ruuterit
Jälgi vaikimisi lüüsi, sõlme edastusrežiimi ja ruuteri olekutabelit, et tõestada, kas Mesh-satelliidi kliendid lähevad VPN-i kaudu.
Satelliit, mis vastab samale Wi-Fi nimele nagu põhiruuter, ei ütle peaaegu midagi selle kohta, kuhu tema klientide paketid lähevad. Sõlm on raadio ja sild, kuni vastupidine on tõestatud. Väljapääsu otsustab vaikimisi lüüs, mille iga klient saab, ja selle ees oleva sõlme edastusrežiim. Tee need viis kontrolli kliendist väljapoole ja sul on kaitstav vastus, mitte kiirustesti mulje.
Loe lüüs, mille klient tegelikult sai
Kliendis trüki välja marsruutide tabel ja naabrite tabel. Vaikimisi marsruut nimetab aadressi, mis liiklust edasi saadab; naabrikirje nimetab MAC-i, millele see aadress kuulub. Kasuta klienti, mitte ruuteri seadmete loendit, sest seadmete loend näitab seoseid, mitte teid.
ip route show default
ip -6 route show default
ip neigh showWindows trükib samad faktid teises vormis välja: ipconfig /all annab vaikimisi lüüsi ja arp -a annab MAC-i. macOS-is katavad route -n get default ja arp -an sama maa-ala.
Võrdle seda lüüsi kahe aadressiga, mida sa juba tead: põhiruuteri LAN-aadress ja satelliidi haldusaadress. Kui lüüs on ruuteri LAN-aadress, on klient ruuterisse sillatud ja ruuteri poliitika selle võrgu jaoks kehtib muutusteta. Kui lüüs on satelliidi aadress, siis satelliit marsruudib ja ruuter ei näe kunagi kliendi pakette LAN-liiklusena; otsus tuleb teha sõlmes, muidu ei tehta seda üldse.
Kinnita, mis režiimis sõlm tegelikult on
Mesh-tooted kasutavad erineva käitumise jaoks kolme sõna uuesti, seega usalda paketi teed rohkem kui rakenduses olevat silti. Silla- või juurdepääsupunkti režiim edastab kaadreid. Ruuteri režiim lõpetab alamvõrgu ja käivitab DHCP. Külalisrežiim paigutab kliendid tavaliselt eraldi VLAN-i, millel on oma reeglid. Teise ruuteri taga olev ruuteri režiimis sõlm on topelt-NAT ja selle kliendid jõuavad VPN-ruuterini juba tõlgituna, mis õõnestab lähteaadressil põhinevat poliitikat.
| 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 |
MAC-i määramiseks loe sõlmel olevat silti ja võrdle seda järgmisega: ip neigh. Tootjad trükivad põhi-MAC-i ja tuletavad iga raadio MAC-i, suurendades ühte baiti, seega erineb viimane kuueteistkümnendnumber; võrdle eesliidet, mitte tervet aadressi. Kui lüüsi MAC kuulub ruuteri LAN-liidesele, siis sõlm selle kliendi jaoks ei marsruudi.
Tõesta väljapääs ruuteril, mitte kiirustestiga
Ruuteri poolne olek on ainus koht, mis tõlkimist näitab. OpenWrt-s loetle poliitikareeglid ja marsruutimistabelid, seejärel kinnita, et tunnelil on värske handshake:
ip rule show
ip route show table all | grep default
wg showPfSense'is või OPNsense'is on samad tõendid kohas pfctl -sr reeglite jaoks, pfctl -ss aktiivsete olekute jaoks ja WireGuardi olekulehel võrdsete loendurite jaoks, vastavalt WireGuardi kliendi dokumentatsioonile. Filtreeri olekutabel kliendi aadressi järgi. Kui olek näitab klienti tunneliaadressile tõlgituna, on liiklus tunnelis; kui näitab WAN-aadressi, siis ei ole, ükskõik mida armatuurlaua märk ütleb.
Traceroute kliendist lisab ühe fakti, mida olekutabel anda ei saa: esimene hüpe. Kui esimene hüpe on ruuteri LAN-aadress, jõudis klient ruuterini otse. Kui see on sõlme aadress ja sellele järgneb veel üks privaatne hüpe, oled marsruuditud segmendil ja see teine hüpe on seade, mis peab poliitikat kandma.
Vaata, mida sõlm lisaks aadressile jagab
DHCP valikud liiguvad koos rendilepinguga, seega saab oma DHCP-d pakkuv sõlm jagada ka oma DNS-i ja oma IPv6-ruuteriteateid. Klient võib seega tunnelist välja minna ja siiski saata päringuid sõlmel olevale resolverile või saada globaalse IPv6-aadressi, mida tunnelipoliitika kunagi ei kata. Trüki mõlemad kliendis välja:
cat /etc/resolv.conf
ip -6 addr show scope globalKui resolver on sõlm ja sõlm edastab ruuterile, järgib DNS tunnelit. Kui sõlm lahendab kohapeal või osutab teenusepakkuja resolverile, lahkuvad päringud tunnelist välja ka siis, kui HTTP seda ei tee. IPv6 väärib sama katset: globaalne aadress ja tunnelist mööda minev vaikimisi marsruut on leke, ja Mesh-püsivara jätab IPv6 sageli sisse, samal ajal kui VPN-poliitika katab ainult IPv4.
Katkesta tunnel meelega ja kirjuta tulemus üles
Lase tunnel alla ja jälgi klienti, mis on selle sõlmega ühendatud, mitte klienti ruuteri kõrval. ping ja curl lühikese ajapiiranguga on piisavad; küsimus on, kas liiklus peatub või langeb tagasi WAN-i. Peata tunnel ruuteri enda teenusekäsuga, näiteks wg-quick down wg0 või OpenVPN-teenuse peatamisega, ja hoia katse lühike.
Kui klient töötab edasi, siis sõlm või ruuter ebaõnnestub selle segmendi jaoks avatult ja mesh on kill switchi vaikselt tühistanud. Too tunnel tagasi, kinnita, et handshake'i loendur liikus, ja korda kolmanda sammu olekutabeli kontrolli.
Kirjuta üks rida iga sõlme kohta: silt, SSID, lüüsi aadress, MAC-i eesliide, väljapääs kinnitatud jah või ei, IPv6 kaetud ja käitumine tunneliga all. Roaming on koht, kus vastus muutub, seega katsu tube, mida sa tegelikult kasutad. Kui üks rida teistega ei klapi, on uurimiseks just see sõlm ja parandus kuulub seadmele, millel on selle rea lüüs.