Waarom verliest een thuisserver één statische route na een upgrade van NetworkManager?

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Een statische route kan na een NetworkManager-upgrade verdwijnen wanneer de route deel uitmaakte van een profiel of configuratiepad dat niet langer de actieve verbinding is.

Op een ZimaSpace of Linux-thuisserver kan een route naar een IoT-VLAN, back-upsubnet of secundaire router handmatig zijn toegevoegd met ip route, zijn opgeslagen in een oud verbindingsprofiel of zijn gekoppeld aan een profiel dat NetworkManager na een upgrade vervangt. De juiste test vergelijkt de actieve route met het actieve persistente profiel, in plaats van de opdracht na elke herstart opnieuw uit te voeren.

Controleer of de route ooit persistent was

Vergelijk een route die met ip route is toegevoegd met het NetworkManager-verbindingsprofiel dat deze route opnieuw zou moeten aanmaken.

Een gerichte praktische networkmanager-gids over persistente statische routes horen in het verbindingsprofiel helpt deze mogelijkheid te isoleren, omdat de gids hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.

Als de route alleen in de kernel-routingtabel bestaat, verplaats deze dan naar het beheerde profiel voordat je de upgrade de schuld geeft.

Controleer profielwijzigingen die door de upgrade zijn veroorzaakt

Vergelijk profielnamen, UUID's, de status van autoconnect en route-items vóór en na de pakketupgrade.

Een gericht artikel over probleemoplossing rond statische routes kunnen verdwijnen wanneer de NetworkManager-status verandert helpt deze mogelijkheid te isoleren, omdat het hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.

Herstel de route in het actieve persistente profiel en bewaar een kopie van het vorige profiel ter vergelijking.

Houd er rekening mee dat NetworkManager profielgericht werkt

Een interface kan meerdere opgeslagen profielen hebben, maar alleen het geactiveerde profiel draagt zijn route-instellingen bij.

Een gerichte engineeringblog over NetworkManager over NetworkManager-configuratie draait om verbindingsprofielen helpt deze mogelijkheid te isoleren, omdat de blog hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.

Identificeer het actieve profiel aan de hand van de UUID in plaats van een willekeurige bekende bestandsnaam te bewerken.

Controleer de routingtabel en beleidsregels samen

Een route kan nog steeds in een niet-hoofdtabel bestaan, terwijl de regel die deze tabel selecteerde is gewijzigd.

Een gerichte uitleg over Linux-routing op beleidsrouting gebruikt zowel tabellen als regels helpt deze mogelijkheid te isoleren, omdat de uitleg hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.

Geef ip rule en elke relevante tabel weer voordat je een dubbele route aan main toevoegt.

Controleer of routemetrieken de voorkeursroute hebben gewijzigd

Wanneer twee routes dezelfde bestemming omvatten, kan de route met de laagste effectieve metriek of de meest specifieke route het verwachte pad vervangen.

Een gerichte Linux-netwerktutorial over routemetrieken bepalen welk pad wordt gekozen helpt deze mogelijkheid te isoleren, omdat de tutorial hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.

Vergelijk het bestemmingsprefix, de metriek en de interface na de update. Ga niet alleen vanwege het gebruik van een andere route ervan uit dat de oorspronkelijke route is verwijderd.

Houd de netwerkconfiguratie van de server bij één beheerder

Het combineren van verouderde scripts, handmatige opdrachten, Netplan en NetworkManager-profielen maakt het waarschijnlijker dat upgrades conflicterend eigenaarschap aan het licht brengen.

Een gerichte praktische Linux-netwerkgids over één NetworkManager-profiel moet het serverpad beheren helpt deze mogelijkheid te isoleren, omdat de gids hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.

Standaardiseer de route in één beheerd profiel, start de server tweemaal opnieuw op en controleer telkens of dezelfde route en metriek terugkeren.

Test het exacte pad naar de thuisserver opnieuw

Herhaal na het wijzigen van één variabele dezelfde NAS- of self-hosted-workflow vanaf dezelfde client, in plaats van over te schakelen naar een andere test die mogelijk een ander pad gebruikt.

De gerelateerde ZimaSpace-gids over het aangrenzende netwerkpad naar de thuisserver helpt de uiteindelijke verificatie gekoppeld te houden aan dezelfde self-hosted-omgeving.

De oplossing is pas compleet wanneer het oorspronkelijke symptoom opgelost blijft na opnieuw verbinden, het herstarten van de service en een tweede gecontroleerde overdracht of aanvraag.

Veelgestelde vragen

Waarom werkt ip route add tot het opnieuw opstarten?

De opdracht wijzigt de actieve kernel-routingtabel, maar maakt niet automatisch persistente NetworkManager-configuratie aan.

Kan de route nog bestaan, maar de verkeerde tabel gebruiken?

Ja. Beleidsrouting kan routes in alternatieve tabellen plaatsen waarvoor bijbehorende regels nodig zijn.

Moet ik verbindingsbestanden na een upgrade handmatig bewerken?

Gebruik bij voorkeur nmcli of de door het platform ondersteunde beheerder, tenzij je een gecontroleerde reden hebt om keyfiles rechtstreeks te beheren.

Ondersteuning & Tips

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.