Як праверыць, ці выкарыстоўвае спадарожнік Mesh Wi-Fi VPN-роўтар
Прасочыце шлюз па змаўчанні, рэжым перасылкі вузла і табліцу станаў роўтара, каб даказаць, ці кліенты спадарожніка Mesh ідуць праз VPN.
Спадарожнік, які адказвае на тое ж імя Wi-Fi, што і базавы роўтар, амаль нічога не кажа пра тое, куды ідуць пакеты яго кліентаў. Вузел застаецца радыё і мостам, пакуль не даказана адваротнае. Выхад вызначаюць шлюз па змаўчанні, які атрымлівае кожны кліент, і рэжым перасылкі вузла перад ім. Выканайце гэтыя пяць праверак ад кліента навонкі, і вы атрымаеце адказ, які можна адстаяць, а не ўражанне ад тэсту хуткасці.
Прачытайце шлюз, які кліент сапраўды атрымаў
На кліенце выведзіце табліцу маршрутаў і табліцу суседзяў. Маршрут па змаўчанні называе адрас, які перасылае трафік; запіс суседа называе MAC, якому належыць гэты адрас. Выкарыстоўвайце кліент, а не спіс прылад роўтара, бо спіс прылад паказвае прывязкі, а не шляхі.
ip route show default
ip -6 route show default
ip neigh showWindows выводзіць тыя ж факты ў іншым выглядзе: ipconfig /all дае шлюз па змаўчанні, а arp -a дае MAC. У macOS route -n get default і arp -an ахопліваюць тое ж самае.
Параўнайце гэты шлюз з двума адрасамі, якія вы ўжо ведаеце: LAN-адрасам базавага роўтара і адрасам кіравання спадарожніка. Калі шлюз — LAN-адрас роўтара, кліент злучаны мостам з роўтарам, і палітыка роўтара для гэтай сеткі дзейнічае без змен. Калі шлюз — адрас спадарожніка, спадарожнік маршрутызуе, і роўтар ніколі не бачыць пакеты кліента як трафік LAN; рашэнне павінна прымацца на вузле, інакш яно не прымаецца зусім.
Пацвердзіце, у якім рэжыме вузел насамрэч
Прадукты Mesh выкарыстоўваюць тры словы для рознага паводзінаў, таму давярайце шляху пакета больш, чым ярлыку ў праграме. Рэжым моста або пункта доступу перасылае кадры. Рэжым роўтара завяршае падсетку і запускае DHCP. Гасцявы рэжым звычайна змяшчае кліентаў у асобны VLAN са сваімі правіламі. Вузел у рэжыме роўтара за іншым роўтарам — гэта двайны NAT, і яго кліенты прыходзяць на VPN-роўтар ужо трансляванымі, што збясцэньвае палітыку па адрасе крыніцы.
| 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, прачытайце этыкетку на вузле і параўнайце яе з ip neigh. Вытворцы друкуюць базавы MAC і выводзяць MAC кожнага радыё інкрэментам байта, таму апошняя шаснаццатковая лічба адрозніваецца; параўноўвайце прэфікс, а не ўвесь адрас. Калі MAC шлюза належыць LAN-інтэрфейсу роўтара, вузел не маршрутызуе для гэтага кліента.
Дакажыце выхад на роўтары, а не тэстам хуткасці
Стан на баку роўтара — адзінае месца, дзе бачная трансляцыя. У OpenWrt выведзіце правілы палітыкі і табліцы маршрутызацыі, затым пераканайцеся, што ў тунеля ёсць свежы handshake:
ip rule show
ip route show table all | grep default
wg showУ pfSense або OPNsense тыя ж доказы ляжаць у pfctl -sr для правілаў, pfctl -ss для актыўных станаў і на старонцы стану WireGuard для лічыльнікаў піраў, згодна з дакументацыяй кліента WireGuard. Фільтруйце табліцу станаў па адрасе кліента. Калі стан паказвае кліента трансляваным у адрас тунеля, трафік унутры тунеля; калі паказвае адрас WAN, то не, што б ні сцвярджаў значок на панэлі.
Traceroute з кліента дадае факт, якога табліца станаў даць не можа: першы пераход. Калі першы пераход — LAN-адрас роўтара, кліент дабраўся да роўтара напрамкі. Калі гэта адрас вузла, за якім ідзе яшчэ адзін прыватны пераход, вы знаходзіцеся на маршрутызаваным сегменце, і гэты другі пераход — прылада, якая павінна трымаць палітыку.
Праверце, што вузел выдае акрамя адраса
Параметры DHCP едуць разам з арэндай, таму вузел з уласным DHCP можа таксама раздаваць уласны DNS і ўласныя аб’явы маршрутызатара IPv6. Кліент можа таму выходзіць праз тунель і ўсё роўна дасылаць запыты рэзалверу на вузле або атрымліваць глабальны адрас IPv6, які палітыка тунеля ніколі не пакрывае. Выведзіце і тое, і тое на кліенце:
cat /etc/resolv.conf
ip -6 addr show scope globalКалі рэзалвер — гэта вузел і вузел перасылае роўтару, DNS ідзе за тунелем. Калі вузел вырашае імёны лакальна або паказвае на рэзалвер правайдэра, запыты выходзяць па-за тунель, нават калі HTTP гэтага не робіць. IPv6 заслугоўвае той жа праверкі: глабальны адрас плюс маршрут па змаўчанні ў абыход тунеля — гэта ўцечка, а прашыўка Mesh часта пакідае IPv6 уключаным, тады як палітыка VPN пакрывае толькі IPv4.
Наўмысна абарвіце тунель, а затым запішыце вынік
Апусціце тунель і назірайце за кліентам, падключаным да гэтага вузла, а не за кліентам побач з роўтарам. ping і curl з кароткім тайм-аўтам дастаткова; пытанне ў тым, ці трафік спыніцца, ці ўпадзе назад у WAN. Спыніце тунель службовай камандай самога роўтара, напрыклад wg-quick down wg0 або спыненнем службы OpenVPN, і трымайце праверку кароткай.
Калі кліент працягвае працаваць, вузел або роўтар адмаўляе ў адкрытую для гэтага сегмента, і Mesh ціха адмяніў аварыйны выключальнік. Вярніце тунель, пераканайцеся, што лічыльнік handshake зрушыўся, і паўтарыце праверку табліцы станаў з трэцяга кроку.
Запішыце па адным радку на вузел: метка, SSID, адрас шлюза, прэфікс MAC, выхад пацверджаны так ці не, IPv6 пакрыты і паводзіны з апушчаным тунелем. Роўмінг — гэта месца, дзе адказ змяняецца, таму правярайце пакоі, якімі сапраўды карыстаецеся. Калі адзін радок разыходзіцца з іншымі, даследаваць трэба менавіта гэты вузел, а выпраўленне датычыцца прылады, якой належыць шлюз з гэтага радка.