Botão de emergência ou acesso à LAN? Duas respostas para o WireGuard
O cliente Windows bloqueia o tráfego fora do túnel quando o perfil indica 0.0.0.0/0. Decida de que propriedade precisa e expresse o valor predefinido em conformidade.
O handshake conclui-se, a navegação funciona, e a impressora, o NAS e os anfitriões SSH locais desaparecem. No cliente Windows isto normalmente não é de todo uma falha de encaminhamento: um par cujos prefixos permitidos incluam o valor predefinido literal ativa Bloquear tráfego fora do túnel, e essa opção é implementada como regras de firewall que descartam os pacotes que saem por qualquer outra interface. A tabela de rotas continua a listar a sub-rede local como ligação direta, e é por isso que o sintoma parece uma mentira. Três condições decidem o que fazer, e apenas uma delas diz respeito ao encaminhamento.
Duas falhas usam o mesmo sintoma
A primeira falha é o modo de encerramento seguro do cliente, e a sua assinatura é que tudo o que está fora do túnel pára enquanto o próprio túnel funciona na perfeição. A segunda é um problema real de acessibilidade: uma rota em falta, uma entrada em falta no servidor para uma sub-rede atrás do cliente, ou duas redes que partilham o mesmo intervalo de endereços. Ambas produzem uma máquina que navega e não imprime, e as suas correções são opostas, pelo que o diagnóstico tem de vir antes da configuração.
A observação decisiva é se a sub-rede local ainda está presente na tabela de rotas enquanto o tráfego para ela é descartado.
Três condições decidem a resposta
Primeiro, esta máquina precisa de encerramento seguro? Se a resposta for sim, um túnel que cai deve parar o tráfego em vez de o deixar regressar à interface física, e esse requisito pesa mais do que a conveniência local. Segundo, os dispositivos locais têm de continuar acessíveis enquanto o túnel está ativo? A impressão, o armazenamento em rede e as consolas de gestão locais são os motivos habituais, e são requisitos legítimos, não exceções pelas quais se pede desculpa. Terceiro, o perfil exprime o valor predefinido como o literal 0.0.0.0/0? É precisamente esse detalhe que aciona as regras do cliente, e é editável.
Responda a estas três por escrito antes de tocar num perfil, porque cada resposta aponta para uma configuração diferente.
Escolha o encerramento seguro e abdique da LAN
Se as fugas forem mais importantes do que a acessibilidade local, mantenha o valor predefinido literal e deixe Bloquear tráfego fora do túnel ativado. É uma posição coerente: a máquina é tratada como um dispositivo que ou está dentro do túnel ou está offline, e os serviços locais são alcançados a partir de outro dispositivo ou através do túnel se o servidor os encaminhar. O custo é real e deve constar das notas de implementação, em vez de ser descoberto pela pessoa que precisa de imprimir.
Esta é a escolha certa para máquinas que tratam de trabalho que não deve aparecer numa rede de café quando o túnel cai. É um mau valor predefinido para um portátil doméstico que também precisa do digitalizador.
Escolha o acesso à LAN e exprima o valor predefinido de outro modo
Se os dispositivos locais tiverem de continuar acessíveis, exprima a mesma cobertura sem o prefixo predefinido literal. Dois semi-prefixos cobrem todos os endereços IPv4, o par equivalente cobre IPv6, e o cliente já não insere as regras de bloqueio porque a cadeia que procura está ausente.
[Peer]
AllowedIPs = 0.0.0.0/1
AllowedIPs = 128.0.0.0/1
AllowedIPs = ::/1
AllowedIPs = 8000::/1
Endpoint = vpn.example.net:51820
Desmarcar essa caixa faz com que o cliente escreva os mesmos dois pares no perfil, pelo que comparar o ficheiro gerado com o bloco acima é uma forma rápida de confirmar o mecanismo em vez de o adivinhar. Daí decorrem duas consequências. A cobertura é idêntica, pelo que nada mais do túnel muda. A proteção não é idêntica: sem as regras, um túnel que cai deixa a máquina a usar a sua interface física, e era precisamente isso que o encerramento seguro impedia.
Verifique os outros dois suspeitos de qualquer forma
Resolvida a questão da firewall, confirme que a sub-rede local está realmente a ser encaminhada e que a extremidade remota conhece tudo o que está atrás deste cliente. Um servidor que tem de alcançar uma LAN atrás de um cliente precisa desse prefixo na lista permitida do cliente no concentrador; se o omitir, o concentrador não consegue escolher um par para esses endereços, e nenhuma configuração do cliente cria um.
Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultOutboundAction
route print 0.0.0.0
A categoria de rede importa mais do que as pessoas esperam: um adaptador de túnel recentemente criado e classificado como público altera as regras que lhe são aplicáveis, e o resultado pode parecer um bloqueio da firewall na extremidade remota. A impressão das rotas mostra se existe sequer um valor predefinido, o que separa um problema de política de uma rota em falta.
Depois teste três coisas numa só sessão: a internet, um anfitrião local por endereço e um anfitrião através do túnel. O handshake só prova que as chaves coincidem, pelo que são os três testes que demonstram a política. Se o anfitrião local continuar a recusar com a opção desmarcada, os suspeitos restantes são a rota, a lista permitida da extremidade remota e a sub-rede duplicada, por essa ordem.