Näin tarkistat, käyttääkö Mesh Wi-Fi-satelliitti VPN-reititintä
Seuraa oletusyhdyskäytävää, solmun välitystilaa ja reitittimen tilataulua todistaaksesi, kulkevatko Mesh-satelliitin asiakkaat VPN:n kautta.
Satelliitti, joka vastaa samaan Wi-Fi-nimeen kuin perusreititin, ei kerro juuri mitään siitä, minne sen asiakkaiden paketit menevät. Solmu on radio ja silta, kunnes toisin todistetaan. Uloskäynnin ratkaisee oletusyhdyskäytävä, jonka jokainen asiakas saa, ja sen edessä olevan solmun välitystila. Tee nämä viisi tarkistusta asiakkaasta ulospäin, niin saat puolustettavan vastauksen etkä nopeustestin vaikutelmaa.
Lue yhdyskäytävä, jonka asiakas todella sai
Tulosta asiakkaassa reititystaulu ja naapuritaulu. Oletusreitti nimeää osoitteen, joka välittää liikennettä; naapurimerkintä nimeää MAC-osoitteen, jolle se osoite kuuluu. Käytä asiakasta, älä reitittimen laiteluetteloa, koska laiteluettelo näyttää liitokset, ei polkuja.
ip route show default
ip -6 route show default
ip neigh showWindows tulostaa samat tosiasiat toisessa muodossa: ipconfig /all antaa oletusyhdyskäytävän ja arp -a antaa MAC-osoitteen. macOS:ssä route -n get default ja arp -an kattavat saman.
Vertaa tuota yhdyskäytävää kahteen jo tuntemaasi osoitteeseen: perusreitittimen LAN-osoitteeseen ja satelliitin hallintaosoitteeseen. Jos yhdyskäytävä on reitittimen LAN-osoite, asiakas on sillattu reitittimeen ja reitittimen käytäntö kyseiselle verkolle pätee muuttumattomana. Jos yhdyskäytävä on satelliitin osoite, satelliitti reitittää eikä reititin näe asiakkaan paketteja koskaan LAN-liikenteenä; päätös on tehtävä solmussa, muuten sitä ei tehdä lainkaan.
Varmista, missä tilassa solmu todella on
Mesh-tuotteet käyttävät kolmea sanaa eri käyttäytymisille, joten luota paketin polkuun enemmän kuin sovelluksen merkintään. Silta- tai tukiasematila välittää kehyksiä. Reititintila päättää aliverkon ja ajaa DHCP:tä. Vierastila sijoittaa asiakkaat yleensä erilliseen VLANiin, jolla on omat sääntönsä. Toisen reitittimen takana oleva reititintilan solmu on kaksinkertainen NAT, ja sen asiakkaat saapuvat VPN-reitittimelle jo käännettyinä, mikä vesittää lähdeosoitteeseen perustuvan käytännön.
| 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-osoitteen selvittämiseksi lue solmun tarra ja vertaa sitä seuraavaan: ip neigh. Valmistajat painavat perus-MAC-osoitteen ja johtavat kunkin radion MAC-osoitteen kasvattamalla yhtä tavua, joten viimeinen heksadesimaalinumero eroaa; vertaa etuliitettä, älä koko osoitetta. Jos yhdyskäytävän MAC kuuluu reitittimen LAN-liitäntään, solmu ei reititä kyseiselle asiakkaalle.
Todista uloskäynti reitittimellä, ei nopeustestillä
Reitittimen puolen tila on ainoa paikka, joka näyttää käännöksen. OpenWrt:ssä luettele käytäntösäännöt ja reititystaulut ja varmista sitten, että tunnelilla on tuore handshake:
ip rule show
ip route show table all | grep default
wg showpfSensessä tai OPNsensessä samat todisteet ovat pfctl -sr säännöille, pfctl -ss aktiivisille tiloille ja WireGuardin tilasivulla vertaisten laskureille, seuraavan mukaan: WireGuard-asiakkaan dokumentaatio. Suodata tilataulu asiakkaan osoitteella. Jos tila näyttää asiakkaan käännettynä tunneliosoitteeseen, liikenne on tunnelissa; jos se näyttää WAN-osoitteen, se ei ole, mitä tahansa kojelaudan merkki sanoo.
Asiakkaasta tehty traceroute lisää yhden tosiasian, jota tilataulu ei voi antaa: ensimmäinen hyppy. Jos ensimmäinen hyppy on reitittimen LAN-osoite, asiakas saavutti reitittimen suoraan. Jos se on solmun osoite ja sitä seuraa vielä yksi yksityinen hyppy, olet reititetyllä segmentillä, ja se toinen hyppy on laite, jonka on pidettävä käytäntöä.
Katso, mitä solmu jakaa osoitteen lisäksi
DHCP-asetukset kulkevat vuokrasopimuksen mukana, joten oman DHCP:n tarjoava solmu voi jakaa myös oman DNS:nsä ja omat IPv6-reititintiedotuksensa. Asiakas voi siis poistua tunnelin kautta ja silti lähettää kyselyitä solmussa olevalle ratkaisijalle tai saada globaalin IPv6-osoitteen, jota tunnelikäytäntö ei koskaan kata. Tulosta molemmat asiakkaassa:
cat /etc/resolv.conf
ip -6 addr show scope globalJos ratkaisija on solmu ja solmu välittää reitittimelle, DNS seuraa tunnelia. Jos solmu ratkaisee paikallisesti tai osoittaa operaattorin ratkaisijaan, kyselyt lähtevät tunnelin ulkopuolelle, vaikka HTTP ei lähtisikään. IPv6 ansaitsee saman kokeen: globaali osoite ja tunnelin ohittava oletusreitti ovat vuoto, ja Mesh-laiteohjelmisto jättää IPv6:n usein päälle, kun VPN-käytäntö kattaa vain IPv4:n.
Katkaise tunneli tahallasi ja kirjaa sitten tulos
Laske tunneli alas ja tarkkaile asiakasta, joka on liitetty siihen solmuun, älä reitittimen vieressä istuvaa asiakasta. ping ja curl lyhyellä aikakatkaisulla riittävät; kysymys on, pysähtyykö liikenne vai putoaako se takaisin WANiin. Pysäytä tunneli reitittimen omalla palvelukomennolla, esimerkiksi wg-quick down wg0 tai pysäyttämällä OpenVPN-palvelu, ja pidä koe lyhyenä.
Jos asiakas toimii edelleen, solmu tai reititin epäonnistuu avoimesti kyseiselle segmentille, ja mesh on hiljaa kumonnut kill switchin. Palauta tunneli, varmista että handshake-laskuri liikkui, ja toista kolmannen vaiheen tilataulun tarkistus.
Kirjaa yksi rivi solmua kohden: tunniste, SSID, yhdyskäytävän osoite, MAC-etuliite, uloskäynti vahvistettu kyllä tai ei, IPv6 katettu ja käyttäytyminen tunnelin ollessa alhaalla. Roaming on paikka, jossa vastaus muuttuu, joten testaa huoneet, joita todella käytät. Kun yksi rivi ei sovi muihin, juuri se solmu on tutkittava, ja korjaus kuuluu laitteelle, joka omistaa kyseisen rivin yhdyskäytävän.