WireGuard: sen ruta ata o par tras un cambio de subrede — dúas saídas

O aperto de mans está fresco en wg show, o extremo é correcto, as claves nunca cambiaron — e ping segue dicindo que non hai ruta ata o par. Cambiou a subrede do túnel hai unha hora. Ese síntoma é a sinatura dun desaxuste de prefixo e non dun problema de claves: WireGuard completou o aperto de mans e logo descartou os datos porque un enderezo de orixe xa non coincide co que aceptará o par receptor. Hai dúas formas sensatas de aplicar un cambio de subrede, e fallan en sitios distintos.

Dúas formas de aplicar o cambio, e que custa cada unha

A opción A é renumerar no sitio: editar o enderezo da interface, os rangos dos pares, as rutas e cada copia da configuración, e despois recargar. A opción B é construír unha segunda interface co prefixo novo xunto á antiga, mover os pares e retirar a interface antiga cando o tráfico se movese de verdade.

O estado medio aplicado é o que fai perigosa a opción A, porque non parece roto. A interface sobe, o aperto de mans ten éxito e só falla a ruta de datos. A opción B custa máis traballo pero mantén viva unha ruta que funciona mentres atopa cada referencia.

Que ten que moverse á vez na súa banda

Catro cousas do host local describen a mesma subrede, e cambiar unha é cambiar todas: o enderezo da interface, o AllowedIPs de cada par, a ruta que o sistema usa para eses destinos e o que o xestor instale no seu nome. Con wg-quick, as dúas últimas xéranse a partir da configuración cada vez que sobe a interface, así que unha copia obsoleta reinstala o prefixo antigo en silencio.

Compare o configurado co que está vivo en lugar de confiar en ningún dos dous:

wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5

A consulta de ruta é o paso que a xente se salta. Responde que faría realmente o núcleo para un destino, incluída unha ruta máis específica que deixase un xestor ou un contorno de execución de contedores. Se informa dunha interface distinta á do túnel, a configuración non é o problema.

Para unha interface en execución, aplique o ficheiro editado sen desmontar o túnel:

wg syncconf wg0 <(wg-quick strip wg0)

Iso actualiza pares e rangos no sitio. Non actualiza o enderezo da interface nin as rutas, porque non son axustes de WireGuard — así que unha renumeración aínda necesita recrear a interface ou cambiar o enderezo con ip, e despois volver comprobar o encamiñamento.

Que ten que moverse á vez no extremo afastado

Aquí é onde adoita morrer un cambio de subrede. AllowedIPs non é só unha pista de encamiñamento; tamén é a lista de enderezos de orixe que un par pode presentar. Cando renumera clientes e deixa o AllowedIPs do servidor no prefixo antigo, o servidor acepta o aperto de mans, recibe os paquetes cifrados e descártaos porque a orixe interna non coincide con ningún rango que asocie a ese par. Non se rexistra ningún erro e o cliente ve un tempo de espera.

Así que actualice o lado receptor con intención: a entrada do par no servidor debe listar o prefixo novo do cliente, a ruta de volta do propio servidor debe apuntar ao túnel para ese prefixo, e calquera rede posterior ao servidor debe aprender o camiño novo. A política de devasas que nomeaba o rango antigo necesita o mesmo trato, e tamén calquera cousa que faga selección por orixe.

O diagnóstico que separa os dous fallos é barato. Un aperto de mans recente sen datos significa que o túnel está levantado e que o direccionamento interno non concorda. Ningún aperto de mans significa que está mirando accesibilidade ou claves. Non rote as claves por un problema de prefixo; reinicia o único que funcionaba.

Copias obsoletas que sobreviven á súa edición

Editar un ficheiro non é o mesmo que cambiar o sistema en marcha, e as copias son máis numerosas do que a xente espera: a unidade ou o xestor que posúe a interface, un segundo perfil co mesmo nome noutro directorio, un contedor coa súa configuración incrustada nunha imaxe, unha interface de router coa súa propia versión editada e unha aplicación cliente que reimporta un túnel gardado ao arrincar. Cada unha pode restaurar o prefixo antigo despois de que o seu cambio pareza completo.

Os nomes tamén viaxan. Se a ruta numérica funciona pero o nome de host falla, un rexistro DNS interno ou a configuración dun servizo segue apuntando ao enderezo antigo do túnel. Corrixa a referencia en lugar de ampliar cada rango de par, o que taparía o problema real e ampliaría á vez a ACL de orixe.

Manteña aberta unha vía de recuperación mentres traballa: unha segunda forma de entrar no host, unha consola serie ou unha reversión programada dos ficheiros de configuración. Un cambio de túnel que o deixa fóra da máquina que está a cambiar é a forma máis común de que esta tarefa se converta nunha noite.

Elixir entre as dúas, e verificar o corte

Elixa A cando posúa todos os pares, o número sexa pequeno e unha interrupción breve sexa aceptable. Elixa B cando os pares sexan mans remotas que non controla, cando unha ligazón entre sedes deba seguir en pé ou cando non poida garantir que cada copia se actualice nunha soa pasada. Nese caso engada o prefixo novo a ambas interfaces, mova os pares de un en un, observe o tráfico na nova e só entón retire a interface antiga e as súas rutas.

Con calquera das dúas opcións, o cambio está feito cando pasan catro comprobacións: o aperto de mans é recente, a consulta de ruta para un destino do prefixo novo nomea o túnel, unha carga dalgúns centos de bytes transfírese en ambos sentidos, e o mesmo se cumpre tras reiniciar o host ou o xestor. O manual de wg(8) é a referencia do que significa AllowedIPs en cada sentido, e paga a pena relerlo antes de ampliar un rango para que desapareza un síntoma.

• Aperto de mans recente e sen datos: mire o AllowedIPs no receptor antes de tocar as claves.
• A consulta de ruta apunta á interface equivocada: a ruta posúea un xestor ou un contedor, non o seu ficheiro.
• Enderezo numérico ben e nome de host roto: unha referencia antiga, non un bucle de encamiñamento.
• O cambio só está completo cando, tras un reinicio, se segue usando o prefixo novo.