Como verificar se um satélite Mesh Wi-Fi usa o roteador VPN

Um satélite que responde ao mesmo nome Wi-Fi do roteador base não diz quase nada sobre para onde vão os pacotes dos seus clientes. O nó é um rádio e uma ponte até prova em contrário. O que decide a saída é o gateway padrão que cada cliente recebe e o modo de encaminhamento do nó à frente dele. Faça estas cinco verificações do cliente para fora e você terá uma resposta defensável, em vez de uma impressão tirada de um teste de velocidade.

Leia o gateway que o cliente realmente recebeu

No cliente, imprima a tabela de rotas e a tabela de vizinhos. A rota padrão nomeia o endereço que encaminha o tráfego; a entrada de vizinho nomeia o MAC dono desse endereço. Use o cliente, não a lista de dispositivos do roteador, porque uma lista de dispositivos mostra associações, não caminhos.

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

O Windows imprime os mesmos fatos de outra forma: ipconfig /all fornece o gateway padrão e arp -a fornece o MAC. No macOS, route -n get default e arp -an cobrem o mesmo terreno.

Compare esse gateway com dois endereços que você já conhece: o endereço LAN do roteador base e o endereço de gerenciamento do satélite. Se o gateway for o endereço LAN do roteador, o cliente está em ponte com o roteador e a política do roteador para essa LAN se aplica sem mudanças. Se o gateway for o endereço do satélite, o satélite está roteando e o roteador nunca vê os pacotes do cliente como tráfego LAN; a decisão precisa acontecer no nó, senão não acontece.

Confirme em que modo o nó está de fato

Os produtos Mesh reutilizam três palavras para comportamentos diferentes, então confie no caminho do pacote mais do que no rótulo do aplicativo. O modo ponte ou ponto de acesso encaminha quadros. O modo roteador termina uma sub-rede e roda DHCP. O modo convidado costuma colocar os clientes em uma VLAN separada com regras próprias. Um nó em modo roteador atrás de outro roteador é um NAT duplo, e seus clientes chegam ao roteador VPN já traduzidos, o que anula uma política baseada no endereço de origem.

Para fixar o MAC, leia o rótulo no nó e compare com ip neigh. Os fabricantes imprimem o MAC base e derivam os MACs de cada rádio incrementando um byte, por isso o último dígito hexadecimal difere; compare o prefixo em vez do endereço inteiro. Se o MAC do gateway pertence à interface LAN do roteador, o nó não está roteando para esse cliente.

Prove a saída no roteador, não com um teste de velocidade

O estado no lado do roteador é o único lugar que mostra a tradução. No OpenWrt, liste as regras de política e as tabelas de rotas e depois confirme que o túnel tem um handshake recente:

ip rule show
ip route show table all | grep default
wg show

No pfSense ou no OPNsense as mesmas evidências ficam em pfctl -sr para as regras, pfctl -ss para os estados ativos e na página de status do WireGuard para os contadores de pares, seguindo a documentação do cliente WireGuard. Filtre a tabela de estados pelo endereço do cliente. Se o estado mostrar o cliente traduzido para o endereço do túnel, o tráfego está dentro do túnel; se mostrar o endereço WAN, não está, diga o que disser o selo do painel.

Um traceroute a partir do cliente acrescenta um fato que a tabela de estados não pode dar: o primeiro salto. Se o primeiro salto for o endereço LAN do roteador, o cliente chegou ao roteador diretamente. Se for o endereço do nó seguido de outro salto privado, você está em um segmento roteado, e esse segundo salto é o dispositivo que precisa deter a política.

Verifique o que o nó entrega além de um endereço

As opções DHCP viajam com a concessão, então um nó que serve seu próprio DHCP também pode servir seu próprio DNS e seus próprios anúncios de roteador IPv6. Um cliente pode, portanto, sair pelo túnel e ainda enviar consultas a um resolvedor no nó, ou obter um endereço IPv6 global que a política do túnel nunca cobre. Imprima os dois no cliente:

cat /etc/resolv.conf
ip -6 addr show scope global

Se o resolvedor for o nó e o nó encaminhar para o roteador, o DNS segue o túnel. Se o nó resolver localmente ou apontar para o resolvedor do provedor, as consultas saem fora do túnel mesmo quando o HTTP não sai. IPv6 merece o mesmo teste: um endereço global mais uma rota padrão que desvia do túnel é um vazamento, e o firmware Mesh muitas vezes deixa o IPv6 ligado enquanto a política VPN cobre apenas IPv4.

Derrube o túnel de propósito e depois anote o resultado

Derrube o túnel e observe um cliente associado a esse nó, não um cliente ao lado do roteador. ping e um curl com timeout curto bastam; a pergunta é se o tráfego para ou cai para a WAN. Pare o túnel com o comando de serviço do próprio roteador, por exemplo wg-quick down wg0 ou a parada do serviço OpenVPN, e mantenha o teste curto.

Se o cliente continuar funcionando, o nó ou o roteador está falhando aberto para esse segmento, e o mesh desfez o kill switch em silêncio. Traga o túnel de volta, confirme que o contador de handshake se moveu e repita a verificação da tabela de estados do terceiro passo.

Registre uma linha por nó: rótulo, SSID, endereço do gateway, prefixo MAC, saída confirmada sim ou não, IPv6 coberto e comportamento com o túnel derrubado. O roaming é onde a resposta muda, então teste os cômodos que você realmente usa. Quando uma linha discorda das outras, esse nó é o que deve ser investigado, e a correção pertence ao dispositivo que detém o gateway daquela linha.