Isolamento de clientes Wi-Fi versus acesso local por VPN: o que bloqueia você
Dois dispositivos na mesma SSID ainda podem não se alcançar. Compare o que o isolamento de clientes Wi-Fi bloqueia com o que o túnel VPN encaminha.
Coloque dois celulares na mesma SSID de convidados e nenhum vê o outro, mas ambos chegam à internet. Adicione um cliente VPN em um deles e a impressora a três metros continua invisível, enquanto um servidor em outro continente responde aos ping. Nada está quebrado no túnel; há duas decisões de acesso separadas envolvidas, e apenas uma delas é sobre roteamento. O ponto de acesso decide se os clientes sem fio podem falar entre si, e o cliente VPN decide quais destinos saem pelo túnel. Confundir as duas produz horas de mudanças de configuração inúteis.
Os dois portões são independentes
O isolamento de clientes é uma decisão de comutação. O ponto de acesso aceita um quadro de uma estação associada, olha o destino, percebe que o destino é outra estação na mesma ponte e o descarta. O endereço IP da estação é irrelevante para essa decisão, e a VPN também.
O roteamento é outra decisão, tomada no cliente. A tabela de rotas da VPN decide se um pacote para 192.168.1.50 entra no túnel ou sai pela interface Wi-Fi. Se o pacote sai pelo Wi-Fi e o ponto de acesso isola os clientes, ele morre no ponto de acesso. Se o pacote entra no túnel, o ponto de acesso nunca vê o destino original e não pode isolar nada.
O que o isolamento bloqueia em um ponto de acesso típico
Os fabricantes entregam isso com vários nomes: isolamento de clientes, isolamento de AP, isolamento de estações ou uma rede de convidados que o implica. No OpenWrt a opção por interface é isolate dentro da configuração sem fio, como descrito na documentação sem fio, e uma SSID de convidados costuma receber a própria ponte e zona de firewall. O efeito é que quadros unicast entre clientes não são comutados pela ponte, então um ping, uma conexão SMB ou um trabalho de impressão para um vizinho falha mesmo que os dois dispositivos mostrem sinal cheio.
Os protocolos de descoberta sofrem primeiro e de forma mais visível. mDNS para impressoras e dispositivos de mídia vai por multicast para 224.0.0.251, SSDP usa 239.255.255.250, e se esses quadros atravessam a ponte depende do fabricante e de a conversão de multicast para unicast estar ativa. Um dispositivo ausente de uma lista é evidência mais fraca do que uma conexão direta falha a um endereço conhecido.
O que a VPN muda e o que ela não pode mudar
Um túnel completo assume a rota padrão, então as sub-redes locais só são alcançadas se o cliente mantiver uma rota mais específica para elas. Túneis divididos fazem o contrário e preservam o acesso local por projeto. Nenhuma das configurações pode forçar um ponto de acesso isolante a encaminhar um quadro entre dois de seus clientes, por isso permitir tráfego local no cliente VPN é necessário, mas não suficiente.
O caso inverso é igualmente comum. O ponto de acesso permite tráfego entre pares, o cliente VPN exclui a sub-rede local do túnel, e a impressora continua sem responder porque o firewall do host trata a rede Wi-Fi como pública. Três camadas, três padrões diferentes, e apenas a rota é visível na maioria dos registros da VPN.
Descubra qual portão está fechado
Comece com um teste que tira a VPN da equação: conecte dois dispositivos comuns à mesma SSID e tente chegar de um ao outro por endereço. Se falhar, o ponto de acesso isola e nenhuma configuração de VPN vai corrigir isso. Se funcionar, passe ao cliente e execute ip route get 192.168.1.50 no Linux ou Find-NetRoute -RemoteIPAddress 192.168.1.50 no Windows; a saída nomeia a interface que o pacote usará.
Quando a rota aponta para a interface Wi-Fi, o pacote sai sem criptografia e a pergunta passa a ser se o ponto de acesso e o firewall do host permitem. Quando a rota aponta para o túnel, o destino está sendo enviado ao servidor VPN, o que é errado para um dispositivo na mesma LAN e normalmente significa que a lista permitida do túnel é ampla demais.
Uma conexão direta à porta da impressora é um teste melhor do que uma lista de descoberta. nc -vz 192.168.1.50 9100 no Linux ou Test-NetConnection 192.168.1.50 -Port 9100 no PowerShell informa se o endereço é alcançável, antes que qualquer emparelhamento em nível de aplicação entre na discussão.
Escolha a correção para a rede em que você está
Em uma rede de hotel ou de convidados, o isolamento é deliberado e você não deve tentar contorná-lo. Trate o dispositivo local como inalcançável, use a VPN para chegar a um host que possa imprimir ou compartilhar, e pare de tratar a SSID como uma LAN.
Em casa, desativar o isolamento na SSID principal é razoável quando os dispositivos são seus, enquanto a SSID de convidados permanece isolada. A configuração fica na configuração sem fio do ponto de acesso, e pertence lá, não a exceções de firewall em cada cliente.
No escritório, suponha que o ponto de acesso, a VLAN e o firewall do host sejam todos intencionais. Escale com os resultados dos testes em vez de pedir que o isolamento seja desativado, porque uma rede que separa clientes normalmente protege alguma coisa.
Verifique a aplicação, não apenas o ping
Um ping bem-sucedido prova o caminho, não o serviço. As impressoras costumam aceitar 9100 cru ou IPP na 631 mas recusam descoberta, e um compartilhamento de arquivos exige 445 mais resolução de nomes funcionando. Confirme a porta usada pela aplicação e depois repita a tarefa real no dispositivo.
Mantenha as duas camadas separadas nas suas anotações: o que a rede Wi-Fi permite e o que a VPN encaminha. Na próxima vez que um dispositivo desaparecer de uma lista, essa separação dirá onde olhar primeiro.