WireGuard-peer verdwijnt na herstart: vind de echte configuratie

De peer die je met wg set hebt toegevoegd, antwoordt de hele middag op ping en is na de herstart verdwenen. Niets is beschadigd: de kernel heeft die peer nooit ergens anders opgeslagen dan in de levende interface, en alles wat de interface bij het opstarten opnieuw maakt, heeft hem opgebouwd uit een bestand dat je niet hebt aangeraakt. De reparatie is geen tweede wg set. Het gaat erom uit te zoeken welke component de interface bezit, de toestand van die component te bewerken en vervolgens te bewijzen dat de peer precies die levenscyclusgebeurtenis overleeft die hem verwijderde.

Reproduceer het één keer, met opzet

Repareer geen herstartprobleem voordat je het kunt zien gebeuren. Met console- of out-of-band-toegang beschikbaar, noteer de peerlijst, herstart via de dienst die de interface bezit, en vergelijk. Als de peer er nog is, heeft je wijziging de persistente toestand al bereikt en debug je de verkeerde gebeurtenis.

Schrijf drie feiten op terwijl je dit doet: de interfacenaam, de unit of het profiel dat hem startte, en of de handshake-teller op de overlevende peer is gereset. Een gereset teller betekent dat de interface is vernietigd en opnieuw gemaakt; een onveranderde teller met een ontbrekende peer betekent dat iets de configuratie onder je voeten heeft bewerkt.

Wie bezit de interface?

WireGuard zelf heeft geen daemon en geen configuratiebestand. Iets erboven roept bij het opstarten wg aan, en dat iets is de bron van waarheid. De gebruikelijke kandidaten zijn [email protected], een NetworkManager-verbindingsprofiel, een distributiespecifieke netwerkeenheid of een beheerpaneel dat zijn eigen database schrijft.

Vraag het systeem, niet de documentatie van je distributie. systemctl status wg-quick@wg0 en nmcli connection show beslissen het meestal met elk één commando. Als beide de interface opeisen, heb je de fout gevonden voordat je iets hebt bewerkt: twee eigenaren herschrijven bij elke start hetzelfde apparaat, en de laatste die draait wint.

systemctl status wg-quick@wg0 --no-pager
grep -R "Address\|SaveConfig\|PostUp" /etc/wireguard/wg0.conf
nmcli -g NAME,TYPE connection show
wg show wg0 peers

Runtimetoestand en opstarttoestand zijn niet hetzelfde bestand

wg set bewerkt het levende apparaat via netlink. Het schrijft niet /etc/wireguard/wg0.conf, een NetworkManager-profiel of de database van een paneel. Een geslaagde wg show daarna bewijst dat de kernel de peer heeft geaccepteerd, niet dat iets hem zal herstellen.

Er is een tweede valkuil in de tegenovergestelde richting. De optie SaveConfig van wg-quick schrijft de huidige interfacetoestand terug naar het configuratiebestand wanneer de interface wordt neergehaald. Als die optie actief is, kan een bewerking van het bestand terwijl de interface actief is, worden overschreven door het afsluiten dat volgt, en je zult zweren dat de regel er stond. Als de peer steeds terugkomt, lees het bestand na een stop, niet ervoor.

NetworkManager gedraagt zich weer anders: hij bezit het profiel en past het toe bij activering, dus een handmatig bewerkte .conf naast een actieve NetworkManager-verbinding is slechts decoratie. Kies één eigenaar voor de interface en laat de andere beheerder hem met rust.

Zorg dat de wijziging op beide plaatsen landt

Bewerk eerst de persistente toestand, laat de eigenaar die vervolgens toepassen en verifieer daarna de levende toestand. Die volgorde betekent dat een fout bij welke stap dan ook op één ding wijst in plaats van drie.

# 1. persistent state (wg-quick owner)
sudo vi /etc/wireguard/wg0.conf

# 2. apply through the owner, not by hand
sudo systemctl restart wg-quick@wg0

# 3. verify runtime matches the file
sudo wg show wg0
sudo wg showconf wg0

wg showconf drukt de levende configuratie af in dezelfde syntaxis die het bestand gebruikt, waardoor de twee direct vergelijkbaar zijn. Behandel die uitvoer als geheim: er staan privésleutels in, dus plak hem niet in een ticket of een chatkanaal. Vergelijk de publieke sleutels van de peers en de toegestane IP's, en controleer dat de peer die je met opzet hebt verwijderd niet terug is.

Bewijs dat hij de levenscyclusgebeurtenis overleeft

Herstart een tweede keer via de eigenaar en bevestig dan drie afzonderlijke dingen: de peer verschijnt in wg show, de handshake-teller stijgt na verkeer, en de toepassing die van de tunnel afhankelijk is, antwoordt daadwerkelijk. Een peer die met een verouderde handshake wordt vermeld, is een routerings- of sleutelprobleem, geen persistentieprobleem, en dat onderscheid bespaart een zinloze configuratiewijziging.

Controleer tot slot wat de herstart heeft hersteld. Een herstart die een peer weer tot leven wekt die je met opzet hebt verwijderd, is dezelfde fout met het omgekeerde teken, en betekent meestal dat er ergens nog een oude kopie van de configuratie wordt geladen. Noteer de eigenaar, het bestandspad, de publieke sleutel van de peer en de verificatiecommando's naast de configuratie, zodat de volgende persoon dit niet opnieuw ontdekt door een productiehost te herstarten.