Perché un server domestico perde una route statica dopo un aggiornamento di NetworkManager?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Why Does a Home Server Lose One Static Route After a NetworkManager Upgrade?

Una route statica può scomparire dopo un aggiornamento di NetworkManager quando apparteneva a un profilo o a un percorso di configurazione che non è più la connessione attiva.

Su uno ZimaSpace o su un home server Linux, una route verso una VLAN IoT, una sottorete di backup o un router secondario potrebbe essere stata aggiunta manualmente con ip route, salvata in un vecchio profilo di connessione oppure associata a un profilo che NetworkManager sostituisce dopo l’aggiornamento. Il test corretto confronta la route attiva con il profilo persistente in uso, invece di aggiungere nuovamente il comando dopo ogni riavvio.

Verifica se la route era davvero persistente

Confronta una route aggiunta con ip route con il profilo di connessione di NetworkManager che dovrebbe ricrearla.

Una guida pratica e mirata su networkmanager relativa alle route statiche persistenti nel profilo di connessione aiuta a isolare questo caso, perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.

Se la route esiste solo nella tabella del kernel, spostala nel profilo gestito prima di attribuire la colpa all’aggiornamento.

Esamina le modifiche ai profili causate dall’aggiornamento

Confronta i nomi dei profili, gli UUID, lo stato di connessione automatica e le voci delle route prima e dopo l’aggiornamento del pacchetto.

Un articolo mirato su un caso di troubleshooting relativo alle route statiche che possono scomparire quando cambia lo stato di NetworkManager aiuta a isolare questo caso, perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.

Ripristina la route nel profilo persistente attivo e conserva una copia del profilo precedente per il confronto.

Ricorda che NetworkManager è incentrato sui profili

Un’interfaccia può avere diversi profili salvati, ma solo quello attivato contribuisce alle impostazioni delle route.

Un blog tecnico mirato su networkmanager relativo al fatto che la configurazione di NetworkManager ruota attorno ai profili di connessione aiuta a isolare questo caso, perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.

Individua il profilo attivo tramite UUID invece di modificare il file il cui nome ti è più familiare.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Controlla insieme la tabella delle route e le regole di policy

Una route potrebbe esistere ancora in una tabella diversa da quella principale, mentre la regola che selezionava tale tabella è cambiata.

Una spiegazione mirata sul routing Linux relativa al fatto che il policy routing utilizza sia le tabelle sia le regole aiuta a isolare questo caso, perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.

Elenca ip rule e tutte le tabelle pertinenti prima di aggiungere una route duplicata alla tabella principale.

Controlla se le metriche delle route hanno cambiato il percorso selezionato

Quando due route coprono la stessa destinazione, la metrica effettiva più bassa o la route più specifica può sostituire il percorso che ti aspettavi di vedere.

Un tutorial mirato sul networking Linux relativo al fatto che le metriche delle route determinano quale percorso prevale aiuta a isolare questo caso, perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.

Confronta il prefisso di destinazione, la metrica e l’interfaccia dopo l’aggiornamento. Non dedurre che la route sia stata eliminata solo perché il traffico utilizza un altro percorso.

Mantieni la configurazione di rete del server sotto un unico gestore

La combinazione di script legacy, comandi manuali, Netplan e profili di NetworkManager rende più probabile che gli aggiornamenti facciano emergere conflitti nella gestione.

Una guida pratica e mirata sul networking Linux relativa all’uso di un unico profilo NetworkManager per gestire il percorso del server aiuta a isolare questo caso, perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.

Standardizza la route in un unico profilo gestito, riavvia due volte e conferma che ogni volta ritornino la stessa route e la stessa metrica.

Ripeti il test sul percorso esatto dell’home server

Dopo aver modificato una variabile, ripeti lo stesso flusso NAS o self-hosted dallo stesso client invece di passare a un test diverso che potrebbe utilizzare un altro percorso.

La guida correlata di ZimaSpace sul percorso di rete adiacente dell’home server aiuta a mantenere la verifica finale legata allo stesso ambiente self-hosted.

La correzione è completa solo quando il sintomo originale rimane risolto dopo la riconnessione, il riavvio del servizio e un secondo trasferimento o una seconda richiesta controllati.