Kā pārbaudīt, vai Mesh Wi-Fi pavadonis izmanto VPN maršrutētāju
Izsekojiet noklusējuma vārteju, mezgla pārsūtīšanas režīmu un maršrutētāja stāvokļu tabulu, lai pierādītu, vai Mesh pavadoņa klienti iet caur VPN.
Pavadonis, kas atbild uz to pašu Wi-Fi nosaukumu kā bāzes maršrutētājs, gandrīz neko nepasaka par to, kurp dodas tā klientu paketes. Mezgls ir radio un tilts, līdz tiek pierādīts pretējais. Izeju nosaka noklusējuma vārteja, ko saņem katrs klients, un tā priekšā esošā mezgla pārsūtīšanas režīms. Veiciet šīs piecas pārbaudes no klienta uz āru, un jums būs atbilde, ko varat aizstāvēt, nevis iespaids no ātruma testa.
Nolasiet vārteju, ko klients patiešām saņēma
Klientā izdrukājiet maršrutu tabulu un kaimiņu tabulu. Noklusējuma maršruts nosauc adresi, kas pārsūta trafiku; kaimiņa ieraksts nosauc MAC, kam pieder šī adrese. Izmantojiet klientu, nevis maršrutētāja ierīču sarakstu, jo ierīču saraksts rāda piesaistes, nevis ceļus.
ip route show default
ip -6 route show default
ip neigh showWindows izdrukā tos pašus faktus citā formā: ipconfig /all dod noklusējuma vārteju un arp -a dod MAC. Operētājsistēmā macOS route -n get default un arp -an aptver to pašu.
Salīdziniet šo vārteju ar divām adresēm, ko jau zināt: bāzes maršrutētāja LAN adresi un pavadoņa pārvaldības adresi. Ja vārteja ir maršrutētāja LAN adrese, klients ir savienots ar maršrutētāju tiltā un maršrutētāja politika šim tīklam darbojas nemainīgi. Ja vārteja ir pavadoņa adrese, pavadonis maršrutē un maršrutētājs nekad neredz klienta paketes kā LAN trafiku; lēmums jāpieņem mezglā, citādi tas vispār netiek pieņemts.
Apstipriniet, kādā režīmā mezgls patiešām ir
Mesh produkti atkārtoti izmanto trīs vārdus dažādai uzvedībai, tāpēc uzticieties pakešu ceļam vairāk nekā lietotnes uzlīmei. Tilta vai piekļuves punkta režīms pārsūta kadrus. Maršrutētāja režīms pabeidz apakštīklu un palaiž DHCP. Viesu režīms parasti ievieto klientus atsevišķā VLAN ar saviem noteikumiem. Mezgls maršrutētāja režīmā aiz cita maršrutētāja ir dubults NAT, un tā klienti nonāk pie VPN maršrutētāja jau pārtulkoti, kas iedragā politiku, kuras pamatā ir avota adrese.
| 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 |
Lai noteiktu MAC, nolasiet uzlīmi uz mezgla un salīdziniet to ar ip neigh. Ražotāji izdrukā bāzes MAC un atvasina katra radio MAC, palielinot vienu baitu, tāpēc pēdējais sešpadsmitnieka cipars atšķiras; salīdziniet prefiksu, nevis visu adresi. Ja vārtejas MAC pieder maršrutētāja LAN saskarnei, mezgls šim klientam nemaršrutē.
Pierādiet izeju maršrutētājā, nevis ar ātruma testu
Tulkojums redzams tikai maršrutētāja puses stāvoklī. OpenWrt izskaitļojiet politikas noteikumus un maršrutu tabulas, pēc tam apstipriniet, ka tunelim ir svaigs handshake:
ip rule show
ip route show table all | grep default
wg showpfSense vai OPNsense sistēmā tie paši pierādījumi ir pfctl -sr noteikumiem, pfctl -ss aktīvajiem stāvokļiem un WireGuard stāvokļa lapā līdzinieku skaitītājiem, saskaņā ar WireGuard klienta dokumentāciju. Filtrējiet stāvokļu tabulu pēc klienta adreses. Ja stāvoklis rāda klientu pārtulkotu uz tuneļa adresi, trafiks ir tunelī; ja rāda WAN adresi, tā nav, lai ko teiktu informācijas paneļa emblēma.
Traceroute no klienta pievieno vienu faktu, ko stāvokļu tabula nevar dot: pirmo lēcienu. Ja pirmais lēciens ir maršrutētāja LAN adrese, klients sasniedza maršrutētāju tieši. Ja tas ir mezgla adrese un tam seko vēl viens privāts lēciens, jūs esat maršrutētā segmentā, un šis otrais lēciens ir ierīce, kurai jātur politika.
Apskatiet, ko mezgls izdala papildus adresei
DHCP opcijas ceļo kopā ar nomu, tāpēc mezgls ar savu DHCP var izdalīt arī savu DNS un savus IPv6 maršrutētāja paziņojumus. Tāpēc klients var iziet caur tuneli un tomēr sūtīt vaicājumus mezglā esošajam risinātājam vai saņemt globālu IPv6 adresi, ko tuneļa politika nekad neaptver. Izdrukājiet abus klientā:
cat /etc/resolv.conf
ip -6 addr show scope globalJa risinātājs ir mezgls un mezgls pārsūta maršrutētājam, DNS seko tunelim. Ja mezgls risina lokāli vai norāda uz pakalpojumu sniedzēja risinātāju, vaicājumi iziet ārpus tuneļa arī tad, ja HTTP to nedara. IPv6 ir pelnījis to pašu pārbaudi: globāla adrese un noklusējuma maršruts, kas apiet tuneli, ir noplūde, un Mesh programmaparatūra bieži atstāj IPv6 ieslēgtu, kamēr VPN politika aptver tikai IPv4.
Apzināti pārtrauciet tuneli un pēc tam pierakstiet rezultātu
Nolaidiet tuneli un vērojiet klientu, kas savienots ar šo mezglu, nevis klientu blakus maršrutētājam. ping un curl ar īsu taimautu ir pietiekami; jautājums ir, vai trafiks apstājas vai atkrīt atpakaļ uz WAN. Apturiet tuneli ar paša maršrutētāja servisa komandu, piemēram, wg-quick down wg0 vai apturot OpenVPN servisu, un turiet pārbaudi īsu.
Ja klients turpina darboties, mezgls vai maršrutētājs šajā segmentā nokrīt atvērtā režīmā, un mesh ir klusi atcēlis kill switch. Atgrieziet tuneli, apstipriniet, ka handshake skaitītājs ir pavirzījies, un atkārtojiet trešā soļa stāvokļu tabulas pārbaudi.
Pierakstiet vienu rindu katram mezglam: etiķete, SSID, vārtejas adrese, MAC prefikss, izeja apstiprināta jā vai nē, IPv6 aptverta un uzvedība ar nolaistu tuneli. Viesabonēšana ir vieta, kur atbilde mainās, tāpēc pārbaudiet telpas, kuras patiešām izmantojat. Ja viena rinda nesaskan ar pārējām, izmeklējams ir tieši šis mezgls, un labojums attiecas uz ierīci, kurai pieder šīs rindas vārteja.