NetworkManager of wg-quick: wie bezit jouw WireGuard-routes?

Je wijzigt AllowedIPs in het WireGuard-bestand, herstart de tunnel, en de routetabel ziet er precies hetzelfde uit als voorheen. De gebruikelijke reactie is de storende route verwijderen en doorgaan, wat werkt tot de volgende herverbinding hem terugzet. Het bestand dat je hebt bewerkt is niet noodzakelijk het object dat de toestand heeft veroorzaakt die je ziet. Twee beheerders kunnen hetzelfde protocol op één machine draaien, en slechts één van hen bezit de interface op elk moment.

Mythe: er is één WireGuard-configuratie op de machine

wg-quick leest een bestand onder /etc/wireguard/ en bouwt de interface op wanneer je hem opzet. NetworkManager bewaart een verbindingsprofiel in zijn eigen keyfile-formaat en rendert het bij activatie, en het importeren van een wg-quick-bestand kopieert de waarden naar dat profiel in plaats van ernaar te verwijzen. Het origineel daarna bewerken verandert niets, omdat het profiel het niet meer leest. Dezelfde lijst met peers en sleutels kan dus twee keer bestaan, waarbij de tweede kopie geldt.

Een teken dat het onthouden waard is: wijzigingen die een herstart overleven maar geen herimport, komen uit één opslag, en wijzigingen die bij herstart verdwijnen komen uit de andere.

Eén praktisch voorbeeld maakt de splitsing duidelijk. Vergelijk nmcli connection show met systemctl status wg-quick@wg0, en controleer dan aan welke interface de routes werkelijk hangen. Als de dienst dood is en de interface staat omhoog, doet het profiel het werk, wat het bestand ook zegt.

Mythe: de routeringsregels horen bij WireGuard

Het WireGuard-apparaat in de kernel kent peers en sleutels, en het weet niets van policy-routing. Welke ip rule -vermeldingen en extra tabellen je ook ziet, ze zijn geïnstalleerd door het gereedschap dat de interface omhoog bracht. wg-quick kan een fwmark en een eigen tabel plus regels die daarheen wijzen toevoegen, terwijl NetworkManager routes installeert via zijn eigen ipv4-instellingen en DNS overlaat aan de resolver-backend die het systeem gebruikt. Dezelfde tunnel, andere bijwerkingen.

Lees ip rule en ip route show table all voordat je iets verandert, en noteer in welke tabel elke route woont. Een tabelnummer dat je niet hebt geconfigureerd is een sterke aanwijzing over het gereedschap dat hem heeft aangemaakt.

Mythe: de route verwijderen is een oplossing

Een route die tijdens runtime wordt verwijderd, is een route die de eigenaar bij de volgende activatie opnieuw installeert, en de activatie kan zonder jou gebeuren: een laptop die ontwaakt, een linkflap, een dienstherstart of een automatische verbinding van NetworkManager. Daarom komt dezelfde route terug en daarom voelt de workaround onbetrouwbaar in plaats van fout. Identificeer eerst de beheerder en wijzig dan de invoer die die beheerder werkelijk leest.

Opnieuw verbinden en de relevante dienst herstarten is de test die een echte oplossing scheidt van een die er alleen netjes uitziet.

Kies één eigenaar en verwijder de ander

Kies de beheerder die je uitrol ondersteunt, en schakel dan de concurrerende activatie uit via zijn gedocumenteerde besturing in plaats van te hopen dat hij inactief blijft. Een gemaskeerde wg-quick-dienst of een verwijderd NetworkManager-profiel is expliciet; beide ingeschakeld laten en ze laten racen niet. Behoud werkende toegang voordat je iets uitschakelt, want de interface die je externe sessie draagt is misschien degene die je op het punt staat te verwijderen.

Controleer na de wijziging het inbegrepen en uitgesloten verkeer, dan DNS, en herstart dan één keer. Als de toestand een herstart met één beheerder overleeft, heb je een eigenaar in plaats van een toeval.

De algemene regel is het waard om buiten WireGuard te onthouden: wanneer een instelling blijft terugkomen, stop dan met het resultaat te verwijderen en zoek het proces dat het blijft produceren.