Как да проверите дали Mesh Wi-Fi сателит използва VPN рутера

Сателит, който отговаря на същото Wi-Fi име като базовия рутер, не казва почти нищо за това къде отиват пакетите на клиентите му. Възелът е радио и мост, докато не се докаже обратното. Изхода определят шлюзът по подразбиране, който получава всеки клиент, и режимът на препращане на възела пред него. Направете тези пет проверки от клиента навън и ще имате отговор, който можете да защитите, вместо впечатление от тест за скорост.

Прочетете шлюза, който клиентът действително е получил

На клиента изведете таблицата на маршрутите и таблицата на съседите. Маршрутът по подразбиране посочва адреса, който препраща трафика; записът за съсед посочва MAC адреса, на който принадлежи този адрес. Използвайте клиента, а не списъка с устройства на рутера, защото списъкът с устройства показва свързвания, а не пътища.

ip route show default
ip -6 route show default
ip neigh show

Windows извежда същите факти в друг вид: ipconfig /all дава шлюза по подразбиране, а arp -a дава MAC адреса. В macOS route -n get default и arp -an покриват същото.

Сравнете този шлюз с два адреса, които вече знаете: LAN адреса на базовия рутер и адреса за управление на сателита. Ако шлюзът е LAN адресът на рутера, клиентът е свързан чрез мост към рутера и политиката на рутера за тази мрежа важи без промяна. Ако шлюзът е адресът на сателита, сателитът маршрутизира и рутерът никога не вижда пакетите на клиента като LAN трафик; решението трябва да се вземе на възела, иначе не се взема изобщо.

Потвърдете в какъв режим всъщност е възелът

Продуктите Mesh използват три думи за различно поведение, затова вярвайте повече на пътя на пакета, отколкото на етикета в приложението. Режимът на мост или точка за достъп препраща кадри. Режимът на рутер завършва подмрежа и пуска DHCP. Гостевият режим обикновено поставя клиентите в отделен VLAN със собствени правила. Възел в режим на рутер зад друг рутер е двоен NAT и клиентите му стигат до VPN рутера вече транслатирани, което обезсмисля политика, базирана на адреса на източника.

За да установите 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 тихо е отменил kill switch. Върнете тунела, потвърдете, че броячът на handshake се е преместил, и повторете проверката на таблицата на състоянията от третата стъпка.

Запишете един ред на възел: етикет, SSID, адрес на шлюза, MAC префикс, изход потвърден да или не, IPv6 покрит и поведение при спрян тунел. Роумингът е мястото, където отговорът се променя, затова тествайте стаите, които наистина използвате. Когато един ред не съвпада с останалите, точно този възел трябва да се изследва, а поправката принадлежи на устройството, което притежава шлюза от този ред.