Un par de WireGuard inaccesible mentres outro funciona: lista de comprobación

Un par de WireGuard pasa tráfico e un segundo completa o handshake pero nunca chega a nada detrás do túnel. O par que funciona diche que a interface, o porto UDP e a clave do servidor probablemente están ben. Non di nada sobre as AllowedIPs do segundo par, o seu enderezo de orixe interno nin as regras de reenvío entre ambos. Percorra a lista en orde e detéñase no primeiro paso cuxa condición falle.

Paso 1: Anote a ruta que debería seguir o paquete

Dous clientes no mesmo concentrador non se alcanzan automaticamente. Nun deseño de concentrador e radios, o servidor recibe o paquete en wg0 e debe reenvialo de novo por wg0 cara ao outro par, o que esixe reenvío IP e unha regra de reenvío. Nun deseño directo de par a par, cada lado necesita o extremo do outro e o enderezo do seu túnel dentro das AllowedIPs. Decida que deseño está depurando antes de ler calquera configuración.

A ruta esperada tamén lle di onde mirar. Se o paquete debe cruzar o concentrador, o salto que falla é ou as AllowedIPs do emisor, ou o reenvío do concentrador, ou as AllowedIPs do receptor. Se debe ir directo, o concentrador é irrelevante e os campos de extremo dos dous pares son os que importan.

Paso 2: Compare as AllowedIPs nos dous lados, non só nun

WireGuard usa as AllowedIPs á vez como táboa de encamiñamento e como lista de acceso. Ao enviar, o enderezo de destino búscase nas AllowedIPs do par para escoller o túnel; ao recibir, o enderezo de orixe interno debe caer dentro das AllowedIPs do par emisor ou o paquete descártase. Un rango que falta en calquera dos dous lados produce o mesmo síntoma: o transporte funciona, a carga desaparece.

Lea o estado vivo en lugar do ficheiro, porque unha recarga pode fallar en silencio: sudo wg show wg0 allowed-ips. No servidor, a entrada do par que falla debe incluír o seu enderezo de túnel, por exemplo 10.90.0.3/32. No cliente, a entrada do par servidor debe incluír o destino que está a probar, xa sexa o enderezo de túnel do concentrador ou a subrede remota. Os rangos superpostos fan ambigua a busca e poden seleccionar un par que non pretendía, así que mantéñaos separados.

Paso 3: Comprobe o enderezo de orixe interno

Un cliente que encamiña 10.90.0.3 por wg0 pero envía paquetes desde o seu enderezo Wi-Fi será rexeitado polo receptor, porque a orixe non coincide coas AllowedIPs do par. Confirme que escolle realmente o núcleo con ip route get 10.90.0.3 from 10.90.0.2, e confirme o enderezo asignado á interface do túnel con ip -brief addr show wg0.

No host Linux receptor, a filtragem de ruta inversa é unha segunda porta. Un rp_filter estrito na interface que posúe a ruta de volta pode descartar tráfico de túnel cuxa ruta de retorno non coincide coa interface pola que chegou. Comprobe o valor efectivo antes de desactivalo; en moitas topoloxías a corrección correcta é unha ruta, non un filtro relaxado.

Paso 4: Revise o reenvío do concentrador e a ruta de volta

Se o concentrador debe reenviar entre pares, o núcleo necesita net.ipv4.ip_forward=1, e o cortalumes debe aceptar o fluxo reenviado: entrada por wg0, saída por wg0, desde o enderezo de túnel do emisor ata o do receptor. Un fallo habitual é unha regra de entrada que acepta UDP 51820 pero ningunha regra de reenvío], de xeito que o handshake ten éxito e a carga morre. Enumere as regras efectivas con sudo nft list ruleset ou o equivalente para o seu xestor de cortalumes.

Despois comprobe a resposta. O host de destino debe ter unha ruta de volta ao emisor, xa sexa polo concentrador ou pola súa propia pasarela. Se o concentrador tamén fai NAT na subrede do túnel, confirme que a tradución se aplica ao fluxo reenviado e que a resposta chega ao concentrador antes de que caduque o estado. Un fallo unidireccional que parece un problema de clave adoita ser só esta ruta de volta.

Por último, separe o handshake dos datos. Un par que completa o handshake pero atasca en transferencias grandes adoita ter un problema de MTU ou MSS nesa ruta concreta, non un problema de AllowedIPs. Probe primeiro cun ping pequeno, despois cun de tamaño completo, e compare os dous pares.

Paso 5: Cambie unha cousa e manteña intacto o par que funciona

Faga un só cambio na ruta que falla e volva probar ambos os pares. Substituír as AllowedIPs de cada par por 0.0.0.0/0 é a forma máis rápida de romper o par que xa funcionaba, porque cambia a decisión de encamiñamento de todo o tráfico desa interface. Edite esa única entrada, recargue e volva ler o estado vivo.

Anote que ruta funcionou, cal fallou e a saída exacta do comando para cada unha. Esa comparación vale máis que un informe xeral de que a VPN está rota, e é o primeiro que pedirá a seguinte persoa.