Prefixo de host en WireGuard: por que funciona un enderezo e o resto non

O túnel está levantado, o handshake ocorre cada dous minutos e exactamente un enderezo do outro lado responde. Os pings ao enderezo do túnel do par funcionan; nada detrás del non. Alguén le a configuración da interface, ve un prefixo de host e conclúe que a máscara está mal. Ampliala a un /24 arranxa o ping durante un tempo e despois rompe outra cousa. O prefixo nunca foi o problema, e a ruta que faltaba non é a que controla a máscara.

Que crea realmente o prefixo da interface

En Linux, asignar un enderezo a unha interface crea unha ruta conectada para ese prefixo. Se asignas un prefixo de host, a ruta conectada cobre un enderezo. Se asignas un /24, cobre 256, e cada un deles pasa a considerarse alcanzable por esa ligazón.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Un prefixo de host é unha elección completamente normal para un túnel punto a punto, porque hai exactamente un par no outro extremo. O terceiro comando é o que responde á pregunta do usuario: di que interface usaría o kernel para ese destino, e non mostrará nada útil se ningunha ruta coincide.

Esa é toda a explicación do síntoma. Un enderezo responde porque existe unha ruta conectada para el, ou porque a lista permitida do par resulta que o inclúe. Todo o demais non ten ruta e descártase antes de que WireGuard interveña. O túnel está san todo o tempo, e por iso o contador de handshakes segue parecendo tranquilizador.

AllowedIPs son dúas regras cun só nome

A lista permitida por par de WireGuard fai dous traballos á vez, e a sintaxe de configuración fai que parezan un. Á entrada, autoriza que enderezos de orixe pode presentar un par. Á saída, selecciona a que par se envía un paquete, atopando a coincidencia máis específica.

Ningún dos dous traballos é encamiñamento. O kernel aínda ten que decidir que un paquete pertence á interface do túnel antes de que WireGuard o mire, e esa decisión vén da táboa de rutas. Unha entrada de par cunha lista permitida ampla non instala unha ruta por si mesma.

Por iso unha configuración pode parecer completa e comportarse de forma asimétrica. O cliente envía cara ao outro extremo porque existe unha ruta, e as respostas nunca chegan porque a lista permitida do outro extremo non autoriza a orixe do cliente, ou porque o outro extremo non ten ruta de volta. Ambas as direccións son decisións separadas con modos de fallo separados. Anotar cal estás a probar é metade do diagnóstico.

De onde vén a ruta

Se usas wg-quick, as rutas xéranse por ti a partir da lista permitida de cada par, a non ser que puxeses Table = off e te fixeses cargo ti mesmo. Ese é o comportamento que documenta a ferramenta, e é a razón pola que unha configuración sen directivas de ruta explícitas segue funcionando.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Compara a lista permitida coas rutas que existen de feito. Un par que permite unha subrede enteira pero produciu só unha ruta de host significa que o axudante nunca correu, ou que xestionas a interface directamente con wg e ip, e nese caso nada xera rutas por ti.

Cando o xestionas á man, a ruta é unha liña e a súa forma é explícita: o destino pola interface, sen pasarela porque a ligazón é punto a punto. Engadila non é unha solución de emerxencia para un prefixo malo; é a metade que faltaba dun deseño que decidiu encargarse do encamiñamento.

Ampliar o prefixo non engade a entrada do par

A solución tentadora é cambiar o enderezo a un /24 para que a ruta conectada cubra a LAN do servidor. Parece funcionar, e a razón de que pareza funcionar é que a ruta conectada agora coincide, non que WireGuard aprendese algo novo.

O que tamén fixeches foi reclamar todo o rango como directamente alcanzable por esa ligazón, incluídos enderezos que pertencen a outros pares ou a unha LAN que en realidade está detrás do servidor. O tráfico a eses enderezos agora entra no túnel, e se sae polo outro lado depende do encamiñamento e das listas permitidas do propio servidor.

O lado criptográfico non se ve afectado en ningún caso. WireGuard segue necesitando unha entrada na lista permitida que cubra o destino para escoller un par, e o outro extremo segue necesitando unha entrada que cubra a túa orixe para aceptala. Un prefixo de interface máis amplo non pode fornecer ningunha das dúas.

Confirma ambas as direccións antes de cambiar nada

Traballa os dous extremos por separado e anota o que di cada un. No cliente, a ruta e a entrada do par; no servidor, a imaxe espello máis a súa propia ruta de volta:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

A captura é o que zanxa as discusións sobre a dirección. Se os paquetes de saída aparecen na interface do túnel e o servidor non rexistra nada, o extremo remoto está a rexeitalos, normalmente porque a túa orixe está fóra da súa lista permitida. Se non aparece nada de todo, falta a ruta ou apunta a outro sitio.

Despois arranxa o extremo máis estreito. Unha entrada na lista permitida do lado do servidor para o enderezo do teu cliente e unha entrada do lado do cliente para a subrede de destino é a forma normal, e deixa intacto o prefixo da interface. Só amplíes o prefixo se o plan de enderezos quere de verdade unha subrede compartida nesa ligazón, e faino como un cambio de plan en vez dun paso de depuración.