O handshake de WireGuard funciona, pero a subrede da oficina non responde

O handshake complétase, wg show informa dunha transferencia recente e o enderezo do túnel do servidor responde a un ping. Un host da LAN do servidor non. Tres condicións deben cumprirse á vez: o cliente debe encamiñar o prefixo da LAN cara ao túnel, o servidor debe reenviar os paquetes e a resposta necesita un camiño de volta. Cando falta unha das tres, o síntoma é idéntico.

AllowedIPs é á vez unha lista de acceso e unha táboa de encamiñamento

No cliente, a lista AllowedIPs decide tanto o que se pode enviar a ese par como que rutas instala WireGuard. Unha entrada de par que só enumera o enderezo do túnel do servidor instala unha ruta de host, así que os destinos da LAN nunca entran no túnel. Engadir o prefixo da LAN é o primeiro que hai que verificar, e tamén é o cambio que máis adoita faltar tras copiar unha configuración. Un par ampliado a unha ruta predeterminada é outro deseño, e tamén moverá o tráfico de internet do cliente.

Manteña a ruta de host e o prefixo da LAN como entradas separadas. Se a oficina ten dúas subredes, ambas pertencen á lista, e o segundo prefixo ausente produce un fallo que parece selectivo en 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 reenvío e a tradución pertencen ao servidor

O servidor necesita o reenvío de IP activado, unha regra de reenvío que acepte o tráfico que chega do túnel e unha regra de tradución cara á súa interface de LAN. A tradución é o que fai funcionar o deseño sen tocar cada host da rede da oficina. Entón as respostas volven ao servidor en vez de a un enderezo que a LAN nunca oíu. Sen ela, cada host necesita unha ruta para a subrede do túnel e unha regra de devasas que a permita, o que raramente é aceptable nunha rede que xestiona outra persoa.

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

As regras engadidas a man desaparecen ao reiniciar, así que ateas á interface cos comandos de gancho da configuración do servidor. Un conxunto de regras que sobrevive á súa interface é como unha máquina acaba traducindo tráfico para un túnel que xa non existe.

Cando a LAN se mudou e a regra non

A substitución dun router que renumera a subrede da oficina é a versión clásica deste fallo. O túnel segue activo, o handshake segue fresco e nada detrás do servidor responde, porque a regra de tradución aínda nomea o enderezo antigo. Os scripts de instalación adoitan incrustar o enderezo de LAN do servidor nunha regra POSTROUTING, e tras unha renumeración ese enderezo non existe en ningunha interface. Os paquetes reescríbense entón cara a un destino que non pode responder.

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

Compare as dúas saídas. Un destino de tradución que non aparece na lista de interfaces é o erro, e corrixilo é un cambio dunha liña unha vez que o viu. A regra pode vivir nunha unidade xerada en vez de na configuración de WireGuard, así que recargue esa unidade tras editala e confirme que o seguinte arranque non reescribe o seu cambio.

Dous sitios detrás de NAT necesitan un lugar onde atoparse

Cando ningún dos dous lados acepta conexións entrantes, a resposta práctica é un host pequeno cun enderezo público e dúas interfaces de WireGuard. Cada sitio conecta cara a fóra, o host intermedio enumera a LAN de cada par na súa propia AllowedIPs, e o reenvío transporta paquetes entre os dous túneles. Nada do devasas de ningún dos dous sitios ten que cambiar, e por iso este deseño se estende con facilidade.

O encamiñamento entre os sitios conserva os enderezos de orixe orixinais e, por tanto, mantén significativo o rexistro por host. Traducir no host intermedio é máis simple cando as dúas LAN se solapan, a costa de perder a identidade da orixe nos rexistros. Decida que propiedade importa antes de escoller.

Separe as capas con catro comprobacións

Executen unha comprobación por capa en vez de cambiar tres cousas e esperar. A primeira mostra a antigüidade do handshake e os contadores de cada par. A segunda mostra se o cliente encamiña realmente ese destino cara ao túnel. A terceira e a cuarta dinlle se a solicitude chegou e se algunha política a descartou tras a chegada.

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

Unha solicitude que chega e non obtén resposta apunta á ruta de resposta ou ao host da LAN. Unha solicitude que nunca chega apunta a AllowedIPs ou á ruta do cliente. Eses dous resultados necesitan correccións distintas, e a captura é o que os distingue.