O handshake do WireGuard funciona, mas a sub-rede do escritório não responde

O handshake é concluído, wg show relata transferência recente, e o endereço do túnel do servidor responde a um ping. Um host na LAN do servidor não. Três condições têm de valer ao mesmo tempo: o cliente tem de encaminhar o prefixo da LAN para o túnel, o servidor tem de encaminhar os pacotes, e a resposta precisa de um caminho de volta. Quando falta uma das três, o sintoma é idêntico.

AllowedIPs é tanto uma lista de acesso quanto uma tabela de rotas

No cliente, a lista AllowedIPs decide tanto o que pode ser enviado a esse par quanto quais rotas o WireGuard instala. Uma entrada de par que lista apenas o endereço do túnel do servidor instala uma única rota de host, então destinos da LAN nunca entram no túnel. Acrescentar o prefixo da LAN é a primeira coisa a verificar, e também é a alteração que mais costuma faltar depois de uma configuração copiada. Um par ampliado para uma rota padrão é outro projeto, e ele também moverá o tráfego de internet do cliente.

Mantenha a rota de host e o prefixo da LAN como entradas separadas. Se o escritório tem duas sub-redes, ambas pertencem à lista, e o segundo prefixo ausente produz uma falha que parece seletiva em vez de total.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

O encaminhamento e a tradução pertencem ao servidor

O servidor precisa do encaminhamento de IP ativado, de uma regra de encaminhamento que aceite o tráfego vindo do túnel e de uma regra de tradução em direção à sua interface LAN. É a tradução que faz o projeto funcionar sem tocar em cada host da rede do escritório. As respostas então voltam ao servidor em vez de irem a um endereço que a LAN nunca ouviu. Sem ela, cada host precisa de uma rota para a sub-rede do túnel e de uma regra de firewall que a permita, o que raramente é aceitável numa rede administrada por outra pessoa.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Regras adicionadas à mão desaparecem no reinício, então amarre-as à interface com os comandos de gancho da configuração do servidor. Um conjunto de regras que sobrevive à sua interface é como uma máquina acaba traduzindo tráfego para um túnel que já não existe.

Quando a LAN mudou e a regra não

A substituição de um roteador que renumera a sub-rede do escritório é a versão clássica desta falha. O túnel permanece ativo, o handshake permanece recente, e nada atrás do servidor responde, porque a regra de tradução ainda nomeia o endereço antigo. Scripts de instalação muitas vezes embutem o endereço LAN do servidor numa regra POSTROUTING, e depois de uma renumeração esse endereço não existe em nenhuma interface. Os pacotes são então reescritos para um destino que não pode responder.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Compare as duas saídas. Um alvo de tradução que não aparece na lista de interfaces é o bug, e corrigi-lo é uma alteração de uma linha depois que você o viu. A regra pode viver numa unidade gerada em vez de na configuração do WireGuard, então recarregue essa unidade após editar e confirme que a próxima inicialização não reescreve a sua alteração.

Dois locais atrás de NAT precisam de um lugar para se encontrar

Quando nenhum dos lados aceita conexões de entrada, a resposta prática é um host pequeno com um endereço público e duas interfaces WireGuard. Cada local se conecta para fora, o host central lista a LAN de cada par na sua própria AllowedIPs, e o encaminhamento transporta pacotes entre os dois túneis. Nada no firewall de nenhum dos locais precisa mudar, e por isso este projeto se espalha facilmente.

O roteamento entre os locais mantém os endereços de origem originais e, portanto, mantém significativo o registro por host. A tradução no host central é mais simples quando as duas LANs se sobrepõem, ao custo de perder a identidade da origem nos logs. Decida qual propriedade importa antes de escolher.

Separe as camadas com quatro verificações

Faça uma verificação por camada em vez de mudar três coisas e esperar. A primeira mostra a idade do handshake e os contadores de cada par. A segunda mostra se o cliente realmente encaminha esse destino para o túnel. A terceira e a quarta dizem se o pedido chegou e se alguma política o descartou após a chegada.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

Um pedido que chega e não gera resposta aponta para o caminho de resposta ou para o host da LAN. Um pedido que nunca chega aponta para AllowedIPs ou para a rota do cliente. Esses dois resultados exigem correções diferentes, e a captura é o que os distingue.