O par de WireGuard sae pola WAN incorrecta: cinco comprobacións en orde

Dous enlaces ascendentes, unha pasarela e un par de WireGuard cuxo tráfico non deixa de aparecer na liña de reserva. O handshake mantense san todo o tempo. Por iso é doado ler o síntoma mal como unha falla de WireGuard en lugar dunha falla de encamiñamento.

Realice as comprobacións seguintes en orde. Cada unha ten unha condición de parada, e adiantarse adoita producir unha resposta incorrecta e segura.

Separe o handshake do fluxo reenviado

O intercambio cifrado co par ten unha ruta de punto final cara ao enderezo público do servidor. O tráfico reenviado do cliente ten outro destino e pode seleccionarse mediante marcas ou regras de política. Son dúas decisións de encamiñamento que comparten unha interface. Tratar unha como proba da outra é o primeiro erro.

Détase en canto se sorprenda razoando a partir do handshake. Só é proba sobre a ruta ao punto final.

Lea a regra de política, non a táboa predeterminada

Unha táboa predeterminada mostra que ocorre cando ningunha regra de política coincide. Nunha pasarela que encamiña por orixe, marca ou destino, a regra decisiva vive noutro lugar. A táboa simple pode parecer totalmente razoable mentres a elección real se toma por riba dela.

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

Lea as regras de política e as táboas ás que apuntan. Despois confirme que regra coincide co seu fluxo de proba. Unha regra que fai referencia a unha interface que xa non transporta o enlace ascendente previsto é un achado, non un detalle. A consulta de ruta do final mostra a resposta moito máis rápido que ler unha táboa e adiviñar.

Comprobe a marca e a tradución xuntas

O encamiñamento por política baséase nunha marca de paquete establecida antes na cadea. Se a regra de marcado non acada o seu tráfico, o fluxo cae na táboa principal e sae polo valor predeterminado que haxa alí. Os paquetes reenviados adoitan saltar cadeas escritas para tráfico xerado localmente.

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

A tradución debe concordar co enlace ascendente que transporta o fluxo. Unha regra que traduce ao enderezo primario mentres o paquete sae pola liña de reserva produce respostas dirixidas a unha interface que o fluxo nunca usou. Comprobe a condición de interface da propia regra de tradución. Unha regra incondicional funciona ata que se usa o segundo enlace ascendente, e entón falla dun xeito que parece intermitente.

Ollade que interface transporta a resposta

Capture en ambos os enlaces ascendentes mentres se executa unha solicitude. Anote que interface transporta a solicitude e cal a resposta. As rutas asimétricas son moito máis fáciles de ver que de predicir.

Se a resposta chega polo enlace ascendente incorrecto, o problema mudou de WireGuard ao seguimento de conexións ou á tradución. Ningún cambio na configuración do par o arranxará.

Cambie unha soa cousa cun camiño de volta

Manteña acceso por consola ou fóra de banda antes de editar regras de política nunha pasarela. Faga un só cambio, probe o mesmo destino autorizado, logo volva conectar e confirme que o handshake segue usando a ruta prevista ao punto final. Engada unha proba numérica na segunda familia de enderezos, porque unha política só para v4 deixa o mesmo erro dispoñible.

Anote que enlace ascendente usou cada fluxo. Ese rexistro converte o seguinte informe nunha comprobación de dous minutos en lugar dunha tarde enteira. as notas de WireGuard sobre espazos de nomes e encamiñamento describen como separar deliberadamente a ruta ao punto final do tráfico tunelizado, o que adoita ser máis limpo que copiar unha volta coa ruta predeterminada.