WireGuard AllowedIPs: a ruta que NetworkManager nunca engadiu

O contador de handshake actualízase, a interface conserva o seu enderezo e un ping cara ao outro lado non chega a ningures. Esa combinación desconcerta porque un handshake que funciona parece a proba de que o túnel está listo. Non o é: un túnel pode estar completamente negociado e aínda así non ter ningunha ruta que dirixa o tráfico cara a el, e son dúas tarefas separadas que realizan dúas pezas de estado separadas. A solución depende por completo de cal das dúas falta, así que o primeiro paso é descubrilo.

wg-quick fai ambas as cousas sen que ninguén llo pida. O soporte de WireGuard integrado en NetworkManager tamén instala rutas de peers de forma predeterminada, o que reduce os sospeitosos a unha opción desactivada, outra táboa de enrutamento ou unha configuración importada por outra vía.

Confirme o túnel antes de perseguir a ruta

wg show mostra a interface, o peer, o extremo e a antigüidade do último handshake, e ip addr show confirma que o enderezo está presente. Un handshake recente significa que as claves, o extremo e a ruta UDP funcionan. Todo o que está roto queda augas abaixo: enrutamento, filtrado ou resolución de nomes.

Despois pregunte ao núcleo que faría cun destino real en lugar dun hipotético: ip route get 10.42.7.9. A resposta nomea a interface de saída e o enderezo de orixe que levaría o paquete. Cando nomea o adaptador físico, o paquete nunca entra no túnel por moi san que pareza o handshake.

AllowedIPs é un filtro e unha lista de rutas

Os prefixos de AllowedIPs fan dous traballos. Seleccionan que peer transporta un destino de saída e validan o enderezo de orixe dos paquetes entrantes, que é o límite do enrutamento por clave criptográfica. En wg-quick ademais impulsan a instalación automática de rutas, e ese comportamento extra é a razón pola que a mesma configuración funciona desde un terminal e non desde un cliente de escritorio.

No caso que hai detrás deste artigo, o perfil importouse mediante un complemento de terceiros e non co soporte integrado, e a interface subiu sen a ruta do prefixo. Listar a táboa móstrao de inmediato: ip route show só contén a ruta conectada do enderezo da interface e nada para o rango remoto.

Pregunte se as rutas de peers están activadas

Lea o axuste antes de modificar nada: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. Cando peer-routes mostra no, a reparación admitida é nmcli connection modify work-wg wireguard.peer-routes yes, seguida dunha reconexión. Engadir no seu lugar unha ruta estática funciona ata a seguinte activación e logo desaparece en silencio. Esa desaparición é a pista: unha ruta que volve como un misterio cada mañá non a instala o perfil.

Se a opción xa está activada, comprobe se o prefixo vive noutra táboa con ip route show table all | grep 10. Unha ruta nunha táboa que non é a principal non falta, simplemente é invisible para unha consulta que só mira a táboa principal. Arranxe o enrutamento por políticas en lugar de apilar unha entrada duplicada enriba.

Engada o prefixo á conexión, non ao sistema en marcha

No editor de conexións, a páxina de WireGuard contén o peer e os seus AllowedIPs, e a páxina de IPv4 contén rutas adicionais. Unha ruta engadida alí sobrevive ás reconexións porque pertence ao perfil. Na liña de comandos o equivalente é engadir unha ruta á conexión coa forma de porta de enlace baleira e despois baixar e subir a conexión para que o cambio se aplique.

Escolla o prefixo máis estreito que cubra os equipos que precisa. Copiar o exemplo /8 do provedor pode tragar rangos locais que estean dentro por casualidade, e os fallos resultantes parecen un túnel roto máis que unha ruta demasiado ampla.

O túnel dividido decídeo a lista de prefixos

Non hai ningún interruptor de túnel dividido; a lista de prefixos é a decisión. Un peer cun rango para a LAN da oficina e outro para unha rede de laboratorio envía exactamente eses destinos polo túnel e deixa todo o demais en paz. Un só equipo necesita un /32, e os rangos que se solapan en dous sitios necesitan prefixos de equipo ata que alguén renumere unha subrede.

Escoller non enviar nada polo túnel leva a mesma decisión ao seu límite: unha lista mínima mantén a ligazón arriba mentres o tráfico corrente segue o seu camiño habitual. Escriba a intención, porque se non o seguinte lector tomará a lista curta por un descoido e ampliaraa con boa vontade.

Un só dono para a táboa de rutas

wg-quick e NetworkManager cren ambos que son donos das rutas da interface. Importe unha configuración escrita para wg-quick e despois arrinque tamén o servizo wg-quick, e obterá entradas duplicadas ou en conflito cuxo comportamento depende de cal se executou ao final. Escolla un único dono e elimine o outro: se NetworkManager xestiona a conexión, desactive a unidade wg-quick para esa interface e non engada nunca un segundo perfil para o mesmo dispositivo.

Cando a división debe seguir un adaptador físico en lugar dun destino, pasou ao enrutamento por políticas, e o enrutamento por políticas tamén necesita un só autor. Verifique repetindo ip route get e logo chegando a un equipo dentro do prefixo remoto con algo que imprima o enderezo de orixe que escolleu. Comprobe IPv6 e DNS por separado se o perfil leva algún dos dous.