Paano malalaman kung gumagamit ng VPN router ang isang Mesh Wi-Fi satellite

Ang satellite na sumasagot sa parehong Wi-Fi name ng base router ay halos walang sinasabi tungkol sa pupuntahan ng mga packet ng kliyente nito. Ang node ay radyo at tulay lamang hangga’t walang patunay sa kabaligtaran. Ang tumutukoy sa labasan ay ang default gateway na natatanggap ng bawat kliyente at ang forwarding mode ng node sa harap nito. Gawin ang limang pagsusuring ito mula sa kliyente palabas, at makakakuha ka ng sagot na kayang ipagtanggol, hindi ng impresyon mula sa speed test.

Basahin ang gateway na aktuwal na natanggap ng kliyente

Sa kliyente, i-print ang route table at neighbor table. Tinutukoy ng default route ang address na nagpapasa ng trapiko; tinutukoy ng neighbor entry ang MAC na may-ari ng address na iyon. Gamitin ang kliyente, hindi ang listahan ng device ng router, dahil nagpapakita ng asosasyon ang listahan ng device, hindi ng landas.

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

Iba ang anyo ng pag-print ng Windows ng parehong mga datos: ipconfig /all ang nagbibigay ng default gateway at arp -a ang nagbibigay ng MAC. Sa macOS, route -n get default at arp -an ang sumasaklaw sa pareho.

Ihambing ang gateway na iyon sa dalawang address na alam mo na: ang LAN address ng base router at ang management address ng satellite. Kung ang gateway ay ang LAN address ng router, naka-bridge ang kliyente sa router at umiiral nang walang pagbabago ang patakaran ng router para sa network na iyon. Kung ang gateway ay ang address ng satellite, nagro-route ang satellite at hindi kailanman nakikita ng router ang mga packet ng kliyente bilang LAN traffic; kailangang magpasya sa node, kung hindi ay hindi ito nangyayari.

Tiyakin kung anong mode talaga ang node

Muling ginagamit ng mga produktong Mesh ang tatlong salita para sa magkaibang pag-uugali, kaya mas paniwalaan ang landas ng packet kaysa sa label sa app. Ang bridge o access point mode ay nagpapasa ng frame. Ang router mode ay nagtatapos ng subnet at nagpapatakbo ng DHCP. Ang guest mode ay karaniwang naglalagay ng mga kliyente sa hiwalay na VLAN na may sariling patakaran. Ang node sa router mode sa likod ng isa pang router ay double NAT, at ang mga kliyente nito ay dumarating sa VPN router na nakasalin na, na sumisira sa patakarang nakabatay sa source address.

Para malaman ang MAC, basahin ang label sa node at ihambing sa ip neigh. Ang mga tagagawa ay nagpi-print ng base MAC at hinango ang MAC ng bawat radyo sa pamamagitan ng pagdagdag ng isang byte, kaya iba ang huling hexadecimal digit; ihambing ang prefix at hindi ang buong address. Kung ang MAC ng gateway ay pag-aari ng LAN interface ng router, hindi nagro-route ang node para sa kliyenteng iyon.

Patunayan ang labasan sa router, hindi sa speed test

Ang state sa panig ng router ang tanging lugar na nagpapakita ng pagsasalin. Sa OpenWrt, ilista ang mga patakaran at route table, pagkatapos tiyakin na may sariwang handshake ang tunnel:

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

Sa pfSense o OPNsense, ang parehong ebidensiya ay nasa pfctl -sr para sa mga patakaran, pfctl -ss para sa aktibong state, at sa status page ng WireGuard para sa peer counters, ayon sa dokumentasyon ng WireGuard client. Salain ang state table ayon sa address ng kliyente. Kung ipinapakita ng state na nakasalin ang kliyente sa tunnel address, nasa loob ng tunnel ang trapiko; kung WAN address ang ipinapakita, wala ito, anuman ang sabihin ng badge sa dashboard.

Ang traceroute mula sa kliyente ay nagdadagdag ng isang katotohanang hindi maibibigay ng state table: ang unang hop. Kung ang unang hop ay ang LAN address ng router, direktang nakarating ang kliyente sa router. Kung ito ay ang address ng node at sinusundan ng isa pang pribadong hop, nasa routed segment ka, at ang ikalawang hop na iyon ang device na dapat humawak ng patakaran.

Tingnan kung ano pa ang ibinibigay ng node bukod sa address

Sumasama ang mga DHCP option sa lease, kaya ang node na may sariling DHCP ay maaari ring magbigay ng sariling DNS at sariling IPv6 router advertisement. Kaya maaaring lumabas ang kliyente sa tunnel at magpadala pa rin ng query sa resolver sa node, o makakuha ng global IPv6 address na hindi kailanman sinasaklaw ng patakaran ng tunnel. I-print ang dalawa sa kliyente:

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

Kung ang resolver ay ang node at ipinapasa ng node sa router, sumusunod ang DNS sa tunnel. Kung lokal na nagre-resolve ang node o nakaturo sa resolver ng provider, lumalabas ang mga query sa labas ng tunnel kahit hindi ito ginagawa ng HTTP. Karapat-dapat din ang IPv6 sa parehong pagsubok: global address at default route na lumalabas sa tunnel ay pagtagas, at madalas na iniiwan ng Mesh firmware na bukas ang IPv6 habang ang patakaran ng VPN ay sumasaklaw lamang sa IPv4.

Sadyang putulin ang tunnel, pagkatapos itala ang resulta

Ibaba ang tunnel at obserbahan ang kliyenteng konektado sa node na iyon, hindi ang kliyenteng nakaupo sa tabi ng router. ping at curl na may maikling timeout ay sapat na; ang tanong ay kung humihinto ang trapiko o bumabalik sa WAN. Itigil ang tunnel gamit ang service command ng router mismo, halimbawa wg-quick down wg0 o paghinto ng OpenVPN service, at panatilihing maikli ang pagsubok.

Kung patuloy na gumagana ang kliyente, nabigo nang bukas ang node o router para sa segment na iyon, at tahimik na binawi ng mesh ang kill switch. Ibalik ang tunnel, tiyaking gumalaw ang handshake counter, at ulitin ang pagsusuri ng state table mula sa ikatlong hakbang.

Itala ang isang hilera bawat node: label, SSID, gateway address, MAC prefix, kumpirmadong labasan oo o hindi, saklaw ng IPv6, at pag-uugali kapag ibinaba ang tunnel. Ang roaming ang lugar kung saan nagbabago ang sagot, kaya subukan ang mga kwartong talagang ginagamit mo. Kapag may isang hilerang hindi tugma sa iba, ang node na iyon ang dapat imbestigahan, at ang pagwawasto ay dapat sa device na may-ari ng gateway ng hilerang iyon.