El parell de WireGuard surt per la WAN equivocada: cinc comprovacions en ordre

Dos enllaços ascendents, una passarel·la i un parell de WireGuard el trànsit del qual no deixa de sortir per la línia de reserva. L’aplec de mans es manté sa tot el temps. Per això és fàcil llegir el símptoma com una fallada de WireGuard en lloc d’una fallada d’encaminament.

Feu les comprovacions següents en ordre. Cada una té una condició d’aturada, i saltar-se-la sol produir una resposta equivocada i segura.

Separeu l’aplec de mans del flux reenviat

L’intercanvi xifrat amb el parell té una ruta fins a l’adreça pública del servidor. El trànsit reenviat del client té una destinació diferent i pot ser seleccionat per marques o regles de política. Són dues decisions d’encaminament que comparteixen una interfície. Tractar-ne una com a prova de l’altra és el primer error.

Atureu-vos tan bon punt us enxampeu raonant a partir de l’aplec de mans. Només és prova del camí fins al punt final.

Llegiu la regla de política, no la taula per defecte

Una taula per defecte mostra què passa quan no coincideix cap regla de política. En una passarel·la que encamina per origen, marca o destinació, la regla decisiva viu en un altre lloc. La taula simple pot semblar del tot raonable mentre la tria real es fa per sobre.

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

Llegiu les regles de política i les taules a què apunten. Després confirmeu quina regla coincideix amb el vostre flux de prova. Una regla que fa referència a una interfície que ja no porta l’enllaç ascendent previst és una troballa, no un detall. La consulta de ruta del final mostra la resposta molt més de pressa que llegir una taula i endevinar.

Comproveu la marca i la traducció alhora

L’encaminament per política es basa en una marca de paquet establerta abans a la cadena. Si la regla de marcatge deixa passar el vostre trànsit, el flux cau a la taula principal i surt pel que hi hagi per defecte. Els paquets reenviats sovint salten cadenes escrites per al trànsit generat localment.

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

La traducció ha de concordar amb l’enllaç ascendent que porta el flux. Una regla que tradueix a l’adreça primària mentre el paquet surt per la línia de reserva produeix respostes adreçades a una interfície que el flux mai no va fer servir. Comproveu la condició d’interfície de la mateixa regla de traducció. Una regla incondicional funciona fins que s’usa el segon enllaç ascendent, i llavors falla d’una manera que sembla intermitent.

Vigileu quina interfície porta la resposta

Captureu en tots dos enllaços ascendents mentre s’executa una sol·licitud. Anoteu quina interfície porta la sol·licitud i quina la resposta. Els camins asimètrics són molt més fàcils de veure que de predir.

Si la resposta arriba per l’enllaç ascendent equivocat, el problema s’ha traslladat de WireGuard al seguiment de connexions o a la traducció. Cap canvi a la configuració del parell ho arreglarà.

Canvieu una cosa amb un camí de tornada

Mantingueu accés per consola o fora de banda abans d’editar regles de política en una passarel·la. Feu un sol canvi, proveu la mateixa destinació autoritzada, torneu a connectar i confirmeu que l’aplec de mans encara fa servir el camí previst fins al punt final. Afegiu una prova numèrica a la segona família d’adreces, perquè una política només per a v4 deixa el mateix error disponible.

Anoteu quin enllaç ascendent va fer servir cada flux. Aquest registre converteix l’informe següent en una comprovació de dos minuts en lloc d’una tarda sencera. les notes de WireGuard sobre espais de noms i encaminament descriuen com separar deliberadament el camí fins al punt final del trànsit tunelitzat, cosa que normalment és més neta que copiar una solució alternativa amb ruta per defecte.