WireGuard só funciona despois de que o servidor envíe: coñecemento do extremo

O túnel parece funcionar só despois de que o servidor envía algo primeiro. Inicie desde o cliente e non ocorre nada, agarde uns segundos, ténteo de novo e logra. O diagnóstico habitual é un NAT roto, e o diagnóstico habitual é erróneo. O que cambiou é que un par aprendeu onde vive o outro.

Coñecemento do extremo, non accesibilidade

Un par de WireGuard non iniciará un handshake ata saber onde envialo. A configuración fornéceo como un extremo de enderezo e porto, e o estado en execución segue o extremo no que cre actualmente.

wg show mostra ambos os lados dese cadro, e un par sen extremo na saída non pode iniciar nada, por correctas que sexan a súa clave pública e os seus prefixos permitidos. Compare a visión do cliente coa do servidor antes de cambiar calquera regra, porque ambos discrepan a miúdo sobre quen sabe que.

Como aprende un par un extremo

WireGuard é deliberadamente silencioso. Cando un paquete correctamente autenticado chega desde un enderezo que o par non esperaba, a implementación actualiza o extremo dese par á nova fonte, e así é como funciona a itinerancia nun portátil que cambia de rede. Ese comportamento explica a dependencia da dirección: se o servidor envía primeiro e o seu paquete chega ao cliente, o cliente aprende o enderezo actual do servidor e pode responder. Ata entón non ten onde enviar. O mecanismo é itinerancia autenticada e non un atallo de confianza no primeiro uso, porque o paquete tiña que ser válido antes de que o extremo se movese.

A documentación das ferramentas para wg describe esa actualización, e paga a pena lela unha vez se vai deseñar arredor diso.

A tradución con estado engade a súa propia dirección

Onde o UDP pasa por unha pasarela que traduce, a pasarela crea estado para o primeiro paquete que ve. RFC 4787 describe ese comportamento e os tempos de espera que acaban eliminando a asignación. Unha asignación inactiva caduca, e un paquete entrante do lado afastado é entón descartado pola pasarela antes de chegar ao equipo. Un túnel que funcionaba toda a mañá deixa de responder pola tarde exactamente por este motivo.

Este é un segundo mecanismo independente que produce o mesmo síntoma direccional. Tanto o coñecemento do extremo como o estado de tradución teñen que ser correctos, e arranxar un non arranxa o outro.

Configure a dirección que realmente quere

Para un cliente que debe iniciar a conexión, poña o extremo do servidor na sección de pares do cliente e déixeo alí. Confiar en que o servidor envíe primeiro é confiar nun accidente da orde do tráfico que cambiará nunha rede tranquila. A configuración debería declarar a dirección prevista, non descubrila.

Para un par detrás dunha tradución que debe seguir sendo accesible, active un keepalive persistente nese lado. Un keepalive cada 25 segundos é o valor inicial habitual, e o seu propósito é manter a asignación aberta en lugar de probar o túnel. Escolla un só lado para levalo, porque activalo en ambos duplica o tráfico e o ruído do rexistro sen mellorar o resultado.

Compare o estado antes e despois do desencadeante

Capture as dúas vistas no momento en que falla e logo outra vez despois de que o servidor envíe. O primeiro comando mostra os extremos e a idade do handshake. O segundo mostra se existe unha entrada de tradución para o porto. A captura mostra que dirección cruzou realmente o cable, e a comprobación de ruta confirma que o cliente non envía ese tráfico a outro lugar por completo.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Anote a columna do extremo e a entrada de tradución xuntas. Un par sen extremo e unha pasarela sen asignación son dous fallos distintos. Só un deles se corrixe cun keepalive.