Dous peers de WireGuard comparten un rango: cal recibe o paquete

Dous peers enumeran rangos que se tocan, e o tráfico chega ao equivocado. Nada está corrupto: WireGuard escolle un peer facendo coincidir o destino cos rangos configurados, e gaña a coincidencia máis específica. Antes de ampliar calquera cousa, decide que peer debería posuír que prefixo.

O prefixo máis longo gaña dentro de WireGuard

Cada entrada de peer leva un conxunto de prefixos de destino. Cando un paquete se encamiña cara á interface, a implementación busca a entrada co prefixo coincidente máis específico, a mesma regra que aplica unha táboa de encamiñamento. Por iso un /24 vence un /16 que o contén, e o peer máis estreito recibe o tráfico.

As instalacións road-warrior úsano deliberadamente. Un peer posúe un rango amplo para un sitio, e os hosts individuais recórtanse con entradas /32 que pertencen a outros peers. O patrón funciona porque os recortes son máis específicos, non pola orde.

Anota a propiedade como unha táboa de prefixo e peer. Se dúas entradas describen o mesmo prefixo, a configuración xa non expresa unha intención, expresa unha carreira.

O sistema operativo escolle primeiro a interface

WireGuard só escolle entre os peers dunha interface. Que interface recibe o paquete decídese antes, pola táboa de encamiñamento do host, e unha segunda ruta predeterminada ou unha ruta obsoleta pode enviar o tráfico a un lugar onde a lista de peers nunca o ve. Por iso un diagnóstico a nivel de peer pode ser correcto e aínda así non explicar o fallo. Comproba a ruta cara ao destino antes de ler a configuración do peer, porque unha ruta que apunta á interface física pasa por alto toda a cuestión.

A ferramenta adoita instalar esas rutas a partir dos rangos dos peers, o que significa que un cambio na lista dun peer pode redirixir en silencio tráfico que antes pertencía a outro. Editar un peer é, por tanto, un cambio de encamiñamento disfrazado. Revisa ambos á vez, ou arranxarás un e romperás o outro.

Os paquetes entrantes compróbanse por orixe

A lista de rangos cumpre unha dobre función. Para o tráfico saínte escolle un peer por destino, e para o tráfico entrante autoriza un enderezo de orixe. Un paquete que chega dun enderezo fóra dos rangos dese peer descártase antes de que o vexa calquera firewall.

Esa asimetría é fácil de pasar por alto cando se le un lado da configuración. Un peer que pode alcanzar unha subrede non queda por iso autorizado a enviar desde esa subrede, e as dúas direccións aplícanse con comprobacións distintas.

A propiedade estreita da orixe converte isto nunha vantaxe. Dá a cada peer un /32 para o seu propio enderezo e o firewall posterior terá unha orixe fiable coa que coincidir, en lugar dun rango de todo o grupo que calquera membro podería reclamar.

Os rangos duplicados non son failover

Asignar o mesmo prefixo a dous peers non crea un balanceador de carga nin unha ruta de reserva. Non hai comprobación de estado nin afinidade de sesión: a entrada gañadora decídea a orde interna da implementación, que non é un contrato sobre o que debas deseñar. Se necesitas saídas alternativas, exprésaas onde se define a selección. Unha política de encamiñamento, unha métrica ou un par de prefixos distintos cun propietario documentado cada un producen un comportamento que podes prever e probar.

Ampliar un rango para arranxar un fallo non relacionado é o outro erro habitual. Afasta o tráfico do peer que funcionaba, e o novo síntoma chega antes de que se entenda o antigo.

Verifica a selección antes de editar

Tres comandos responden as tres preguntas en orde. O primeiro enumera os rangos que reclama cada peer. O segundo mostra que interface usaría o host para un destino. O terceiro mostra o estado vivo dos peers despois de que fluíse o tráfico.

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

Execútaos antes e despois dun cambio e compara. Se a saída da ruta cambiou pero o tráfico segue chegando ao peer equivocado, as listas de prefixos se superpoñen dun xeito que aínda non documentaches. Se a saída da ruta non cambiou, a configuración do peer nunca foi o que se consultaba.

Rexistra o destino, a interface escollida e o peer escollido no ticket. Ese trío é o que fai revisable máis tarde unha superposición, e é moito máis útil ca unha captura de pantalla da configuración.