A VPN di que está conectada, pero a ruta predeterminada está morta

O cliente informa de que está conectado, a icona da bandexa parece normal e non carga nada. Comezou xusto despois de pasar de Wi-Fi a cable, ou xusto despois de que rematase unha actualización da distribución. O que se rompeu non é o perfil, senón o estado que se construíu para a conexión base anterior. O núcleo aínda ten unha ruta predeterminada que apunta a un dispositivo de túnel que ninguén posúe, ou o resolvedor segue listando servidores nunha ligazón que desapareceu. Ambos os fallos parecen unha rede morta e ambos se poden reparar no sitio.

As pezas obsoletas xa estaban mal antes de que te decataras. Desconectar un cable só as fixo visibles.

Pregúntalle ao núcleo a onde iría un paquete

As listas de rutas son difíciles de ler porque enumeran todo o que o sistema sabe, incluídas as entradas que xa non se aplican. Unha consulta de ruta responde á única pregunta que paga a pena: que dispositivo leva este paquete concreto agora mesmo. Se a resposta nomea un dispositivo de túnel, o núcleo usarão aínda que detrás non haxa ningún proceso de cliente vivo, e o paquete cae nunha interface que ninguén mantén. Se a resposta nomea o adaptador Ethernet mentres o cliente insiste en que está activo, o túnel existe pero perdeu a selección, que é o resultado habitual de pasar de sen fíos a cable.

Executa a consulta dúas veces, unha para un enderezo público e outra para un interno, porque unha política de túnel dividido pode encamiñar un con honestidade e deixar caer o outro.

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

O resolvedor tamén conserva a ligazón morta

Nun equipo con systemd-resolved, os servidores DNS pertencen ás ligazóns e non a unha lista global. Unha ligazón VPN que caeu pode seguir rexistrada cos seus servidores durante un tempo, e entón cada consulta espera un enderezo que nunca responderá. Esa demora séntese como unha rede morta e fai que a xente mire as rutas cando a ruta está ben.

resolvectl status
resolvectl query intranet.example.com

Le os bloques por ligazón e identifica que ligazón posúe o dominio en cuestión. Un túnel que está levantado pero non é o propietario do dominio interno reenvía os nomes internos ao resolvedor público, e o síntoma é indistinguible dunha falla de encamiñamento.

Repara o rexistro en lugar de /etc/resolv.conf. Nas instalacións actuais de Ubuntu e Fedora esa ruta é unha ligazón simbólica ao estado de execución do resolvedor, así que unha edición ou se ignora ou se sobrescribe no seguinte evento de rede.

Unha VPN nunca arranca soa

NetworkManager levanta unha VPN sobre unha conexión base, e aprende cal debe seguir a partir de connection.secondaries nesa base. A referencia de axustes de conexión di explicitamente que a conexión automática non está implementada para os perfís VPN. Ese é todo o mecanismo detrás desta clase de fallo: cambia a base e a VPN ten que emparellarse de novo ou reactivarse a man.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

Cando a lista activa mostra a base sen a VPN, o túnel non está activo en absoluto e a ruta nunca se instalou, en lugar de quedar obsoleta. Cando a activación se queixa de que non existe ningunha conexión de orixe, a base coa que estaba emparellada desapareceu, así que arranxa primeiro a base ou o emparellamento e deixa de reintentar a VPN.

Unha actualización pode deixar caer axustes sen ningunha mensaxe

Actualizar unha distribución substitúe o cliente e a miúdo o seu complemento de NetworkManager, mentres o perfil gardado conserva os nomes de propiedade cos que se escribiu. Todo o que o complemento novo xa non recoñece omítese en silencio. O perfil aínda se activa e o dispositivo aínda aparece, pero a ruta que antes chegaba con el xa non chega.

Os ganchos escritos a man tamén se moven. Un script que instalaba unha ruta nun momento previsible da secuencia antiga pode agora executarse antes de que exista a interface, ou despois de que o cliente xa esgotase o tempo.

Compara o perfil vivo co complemento que realmente tes, non co comportamento que recordas. Se unha clave desapareceu da documentación, move o traballo a un script despachador ou a unha substitución admitida en lugar de restaurar a propiedade antiga.

Tres estados, tres reparacións distintas

Decide en que estado estás antes de tocar nada, porque un reinicio destrúe as probas e o fallo volve no seguinte cambio de rede.

Remata cunha consulta para un enderezo público, unha para un enderezo interno e unha consulta de nome. Se os enderezos funcionan e o nome non, o fallo restante é o ámbito de dominio no resolvedor, e a táboa de rutas nunca foi o problema.