O handshake de WireGuard funciona pero non hai internet: segue o paquete

O túnel está activo, wg show informa dun handshake recente, podes facer ping ao enderezo do túnel do servidor e nada máis aló responde. O instinto é rexenerar as claves ou volver compartir a configuración. Iso cambia xusto a parte do camiño que xa está demostrado que funciona.

Un handshake completado di que os dous pares coinciden nas claves, que UDP chega ao extremo e que o enrutamento criptográfico acepta o paquete. Non di nada sobre se o paquete pode saír do servidor despois.

Así que segue un só paquete en lugar de adiviñar. Hai catro lugares onde pode morrer, e cada un deixa un rastro distinto.

Que demostra realmente o handshake

WireGuard é un protocolo UDP que establece unha sesión cun handshake Noise e despois cifra os paquetes dun par. Cando wg show mostra un handshake de hai uns segundos e un contador de transferencia crecente, o extremo, as claves e a clave pública do par son todos correctos.

O que non demostra é que o teu cliente envíe tráfico cara a internet á interface, que o servidor estea disposto a reenvialo ou que unha resposta poida atopar o camiño de volta. Esas son decisións de enrutamento do núcleo e do cortafogos, e tómanse fóra do túnel.

Por iso facer ping ao enderezo do túnel do servidor é unha proba tan enganosa. Ese paquete está dirixido ao propio servidor, así que remata localmente. Nunca necesita reenvío, nunca necesita tradución e nunca necesita unha ruta de volta desde internet.

AllowedIPs é unha decisión de enrutamento

No cliente, AllowedIPs fai dous traballos. É a táboa de enrutamento de clave criptográfica que decide que enderezos de destino se envían ao túnel deste par, e é a lista de enderezos de orixe que o par aceptará de ti. Se a configuración do cliente só enumera 10.8.0.0/24, os destinos públicos nunca entran na interface e a túa ruta predeterminada habitual lévaos fóra do túnel. Entón o túnel funciona perfectamente e non fai nada do que querías.

Mira o que o cliente instalou realmente en lugar do que di o ficheiro de configuración:

wg show wg0 allowed-ips
ip route get 1.1.1.1

O segundo comando é o decisivo. Se a resposta nomea a túa interface física e a pasarela habitual, o paquete non se está tunelizando e ningún cambio do lado do servidor o arranxará. Engade 0.0.0.0/0 para IPv4 e ::/0 para IPv6 por separado; unha regra que o abrangue todo para unha familia deixa a outra no seu camiño orixinal, e iso é unha causa habitual dun túnel IPv4 que funciona e dunha consulta IPv6 atascada.

Onde morre o paquete na pasarela

Se a ruta é correcta e o paquete segue sen ir a ningures, chega ao servidor e detense alí. Catro comprobacións cobren a maioría das pasarelas.

Reenvío. sysctl net.ipv4.ip_forward devolvendo 0 é a resposta clásica, e moitas distribucións seguen en 0 por defecto. Debe ser 1, e fixarse de forma persistente nun ficheiro sysctl en lugar de cun comando que desaparece ao reiniciar. O reenvío de IPv6 é un interruptor aparte.

A política de filtrado. Unha cadea FORWARD con política de descarte por defecto descartará o tráfico do túnel mentres permite o tráfico cara ao propio host, o que encaixa exactamente co síntoma. Le o conxunto de regras vivo, non un ficheiro gardado: nft list ruleset ou iptables -S.

Tradución ou enrutamento. Os clientes con enderezos de túnel privados necesitan ou ben NAT de orixe na interface de saída do servidor, ou ben un prefixo enrutado que a rede superior saiba devolver. Escoller entre ambos segue o plan de enderezos. Engadir MASQUERADE a unha rede que xa enruta o teu prefixo de volta é inofensivo pero inútil, e omitilo onde non existe ningunha ruta deixa as respostas dirixidas a un rango privado non enrutable.

O camiño de volta. En deseños enrutados, o router superior necesita unha ruta que apunte ao teu servidor. A rede do provedor tamén pode bloquealo: varias nubes activan unha comprobación de orixe e destino na instancia, que descarta en silencio os paquetes cuxa orixe non é o enderezo propio da instancia ata que se desactiva esa comprobación.

O DNS falla de forma distinta ao enrutamento

Un paquete a un enderezo coñecido e unha consulta de nome son fallos separados, e as mensaxes de erro enganan en direccións opostas. Se ping 1.1.1.1 funciona e un navegador non carga nada, a ruta está ben e a resolución de nomes non. Se o ping en si falla, o DNS é irrelevante e volves á sección anterior.

wg-quick pode establecer un resolutor a partir da liña DNS = da configuración, e systemd-resolved ten o seu propio comportamento por ligazón. Unha VPN que sobrescribe o resolutor cun enderezo só accesible dentro do túnel fará fallar cada consulta no momento en que caia o túnel, o que parece que o túnel rompe internet.

Unha orde que produce probas

Executa primeiro a comprobación do lado do cliente, porque é un só comando e elimina a metade das posibilidades. Logo confirma se o servidor está pensado para ser unha saída a internet; unha pasarela feita para acceso privado non está rota cando fallan os destinos públicos.

No servidor, observa a interface mentres envías un ping desde o cliente: tcpdump -ni wg0 icmp debería mostrar a petición, e tcpdump -ni eth0 icmp debería mostrar que sae, traducida ou non. Se aparece na primeira e nunca na segunda, a parada é local ao servidor. Se sae e non volve ningunha resposta, o problema está máis arriba, e esa é outra conversa.

Por último, fai que a corrección sobreviva a un reinicio. O reenvío pertence a un ficheiro sysctl, as regras do cortafogos pertencen ao servizo que as carga, e as rutas do cliente pertencen á configuración que levanta a interface en lugar dun shell que esquecerás. Vólvete conectar, repite as mesmas dúas probas e confirma que os contadores se moven.