Hvernig á að athuga hvort Mesh Wi-Fi gervihnöttur notar VPN-beiðinn
Fylgdu sjálfgefnu gáttinni, sendingarham hnútsins og stöðutöflu beinisins til að sanna hvort biðlarar Mesh-gervihnattar fara í gegnum VPN.
Gervihnöttur sem svarar sama Wi-Fi nafni og grunnbeinninn segir næstum ekkert um hvert pakkar biðlara hans fara. Hnúturinn er útvarp og brú þar til hið gagnstæða er sannað. Það sem ræður útgöngunni er sjálfgefna gáttin sem hver biðlari fær og sendingarhamur hnútsins fyrir framan hana. Gerðu þessar fimm athuganir frá biðlaranum út á við og þú hefur svar sem þú getur varið, ekki tilfinningu frá hraðaprófi.
Lestu gáttina sem biðlarinn fékk í raun
Á biðlaranum, prentaðu leiðatöfluna og nágrannatöfluna. Sjálfgefna leiðin nefnir netfangið sem sendir umferð áfram; nágrannafærslan nefnir MAC-ið sem á það netfang. Notaðu biðlarann, ekki tækjalista beinisins, því tækjalisti sýnir tengingar, ekki leiðir.
ip route show default
ip -6 route show default
ip neigh showWindows prentar sömu staðreyndir í annarri mynd: ipconfig /all gefur sjálfgefnu gáttina og arp -a gefur MAC-ið. Á macOS ná route -n get default og arp -an yfir sama hlut.
Berðu þessa gátt saman við tvö netföng sem þú þekkir nú þegar: LAN-netfang grunnbeinisins og stjórnnetfang gervihnattarins. Ef gáttin er LAN-netfang beinisins er biðlarinn brúaður til beinisins og stefna beinisins fyrir það net gildir óbreytt. Ef gáttin er netfang gervihnattarins er gervihnötturinn að beina og beinninn sér aldrei pakka biðlarans sem LAN-umferð; ákvörðunin verður að eiga sér stað á hnútnum, annars gerist hún alls ekki.
Staðfestu í hvaða ham hnúturinn er í raun
Mesh-vörur endurnýta þrjú orð fyrir ólíka hegðun, svo treystu slóð pakkans frekar en merkimiðanum í appinu. Brúar- eða aðgangspunktaham sendir ramma áfram. Beinaham lýkur undirneti og keyrir DHCP. Gestaham setur biðlara venjulega í sér VLAN með eigin reglum. Hnútur í beinaham á bak við annan beini er tvöfalt NAT og biðlarar hans ná til VPN-beinisins þegar þýddir, sem veikir stefnu sem byggir á upprunanetfangi.
| 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 |
Til að ákvarða MAC-ið, lestu merkimiðann á hnútnum og berðu saman við ip neigh. Framleiðendur prenta grunn-MAC-ið og leiða MAC hvers útvarps með því að hækka eitt bæti, svo síðasti sextánski tölustafur er ólíkur; berðu saman forskeytið en ekki netfangið allt. Ef MAC gáttarinnar tilheyrir LAN-tengi beinisins beinir hnúturinn ekki fyrir þann biðlara.
Sannaðu útgönguna á beininum, ekki með hraðaprófi
Staðan á beinahliðinni er eini staðurinn sem sýnir þýðinguna. Á OpenWrt, listaðu stefnureglurnar og leiðatöflurnar og staðfestu svo að göngin hafi nýlegt handshake:
ip rule show
ip route show table all | grep default
wg showÁ pfSense eða OPNsense er sömu sönnunargögnin að finna í pfctl -sr fyrir reglur, pfctl -ss fyrir virk stöður og á stöðusíðu WireGuard fyrir teljara jafningja, samkvæmt skjölum WireGuard-biðlarans. Síaðu stöðutöfluna eftir netfangi biðlarans. Ef staðan sýnir biðlarann þýddan yfir á netfang ganganna er umferðin í göngunum; ef hún sýnir WAN-netfangið er hún það ekki, hvað sem merkið á mælaborðinu segir.
Traceroute frá biðlaranum bætir við einni staðreynd sem stöðutaflan getur ekki gefið: fyrsta stökkið. Ef fyrsta stökkið er LAN-netfang beinisins náði biðlarinn beininum beint. Ef það er netfang hnútsins og annað einkastökk fylgir ertu á beinum hluta, og það annað stökk er tækið sem verður að halda stefnunni.
Skoðaðu hvað hnúturinn dreifir öðru en netfangi
DHCP-valkostir ferðast með leigunni, svo hnútur með eigið DHCP getur líka dreift eigin DNS og eigin IPv6-beinaskilaboðum. Biðlari getur því farið út í gegnum göngin og samt sent fyrirspurnir til leysirásar á hnútnum, eða fengið alheims IPv6-netfang sem stefna ganganna nær aldrei yfir. Prentaðu bæði á biðlaranum:
cat /etc/resolv.conf
ip -6 addr show scope globalEf leysirinn er hnúturinn og hnúturinn sendir áfram til beinisins fylgir DNS göngunum. Ef hnúturinn leysir staðbundið eða vísar á leysi þjónustuveitandans fara fyrirspurnirnar út fyrir göngin jafnvel þótt HTTP geri það ekki. IPv6 á skilið sömu prófun: alheimsnetfang ásamt sjálfgefinni leið sem fer fram hjá göngunum er leki, og Mesh-fastbúnaður lætur IPv6 oft vera á meðan VPN-stefnan nær aðeins yfir IPv4.
Rjúfðu göngin viljandi og skrifaðu svo niðurstöðuna
Lækkaðu göngin og fylgstu með biðlara sem er tengdur þeim hnút, ekki biðlara við hlið beinisins. ping og curl með stuttum tímanum er nóg; spurningin er hvort umferðin stöðvast eða fellur aftur í WAN. Stöðvaðu göngin með þjónustukommando beinisins sjálfs, til dæmis wg-quick down wg0 eða stöðvun OpenVPN-þjónustunnar, og haltu prófuninni stuttri.
Ef biðlarinn heldur áfram að virka bregst hnúturinn eða beinninn opið fyrir þann hluta, og mesh-ið hefur hljóðlega afturkallað kill switch. Komdu göngunum aftur, staðfestu að handshake-teljarinn hreyfðist og endurtaktu stöðutöfluna frá þriðja skrefi.
Skrifaðu eina línu fyrir hvern hnút: merki, SSID, netfang gáttar, MAC-forskeyti, útganga staðfest já eða nei, IPv6 þakið og hegðun með göngin niðri. Roaming er staðurinn þar sem svarið breytist, svo prófaðu herbergin sem þú notar í raun. Þegar ein lína passar ekki við hinar er sá hnútur sá sem rannsaka þarf, og leiðréttingin tilheyrir tækinu sem á gátt þeirrar línu.