Як перевірити, чи використовує супутник 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 виведіть правила політики й таблиці маршрутизації, потім підтвердьте, що тунель має свіжий рукостиск:
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 тихо скасував аварійний вимикач. Поверніть тунель, підтвердьте, що лічильник рукостискань зрушив, і повторіть перевірку таблиці станів із третього кроку.
Запишіть по одному рядку на вузол: мітка, SSID, адреса шлюзу, префікс MAC, вихід підтверджено так чи ні, IPv6 покрито й поведінка з опущеним тунелем. Роумінг — це місце, де відповідь змінюється, тому перевіряйте кімнати, якими справді користуєтеся. Коли один рядок розходиться з іншими, досліджувати треба саме цей вузол, а виправлення стосується пристрою, якому належить шлюз із цього рядка.