Kiel kontroli ĉu Mesh Wi-Fi satelito uzas la VPN-routeilon

Satelito, kiu respondas al la sama Wi-Fi-nomo kiel la baza routeilo, preskaŭ nenion diras pri tio, kien iras la pakoj de ĝiaj klientoj. La nodo estas radio kaj ponto, ĝis la malo estos pruvita. La eliron decidas la implicita pordego, kiun ricevas ĉiu kliento, kaj la plusenda reĝimo de la nodo antaŭ ĝi. Faru ĉi tiujn kvin kontrolojn de la kliento eksteren, kaj vi havos respondon, kiun vi povas defendi, ne impreson el rapidotesto.

Legu la pordegon, kiun la kliento efektive ricevis

Sur la kliento, presu la vojran tabelon kaj la najbaran tabelon. La implicita vojo nomas la adreson, kiu plusendas trafikon; la najbara ero nomas la MAC-on, kiu posedas tiun adreson. Uzu la klienton, ne la aparatliston de la routeilo, ĉar aparatlisto montras asociiĝojn, ne vojojn.

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

Vindozo presas la samajn faktojn en alia formo: ipconfig /all donas la implicitan pordegon kaj arp -a donas la MAC-on. En macOS, route -n get default kaj arp -an kovras la samon.

Komparu tiun pordegon kun du adresoj, kiujn vi jam konas: la LAN-adreso de la baza routeilo kaj la administra adreso de la satelito. Se la pordego estas la LAN-adreso de la routeilo, la kliento estas pontita al la routeilo kaj la politiko de la routeilo por tiu reto validas senŝanĝe. Se la pordego estas la adreso de la satelito, la satelito rutas, kaj la routeilo neniam vidas la pakojn de la kliento kiel LAN-trafikon; la decido devas okazi sur la nodo, alie ĝi tute ne okazas.

Konfirmu, en kiu reĝimo la nodo vere estas

Mesh-produktoj reuzas tri vortojn por malsamaj kondutoj, do fidu la pakan vojon pli ol la etikedon en la aplikaĵo. Ponto- aŭ alirpunkta reĝimo plusendas kadrojn. Routeila reĝimo finas subreton kaj rulas DHCP. Gastoreĝimo kutime metas klientojn en apartan VLAN kun propraj reguloj. Nodo en routeila reĝimo malantaŭ alia routeilo estas duobla NAT, kaj ĝiaj klientoj alvenas al la VPN-routeilo jam tradukitaj, kio subfosas politikon bazitan sur la fonta adreso.

Por determini la MAC-on, legu la etikedon sur la nodo kaj komparu ĝin kun ip neigh. Fabrikantoj presas la bazan MAC-on kaj derivas la MAC-ojn de ĉiu radio per pliigo de unu bajto, do la lasta deksesuma cifero malsamas; komparu la antaŭsignon, ne la tutan adreson. Se la MAC de la pordego apartenas al la LAN-interfaco de la routeilo, la nodo ne rutas por tiu kliento.

Pruvu la eliron sur la routeilo, ne per rapidotesto

La stato sur la routeila flanko estas la sola loko, kiu montras la tradukon. Sur OpenWrt, listigu la politikajn regulojn kaj la vojajn tabelojn, poste konfirmu, ke la tunelo havas freŝan handshake:

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

Sur pfSense aŭ OPNsense la samaj pruvoj troviĝas en pfctl -sr por reguloj, pfctl -ss por aktivaj statoj kaj sur la statpaĝo de WireGuard por la nombriloj de kunuloj, laŭ la dokumentaro de la WireGuard-kliento. Filtru la statan tabelon laŭ la adreso de la kliento. Se la stato montras la klienton tradukita al la tunela adreso, la trafiko estas en la tunelo; se ĝi montras la WAN-adreson, ĝi ne estas, kion ajn diras la insigno sur la panelo.

Traceroute de la kliento aldonas fakton, kiun la stata tabelo ne povas doni: la unuan salton. Se la unua salto estas la LAN-adreso de la routeilo, la kliento atingis la routeilon rekte. Se ĝi estas la adreso de la nodo sekvata de alia privata salto, vi estas sur rutita segmento, kaj tiu dua salto estas la aparato, kiu devas teni la politikon.

Rigardu, kion la nodo disdonas krom adreso

DHCP-opcioj vojaĝas kun la luo, do nodo kun propra DHCP povas ankaŭ disdoni sian propran DNS-on kaj siajn proprajn IPv6-routeilajn anoncojn. Kliento do povas eliri tra la tunelo kaj tamen sendi demandojn al solvilo sur la nodo, aŭ ricevi tutmondan IPv6-adreson, kiun la tunela politiko neniam kovras. Presu ambaŭ sur la kliento:

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

Se la solvilo estas la nodo kaj la nodo plusendas al la routeilo, DNS sekvas la tunnelon. Se la nodo solvas loke aŭ montras al la solvilo de la provizanto, la demandoj eliras ekster la tunelon eĉ kiam HTTP tion ne faras. IPv6 meritas la saman teston: tutmonda adreso plus implicita vojo, kiu preterpasas la tunelon, estas liko, kaj Mesh-firmware ofte lasas IPv6 ŝaltita dum la VPN-politiko kovras nur IPv4.

Rompu la tunelon intence, poste notu la rezulton

Mallevu la tunelon kaj observu klienton ligitan al tiu nodo, ne klienton apud la routeilo. ping kaj curl kun mallonga tempolimo sufiĉas; la demando estas, ĉu la trafiko haltas aŭ refalas al la WAN. Haltigu la tunelon per la servokomando de la routeilo mem, ekzemple wg-quick down wg0 aŭ haltigo de la OpenVPN-servo, kaj tenu la teston mallonga.

Se la kliento daŭre funkcias, la nodo aŭ la routeilo malsukcesas malferme por tiu segmento, kaj la mesh silente nuligis la kill switch. Revenigu la tunelon, konfirmu ke la handshake-nombrilo moviĝis, kaj ripetu la kontrolon de la stata tabelo el la tria paŝo.

Notu unu vicon por ĉiu nodo: etikedo, SSID, pordega adreso, MAC-antaŭsigno, eliro konfirmita jes aŭ ne, IPv6 kovrita, kaj konduto kun la tunelo mallevita. Roaming estas la loko, kie la respondo ŝanĝiĝas, do testu la ĉambrojn, kiujn vi vere uzas. Kiam unu vico ne kongruas kun la aliaj, tiu nodo estas la esplorinda, kaj la korekto apartenas al la aparato, kiu posedas la pordegon de tiu vico.