Un peer de WireGuard no és accessible mentre un altre funciona: llista de comprovació

Un peer de WireGuard passa trànsit i un segon fa l’aplec de mans però no arriba mai a res que hi hagi darrere del túnel. El peer que funciona us diu que la interfície, el port UDP i la clau del servidor probablement estan bé. No us diu res sobre les AllowedIPs del segon peer, la seva adreça d’origen interna ni les regles de reenviament entremig. Seguiu la llista en ordre i atureu-vos al primer pas la condició del qual falli.

Pas 1: Anoteu el camí que hauria de seguir el paquet

Dos clients al mateix concentrador no s’arriben automàticament l’un a l’altre. En un disseny de concentrador i radis, el servidor rep el paquet per wg0 i l’ha de reenviar de nou per wg0 cap a l’altre peer, cosa que requereix reenviament IP i una regla de reenviament. En un disseny directe peer a peer, cada costat necessita l’extrem de l’altre i l’adreça del seu túnel dins de les AllowedIPs. Decidiu quin disseny esteu depurant abans de llegir cap configuració.

El camí esperat també us diu on mirar. Si el paquet ha de travessar el concentrador, el salt que falla és o bé les AllowedIPs de l’emissor, o bé el reenviament del concentrador, o bé les AllowedIPs del receptor. Si ha d’anar directe, el concentrador és irrellevant i els camps d’extrem dels dos peers són els que importen.

Pas 2: Compareu les AllowedIPs als dos costats, no només a un

WireGuard fa servir les AllowedIPs alhora com a taula d’encaminament i com a llista d’accés. En enviar, l’adreça de destinació es busca a les AllowedIPs del peer per triar el túnel; en rebre, l’adreça d’origen interna ha de caure dins de les AllowedIPs del peer emissor o el paquet es descarta. Un rang que falta a qualsevol dels dos costats produeix el mateix símptoma: el transport funciona, la càrrega desapareix.

Llegiu l’estat viu en lloc del fitxer, perquè una recàrrega pot haver fallat en silenci: sudo wg show wg0 allowed-ips. Al servidor, l’entrada del peer que falla ha d’incloure la seva adreça de túnel, per exemple 10.90.0.3/32. Al client, l’entrada del peer servidor ha d’incloure la destinació que proveu, tant si és l’adreça de túnel del concentrador com si és la subxarxa remota. Els rangs que se superposen fan ambigua la consulta i poden triar un peer que no volíeu, així que manteniu-los disjunts.

Pas 3: Comproveu l’adreça d’origen interna

Un client que encamina 10.90.0.3 per wg0 però envia els paquets des de la seva adreça Wi-Fi serà rebutjat pel receptor, perquè l’origen no coincideix amb les AllowedIPs del peer. Confirmeu què tria realment el nucli amb ip route get 10.90.0.3 from 10.90.0.2 i confirmeu l’adreça assignada a la interfície del túnel amb ip -brief addr show wg0.

A l’amfitrió Linux receptor, el filtratge de camí invers és una segona porta. Un rp_filter estricte a la interfície que posseeix la ruta de tornada pot descartar trànsit de túnel el camí de retorn del qual no coincideix amb la interfície per la qual ha arribat. Comproveu el valor efectiu abans de desactivar-lo; en moltes topologies la correcció correcta és una ruta, no un filtre relaxat.

Pas 4: Reviseu el reenviament del concentrador i el camí de tornada

Si el concentrador ha de reenviar entre peers, el nucli necessita net.ipv4.ip_forward=1, i el tallafoc ha d’acceptar el flux reenviat: entrada per wg0, sortida per wg0, des de l’adreça de túnel de l’emissor fins a la del receptor. Una fallada habitual és una regla d’entrada que accepta UDP 51820 però cap regla de reenviament], de manera que l’aplec de mans té èxit i la càrrega mor. Llisteu les regles efectives amb sudo nft list ruleset o l’equivalent per al vostre gestor de tallafoc.

Després comproveu la resposta. L’amfitrió de destinació ha de tenir una ruta de tornada cap a l’emissor, ja sigui pel concentrador o pel seu propi passarel·la. Si el concentrador també fa NAT a la subxarxa del túnel, confirmeu que la traducció s’aplica al flux reenviat i que la resposta arriba al concentrador abans que l’estat caduqui. Una fallada unidireccional que sembla un problema de clau sovint és només aquesta ruta de tornada.

Finalment, separeu l’aplec de mans de les dades. Un peer que completa l’aplec de mans però s’encalla en transferències grans sol tenir un problema d’MTU o MSS en aquest camí concret, no un problema d’AllowedIPs. Proveu primer amb un ping petit, després amb un de mida completa, i compareu els dos peers.

Pas 5: Canvieu una cosa i manteniu intacte el peer que funciona

Feu un sol canvi al camí que falla i torneu a provar els dos peers. Substituir les AllowedIPs de cada peer per 0.0.0.0/0 és la manera més ràpida de trencar el peer que ja funcionava, perquè canvia la decisió d’encaminament de tot el trànsit d’aquella interfície. Editeu l’entrada d’aquell peer, recarregueu i torneu a llegir l’estat viu.

Anoteu quin camí ha funcionat, quin ha fallat i la sortida exacta de la comanda per a cadascun. Aquesta comparació val més que un informe general que la VPN està trencada, i és el primer que demanarà la persona següent.