A VPN da FRITZ!Box conecta mas nada responde: WireGuard ou IPSec
Um túnel FRITZ!Box conectado que não alcança a LAN é um problema de endereçamento. Verifique os quatro campos IPSec ou o peer WireGuard antes de reimportar.
O túnel informa conectado, o ícone está verde e nada na LAN de casa responde. É a queixa mais comum sobre o acesso remoto da FRITZ!Box e quase nunca é o próprio túnel. O plano de endereços, a identidade da sub-rede ou a tabela de rotas do cliente estão errados. Qual deles você vai acabar depurando depende de ter escolhido WireGuard ou o mais antigo IPSec Fernzugang, então comece sabendo o que realmente configurou.
O túnel sobe e a LAN continua em silêncio
Um túnel que se estabelece prova que as chaves e o endpoint estão corretos. Não prova que o cliente recebeu um endereço para o qual a caixa consiga encaminhar, nem que o cliente saiba quais prefixos pertencem ao túnel. São dois sucessos distintos, e só o segundo permite chegar a uma impressora.
Verifique primeiro o endereço do cliente, depois a tabela de rotas dele.
Se o endereço atribuído estiver fora da sub-rede da LAN, a caixa não tem para onde encaminhar de volta. Se estiver dentro da faixa DHCP, a caixa pode entregar o mesmo endereço a um dispositivo local. As duas coisas produzem um túnel que conecta e uma LAN que ignora você.
O que cada opção configura de fato
A opção IPSec gera um arquivo de configuração para um usuário, contendo a chave pré-compartilhada e o endereçamento. Você o importa num cliente que fale o mesmo perfil, o que no Windows geralmente significa a ferramenta do fabricante e não o cliente embutido. A opção WireGuard gera um peer para um dispositivo: um par de chaves, um endereço dentro do túnel e um endpoint.
Essa diferença decide o seu modelo de manutenção. Cada dispositivo WireGuard é um peer separado com a própria chave, então revogar um celular perdido significa apagar um peer enquanto os outros continuam funcionando. O IPSec revoga mudando o segredo compartilhado ou a configuração do usuário, o que é mais grosseiro e afeta todo dispositivo que o utiliza.
Nenhuma das opções está obsoleta. O caminho IPSec continua sendo o suportado onde o extremo remoto não consegue executar WireGuard.
Os campos IPSec que produzem um túnel morto
Quatro valores precisam concordar com a sua LAN, e três deles falham de um jeito que parece um túnel quebrado.
| Value | What breaks when it is wrong |
|---|---|
| LAN subnet | The client routes nothing, or routes the wrong prefix |
| Network address | The configuration looks valid and the tunnel never establishes |
| DHCP range | No address is left to assign to tunnel clients |
| DNS server | The tunnel works and name resolution does not |
O endereço de rede é o que pega as pessoas. Uma sub-rede é identificada pelo primeiro endereço, que normalmente termina em zero, e digitar ali um endereço de host produz uma configuração que parece totalmente plausível e nunca conecta. A faixa DHCP importa por outro motivo: os clientes do túnel costumam ser atribuídos acima dela, então uma faixa que consome a sub-rede inteira não deixa nada para distribuir.
Sub-redes sobrepostas são o outro caso clássico. Se a LAN remota a que você se junta usa o mesmo prefixo da LAN em que você está sentado, o roteamento não consegue distingui-las, e renumerar um dos lados é a única correção real. Nenhuma quantidade de configuração no cliente resolve isso.
Por que o WireGuard falha de outra forma
O WireGuard não tem chave pré-compartilhada para digitar errado, então as falhas se agrupam em torno da definição do peer. Uma lista de IPs permitidos que omite o prefixo da LAN produz um túnel que não transporta nada, porque o cliente nunca envia para ele tráfego destinado à LAN. Uma chave pública antiga em qualquer dos lados produz um aperto de mão que nunca se completa. Um endpoint ausente ou uma porta errada produzem silêncio em vez de erro.
Compare os dois lados campo por campo em vez de reimportar o arquivo e torcer.
A única falha comum é a colisão de sub-redes. O WireGuard constrói tranquilamente um túnel para uma rede que se sobrepõe à sua, e então a tabela de rotas decide qual dos dois prefixos idênticos vence.
Comprove de fora e depois guarde um caminho de volta
Teste de uma conexão móvel, nunca de dentro da LAN, porque de dentro você está testando um caminho que não envolve o túnel em nada. Anote qual porta cada opção usa antes de ativá-la, e encaminhe essa porta para a caixa.
Guarde o arquivo gerado em algum lugar acessível sem o túnel, e de passagem anote o nome externo da caixa.
Uma configuração que nunca foi testada de fora é um plano, não um caminho de acesso remoto que funciona. Teste um host da LAN por endereço e não por nome, para que uma falha de DNS não seja confundida com uma falha de roteamento.