WireGuard només funciona després que el servidor enviï: coneixement de l'extrem

El túnel sembla funcionar només després que el servidor enviï alguna cosa primer. Inicieu des del client i no passa res, espereu uns segons, torneu-ho a provar i funciona. El diagnòstic habitual és un NAT trencat, i el diagnòstic habitual és erroni. El que ha canviat és que un dels parells ha après on viu l'altre.

Coneixement de l'extrem, no accessibilitat

Un parell de WireGuard no iniciarà un handshake fins que no sàpiga on enviar-lo. La configuració ho proporciona com un extrem d'adreça i port, i l'estat en execució segueix l'extrem en què creu actualment.

wg show mostra les dues bandes d'aquesta imatge, i un parell sense extrem a la sortida no pot iniciar res, per correctes que siguin la seva clau pública i els prefixos permesos. Compareu la visió del client amb la del servidor abans de canviar cap regla, perquè tots dos sovint no coincideixen sobre qui sap què.

Com aprèn un parell un extrem

WireGuard és deliberadament silenciós. Quan un paquet correctament autenticat arriba d'una adreça que el parell no esperava, la implementació actualitza l'extrem d'aquest parell a la nova font, i així és com funciona l'itinerància en un portàtil que canvia de xarxa. Aquest comportament explica la dependència de la direcció: si el servidor envia primer i el seu paquet arriba al client, el client aprèn l'adreça actual del servidor i pot respondre. Fins llavors no té on enviar. El mecanisme és itinerància autenticada i no una drecera de confiança en el primer ús, perquè el paquet havia de ser vàlid abans que l'extrem es mogués.

La documentació de les eines per a wg descriu aquesta actualització, i val la pena llegir-la un cop si voleu dissenyar al voltant d'això.

La traducció amb estat afegeix la seva pròpia direcció

Quan l'UDP passa per una passarel·la que tradueix, la passarel·la crea estat per al primer paquet que veu. RFC 4787 descriu aquest comportament i els temps d'espera que acaben eliminant la traducció. Una traducció inactiva caduca, i la passarel·la descarta llavors un paquet entrant del costat llunyà abans que arribi a l'amfitrió. Un túnel que funcionava tot el matí deixa de respondre a la tarda exactament per aquest motiu.

Aquest és un segon mecanisme independent que produeix el mateix símptoma direccional. Tant el coneixement de l'extrem com l'estat de traducció han de ser correctes, i arreglar-ne un no arregla l'altre.

Configureu la direcció que realment voleu

Per a un client que ha d'iniciar la connexió, poseu l'extrem del servidor a la secció de parells del client i deixeu-lo allà. Confiar que el servidor enviï primer és confiar en un accident de l'ordre del trànsit que canviarà en una xarxa tranquil·la. La configuració hauria de declarar la direcció prevista, no descobrir-la.

Per a un parell darrere d'una traducció que ha de romandre accessible, activeu un keepalive persistent en aquest costat. Un keepalive cada 25 segons és el valor inicial habitual, i la seva finalitat és mantenir la traducció oberta, no provar el túnel. Trieu un sol costat per portar-lo, perquè activar-lo als dos duplica el trànsit i el soroll del registre sense millorar el resultat.

Compareu l'estat abans i després del desencadenant

Captureu les dues vistes en el moment que falla i després un altre cop quan el servidor hagi enviat. La primera ordre mostra els extrems i l'edat del handshake. La segona mostra si hi ha una entrada de traducció per al port. La captura mostra quina direcció ha creuat realment el cable, i la comprovació de ruta confirma que el client no envia aquest trànsit a un altre lloc ben diferent.

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

Registreu la columna de l'extrem i l'entrada de traducció alhora. Un parell sense extrem i una passarel·la sense traducció són dues avaries diferents. Només una d'elles es corregeix amb un keepalive.