Een VPN-server herstellen zonder identiteiten te dupliceren

Je hebt de back-up hersteld, de dienst startte en een client verbond bij de eerste poging. Dat succes is de val. Een herstel geeft de bestanden terug die de server op het moment van de snapshot had, niet de toegangsstatus die sindsdien is veranderd, en als het oude eindpunt nog bereikbaar is heb je nu twee machines die op één identiteit antwoorden. De oplossing is geen betere back-up; het is beslissen wat de herstelde host mag zijn voordat hij één handshake beantwoordt.

Een back-up brengt bestanden terug, geen gezag

De snapshot bevat de serverconfiguratie, de privésleutels, de certificaatautoriteit, de peerlijst en de firewallregels zoals ze waren toen de back-up liep. Hij kan niet bevatten wat daarna veranderde: het apparaat dat je introk, de sleutel die je opnieuw uitgaf, de peer die je verwijderde toen een laptop werd verkocht, het subnet dat je verplaatste. Herstellen spoelt de bestanden terug naar dat moment. Het spoelt de beslissingen die mensen sindsdien namen niet terug.

De schade komt juist uit die kloof. Een gestolen laptop die twee weken na de back-up werd ingetrokken, toont een certificaat dat nog valideert tegen de oudere CRL in de herstelde boom, en de server accepteert een apparaat dat je buiten gebruik hebt gesteld. WireGuard is directer: een peer is geautoriseerd door op de lijst te staan, dus een peer die na de snapshot werd verwijderd is gewoon weer aanwezig. Niemand keurde die toegang opnieuw goed. Het oude bestand deed het.

Serveridentiteit en clientidentiteit falen op verschillende manieren

Bij WireGuard is de identiteit van de server de privésleutel in wg0.conf, dus het kopiëren van dat bestand naar een tweede bereikbare host maakt twee servers met dezelfde identiteit die elkaar niet kennen. Elk houdt zijn eigen peerlijst bij. Verwijder een peer op de nieuwe host en de oude accepteert hem nog steeds; controleer wg show op één en je ziet de helft van de waarheid. Clients schakelen ook niet zelf over: een profiel draagt één Endpoint, dus een apparaat blijft praten met het adres waarmee het is geconfigureerd, wat de host kan zijn die je wilde uitfaseren.

OpenVPN dupliceert op dezelfde laag met een servercertificaat, de bijbehorende privésleutel en de statische sleutel tls-auth of tls-crypt. Kopieer alle drie en een client kan de instanties niet onderscheiden; als beide bereikbaar zijn, kan een herverbinding op een van beide landen, en elk logbestand vertelt een half verhaal. De certificaatautoriteit is de diepere kopie. Een herstelde easy-rsa-boom is een tweede bron van waarheid die een geldig certificaat kan uitgeven voor elke naam die je hem geeft.

Clients worden ook gedupliceerd, meestal tijdens de migratie zelf. Een profiel naar een reserveapparaat kopiëren «alleen om te testen» levert een tweede apparaat met dezelfde sleutel en dezelfde common name. Met duplicate-cn kunnen beide sessies tegelijk actief blijven, en een statische adresstoewijzing in ccd of ifconfig-pool-persist kan botsen met het oorspronkelijke apparaat. Dat zijn twee machines met één identiteit, en niets in de serverconfiguratie onderscheidt ze.

Kies een van drie toestanden voor het oude eindpunt

Een herstel is pas veilig als het lot van het oude eindpunt is beslist. Faseer het uit: de oude dienst moet stoppen met het accepteren van de VPN-poort voordat de nieuwe host start, en als je de machine niet kunt bereiken, blokkeer die poort dan aan de netwerkrand voor alles behalve je beheerbron. Repareer dezelfde host: hergebruik van de identiteit is prima omdat één machine hem vasthoudt, maar vernietig daarna de schijfkopie of VM-snapshot van de oude sleutel zodat die niet kan terugkeren. Bouw een beschikbaarheidspaar: twee hosts hebben aparte hostidentiteiten nodig plus één gedeeld eindpunt, zoals een zwevend adres, een load balancer of DNS die je kunt verplaatsen. De privésleutel kopiëren is geen failover-ontwerp; het zijn twee servers die één naam opeisen.

Bevestig in welke toestand je werkelijk bent voordat je clients aanraakt. De oude host die op de VPN-poort antwoordt, is degene die het ingetrokken apparaat accepteert, zelfs als DNS is verhuisd. Controleer luisteraars en de publieke sleutel:

ss -lunp | grep -E ':51820|:1194'
wg show wg0
wg pubkey < /etc/wireguard/server.key

Stem eerst peers, intrekkingen en adressen af

Lijst op wat het herstel claimt tegenover wat nu is geautoriseerd. Bij WireGuard geeft wg show wg0 de sleutel, het eindpunt, de laatste handshake en de overdrachtstellers van elke peer, genoeg om een apparaat te herkennen dat je niet meer bezit. Verwijder het live met wg set wg0 peer <key> remove, bewerk daarna ook de configuratie, anders komt de peer bij de volgende start terug. wg show wg0 allowed-ips onthult het tweede probleem: twee peers op één adres, of een adres dat je al opnieuw hebt toegewezen.

Bij OpenVPN is de intrekkingslijst een bestand met een datum, en een herstel kan een oude terugbrengen. Controleer hem voordat clients verbinden:

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
grep -E 'crl-verify|reneg-sec' /etc/openvpn/server.conf

Als de laatste update vóór de intrekking ligt, respecteert de server nog een certificaat dat je hebt ingetrokken. OpenVPN 2.4 en later lezen het CRL-bestand opnieuw voor elke nieuwe verbinding, dus het bestand vervangen stopt nieuwe sessies, maar bestaande tunnels blijven bestaan tot heronderhandeling; de standaardwaarde van reneg-sec is 3600 seconden, en juist het verlagen daarvan of het herstarten van de dienst geeft je de wijziging nu. Oudere builds pikken het bestand misschien niet zo betrouwbaar op, dus herstart wanneer je het gedrag van de versie niet kunt bevestigen. De wg(8)-handleiding behandelt het verwijderen van peers en de hierboven gebruikte allowed-ips-syntaxis.

Ruim ook statische toewijzingen op voor apparaten die niet meer bestaan. Het adres van een uitgefaseerd apparaat hergebruiken voor een nieuw terwijl het oude profiel nog is geïnstalleerd, maakt precies het duplicaat dat je probeert te vermijden.

Verifieer met een client die je hebt ingetrokken

Voer de controles in volgorde uit, vanaf een netwerk buiten de tunnel. Eerst verbindt een geautoriseerd apparaat, lost DNS op via de gepushte resolver en bereikt een privébron. Daarna moet het ingetrokken apparaat falen, met zijn bestaande profiel in plaats van een nieuw. Probeer dan het oude eindpunt van buitenaf: als de VPN-poort nog een handshake voltooit, leeft de oude host en is de duplicatie echt, niet theoretisch.

Herstart de herstelde host en herhaal de controles voor geautoriseerd en ingetrokken, want dan wint het configuratiebestand van wat je tijdens runtime hebt gewijzigd. Vergelijk de publieke sleutel of certificaatvingerafdruk van de host met die van de uitgefaseerde machine. Overeenkomende vingerafdrukken op twee levende machines betekenen dat het herstel de identiteit heeft gekloond; overeenkomende vingerafdrukken op één machine zijn prima. Noteer de herstelde versies, sleutelvingerafdrukken en het ingetrokken serienummer of de peersleutel, en maak daarna de volgende back-up na deze afstemming, zodat die de dienst weergeeft zoals hij nu is. De werkende test is niet dat een client verbindt. Het is dat de client die je hebt verwijderd buiten blijft terwijl het oude eindpunt gesloten blijft.