La VPN diu que està connectada, però la ruta per defecte és morta
Passar de Wi-Fi a Ethernet pot deixar la ruta i el resolutor al túnel antic. Llegeix els dos estats per separat i repara el que està malament.
El client diu que està connectat, la icona de la safata sembla normal i no carrega res. Va començar just després de passar de Wi-Fi a cable, o just després d’acabar una actualització de la distribució. El que s’ha trencat no és el perfil, sinó l’estat que es va construir per a la connexió base anterior. El nucli encara té una ruta per defecte que apunta a un dispositiu de túnel que ningú posseeix, o el resolutor encara llista servidors en un enllaç que ha desaparegut. Totes dues fallades semblen una xarxa morta i totes dues es poden reparar al lloc.
Les peces obsoletes ja estaven malament abans que te n’adonessis. Desendollar un cable només les va fer visibles.
Pregunta al nucli on anirà un paquet
Els llistats de rutes són difícils de llegir perquè enumeren tot el que el sistema sap, incloent-hi entrades que ja no s’apliquen. Una consulta de ruta respon l’única pregunta que val la pena: quin dispositiu porta aquest paquet concret ara mateix. Si la resposta anomena un dispositiu de túnel, el nucli l’utilitzarà encara que darrere no hi hagi cap procés de client viu, i el paquet cau en una interfície que ningú manté. Si la resposta anomena l’adaptador Ethernet mentre el client insisteix que està actiu, el túnel existeix però ha perdut la selecció, que és el resultat habitual de passar de sense fils a cable.
Executa la consulta dues vegades, una per a una adreça pública i una per a una d’interna, perquè una política de túnel dividit pot encaminar una amb honestedat i deixar caure l’altra.
ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40
El resolutor també conserva l’enllaç mort
En un amfitrió amb systemd-resolved, els servidors DNS pertanyen als enllaços i no a una llista global. Un enllaç VPN que ha caigut pot quedar registrat amb els seus servidors durant un temps, i llavors cada consulta espera una adreça que no respondrà mai. Aquest retard sembla una xarxa morta i fa que la gent miri les rutes quan la ruta és correcta.
resolvectl status
resolvectl query intranet.example.com
Llegeix els blocs per enllaç i identifica quin enllaç posseeix el domini en qüestió. Un túnel que està aixecat però no és el propietari del domini intern reenvia els noms interns al resolutor públic, i el símptoma és indistingible d’una fallada d’encaminament.
Repara el registre en lloc de /etc/resolv.conf. A les instal·lacions actuals d’Ubuntu i Fedora aquest camí és un enllaç simbòlic a l’estat d’execució del resolutor, així que una edició o s’ignora o se sobreescriu al següent esdeveniment de xarxa.
Una VPN no s’inicia mai sola
NetworkManager aixeca una VPN sobre una connexió base i aprèn quina ha de seguir a partir de connection.secondaries en aquesta base. La referència de paràmetres de connexió diu explícitament que la connexió automàtica no està implementada per als perfils VPN. Aquest és tot el mecanisme darrere d’aquesta classe de fallada: canvia la base i la VPN s’ha de tornar a aparellar o reactivar a mà.
nmcli device status
nmcli connection show --active
nmcli connection up office-vpn
Quan la llista activa mostra la base sense la VPN, el túnel no està actiu en absolut i la ruta no es va instal·lar mai, en lloc d’haver quedat obsoleta. Quan l’activació es queixa que no existeix cap connexió d’origen, la base amb què estava aparellada ha desaparegut, així que arregla primer la base o l’aparellament i deixa de reintentar la VPN.
Una actualització pot deixar caure paràmetres sense cap missatge
Actualitzar una distribució substitueix el client i sovint el seu connector de NetworkManager, mentre el perfil desat conserva els noms de propietat amb què es va escriure. Tot el que el connector nou ja no reconeix es descarta en silenci. El perfil encara s’activa i el dispositiu encara apareix, però la ruta que abans hi arribava ja no hi arriba mai.
Els ganxos escrits a mà també es mouen. Un script que instal·lava una ruta en un moment previsible de la seqüència antiga pot ara executar-se abans que existeixi la interfície, o després que el client ja hagi esgotat el temps.
Compara el perfil viu amb el connector que realment tens, no amb el comportament que recordes. Si una clau ha desaparegut de la documentació, mou la feina a un script despatxador o a un reemplaçament admès en lloc de restaurar la propietat antiga.
Tres estats, tres reparacions diferents
Decideix en quin estat ets abans de tocar res, perquè un reinici destrueix les proves i la fallada torna al següent canvi de xarxa.
| What the lookup shows | What it means | Repair |
|---|---|---|
| A default route via a device that exists but is unused | Leftover route from an earlier activation | Remove the stale entry, or bounce the profile that installed it |
| A tunnel device with no client process | The client skipped its cleanup | Fix the disconnect path, then clear the leftover device state |
| No tunnel device and no active profile | Missing base connection or broken pairing | Bring up the base, then pair the VPN with it again |
Acaba amb una consulta per a una adreça pública, una per a una adreça interna i una consulta de nom. Si les adreces funcionen i el nom no, la fallada restant és l’abast de domini al resolutor, i la taula de rutes mai no va ser el problema.