WireGuard: dúas medias rutas fronte a 0.0.0.0/0 en wg-quick

Dous prefixos /1 cobren exactamente os mesmos enderezos IPv4 ca un só /0, e esa igualdade só se cumpre dentro da lista de prefixos permitidos do peer. Deixa de cumprirse no momento en que a ferramenta de configuración decide como encamiñar, porque Linux wg-quick trata un prefixo por defecto como un caso especial e non como aritmética. A rama especial instala unha táboa dedicada, dúas regras de política, unha marca de socket e axustes de ruta inversa que un par de medias rutas nunca recibe. Así que cando un proxy ou un navegador deixa de funcionar tras a edición, os prefixos son a parte menos interesante do cambio.

A lista de prefixos non é toda a configuración

AllowedIPs fai dous traballos á vez, e só un deles trata da cobertura. Para o propio WireGuard a lista é encamiñamento por clave criptográfica: decide que destinos se cifran cara a un peer e que enderezos de orixe pode usar ese peer. Para wg-quick a mesma lista tamén actúa como especificación de rutas, e a ruta que produce depende de que rama coincida coa lista. Unha cobertura idéntica con dúas formas de lista distintas non di nada, polo tanto, sobre un estado de host idéntico.

A configuración por defecto quítalle esa decisión das mans, porque Table é automática de forma predeterminada e a ferramenta elixe onde acaban as rutas. Outro xestor de rede, un envoltorio de distribución ou un valor personalizado de Table volve cambiar o resultado, e por iso un consello escrito para un host pode parecer erróneo no seguinte.

Que engade a rama por defecto máis alá dunha ruta

Unha entrada /0 envía wg-quick pola súa ruta por defecto: unha táboa de encamiñamento separada recibe a ruta por defecto, unha regra de política manda alí o tráfico sen marcar, unha segunda regra mantén como autoritativas as rutas máis específicas da táboa principal, e a interface recibe unha marca de cortalumes aplicada ao seu propio socket. Esa marca é o gardián do bucle. Os datagramas cifrados que levan o tráfico do túnel saen coa marca posta, de modo que a regra que dirixe todo o demais ao túnel non traga os paquetes de transporte do propio túnel.

Un par de entradas /1 toma en cambio a ruta ordinaria. Dúas rutas acaban na táboa configurada, e non aparece nada da maquinaria que as rodea, non porque sexa innecesaria senón porque esa ruta de código nunca se executou.

Onde diverxen os dous arranxos

A diverxencia amósase primeiro como recursión. Coas medias rutas na táboa principal, o enderezo de transporte do propio peer cae dentro dun prefixo do túnel, así que o paquete que debería portar o túnel coincide cunha ruta que apunta cara a dentro do túnel. Algo ten que eximilo: unha ruta de host para o extremo actual, unha marca aplicada a man ou unha regra específica da interface. Unha ruta de host funciona ata que cambia o enderezo do extremo, algo que ocorre con extremos baseados en DNS, clientes itinerantes e configuracións con varios peers.

En segundo lugar, todo o que razoa sobre marcas cambia de comportamento. Un proxy transparente que redirixe conexións localmente crea sockets novos cuxas marcas e orixes difiren do fluxo orixinal do cliente, e as regras de política que xera a rama por defecto eran parte do que separou eses fluxos. Ler a conexión saínte do propio proxy é un exercicio distinto de comprobar se o destino orixinal é alcanzable.

Lea as regras e as marcas antes de editar

Capture o estado actual mentres o túnel está san e outra vez despois do cambio, e compare os dous volcados en lugar de razoar a partir do ficheiro de configuración. Inclúa as regras de política, cada táboa, a marca da interface e os extremos rexistrados.

ip rule show
ip -4 route show table all | grep -E 'default|wg1'
wg show wg1 fwmark
wg show wg1 endpoints

Se a primeira liña de saída perdeu a regra do tráfico sen marcar e a táboa dedicada está baleira, a rama por defecto non se executa e ningunha aritmética de prefixos restaurará os seus efectos. Unha marca de cero nunha interface que antes levaba unha é o mesmo sinal, visible nun só valor.

Ensaiade a perda do túnel antes de despregar

Se a disposición de medias rutas é a escolla deliberada, debe achegar explicitamente as pezas que faltan: unha ruta de extremo que sobreviva aos cambios de enderezo, o comportamento previsto cando o túnel cae e o tratamento equivalente para IPv6. Anotádeo como requisitos en lugar de descubrilo durante unha caída. Despois ensaiade o fallo, porque un túnel completo que recae en silencio sobre a ligazón física é peor ca un que deixa de funcionar.

sudo ip -4 route add 198.51.100.20/32 via 192.0.2.1 dev eth0
ip -4 route get 198.51.100.20
sudo wg-quick down wg1

A consulta de ruta debería resolver o extremo pola interface física sen atravesar o túnel, e baixar a interface debería deixar o host no estado que prometeu o deseño. Un proxy que funciona tras a substitución demostra que o estado de host xerado importaba; non demostra que a prevención de bucles e o comportamento en estado baixado sobrevivisen á edición.