Как проверить, использует ли сателлит 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 покрыт и поведение при опущенном туннеле. Роуминг — это место, где ответ меняется, поэтому проверяйте комнаты, которыми действительно пользуетесь. Когда одна строка расходится с остальными, исследовать нужно именно этот узел, а исправление относится к устройству, которому принадлежит шлюз из этой строки.