Een VPN-server naar een nieuw openbaar IP verhuizen: wat u eerst moet controleren

Een adres opnieuw toewijzen kost een minuut. De week erna is waar de verhuizing breekt, en zelden waar de console van de provider het suggereert. Een nieuw openbaar IP wordt op vier plaatsen genoemd: de socket waarop de daemon luistert, het vertrouwensanker dat clients verifiëren, elke regel die het oude adres noemt, en de DNS-record die ze verbindt. Twee verhuizingen lijken identiek vanaf een bedieningspaneel maar gedragen zich totaal anders: het adres opnieuw toewijzen op de machine die u beheert, of een tweede endpoint opzetten en clients daarheen verhuizen. De controles hieronder zetten de goedkope fouten vooraan, en elke sectie noemt op welke verhuizing die van toepassing is.

In-place vervanging en parallelle overgang zijn verschillende klussen

Een in-place vervanging behoudt de host, de sleutels, de routingtabel en de gebruikerslijst; alleen het adres verandert. Dat doet een hertoewijzing van een zwevend IP, en bij verschillende providers merkt de gast er niets van, omdat de vertaling vóór de instantie gebeurt. Een herbouw of hertoewijzing door de provider is harder: de gast ziet de wijziging, en alles wat de oude waarde in de cache had, leert het op hetzelfde moment.

Een parallel endpoint is een tweede host die hetzelfde werk doet. Bouw het, test het met één profiel, en laat de oude antwoorden tot de nieuwe zich op een echte route bewijst. De prijs is toestand. Zonder gedeelde peer-vermeldingen, intrekkingen en logging hebt u twee netwerken die toevallig een naam delen.

Vind elke plek waar het oude adres staat opgeschreven

Begin met een tekstzoekactie, want configuratiebestanden zijn de makkelijke helft. Zoek in de daemonconfiguratie, firewallfragmenten, monitoringdoelen en elke gegenereerde clientbundel op schijf. Neem het IPv6-adres mee als u er een publiceert; een verhuizing die alleen de A-record volgt, laat dual-stack-clients op het oude pad.

OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpoints

Loop daarna de kernel na, want een draaiend systeem houdt het adres op plekken die geen enkel bestand noemt. Een statische bron-NAT-regel, een ipset-vermelding, een bindadres en een conntrack-vermelding overleven de configuratiewijziging die ze verwijderde, en sommige overleven een herstart omdat ze terugkwamen uit een opgeslagen regelset. Eén laag hoger staan beveiligingsgroepen van de provider, doelen van de loadbalancer en monitoringcontroles helemaal niet op uw bestandssysteem.

Schrijf de inventaris op voordat u iets verandert; die dient ook als rollbackscript.

Hostname-clients herstellen; literal-IP-clients blijven stil

Als clients de server via een hostnaam bereiken, is de overgang vooral een DNS-probleem, en de TTL die u gisteren instelde bepaalt hoe erg het wordt. Resolvers cachen, stub-resolvers cachen nog eens, en veel clients zoeken de naam alleen op bij een nieuwe verbinding, dus een bestaande tunnel behoudt zijn beginadres.

Als het endpoint een letterlijk adres is, wordt niets opnieuw opgelost en logt niets een klacht. WireGuard bewaart een opgelost socketadres: Endpoint = vpn.example.net:51820 wordt een IP op het moment dat wg-quick up draait en blijft dat IP tot u het wijzigt. OpenVPN is toegeeflijker: het lost de hostnaam remote op bij het verbinden en probeert met resolv-retry infinite opnieuw DNS bij het herverbinden. Met een letterlijk IP blijven beide een machine bellen die niet meer bestaat.

Wat mensen misleidt, is het spiegelbeeld. Een client die al naar het nieuwe adres wijst, terwijl de oude luisteraar nog antwoordt, slaagt voor elke test die u vanaf uw eigen bureau doet. Ik ben er zelf ingetrapt: het nieuwe endpoint kwam op een telefoon in één poging omhoog, en een client met een verouderd profiel kwam pas boven water toen de oude luisteraar veel later werd uitgezet.

Vertrouwen verhuist niet mee met het adres

WireGuard scheidt identiteit van bereikbaarheid, wat een adresverhuizing bijna gratis maakt. Peers worden geïdentificeerd met een openbare sleutel, en het endpoint is alleen waar pakketten nu heen gaan; een host werkt het endpoint van een peer bij op basis van het bronadres van het laatst geauthenticeerde pakket. Een inactieve peer heeft toch een reden nodig om met de nieuwe plek te praten, en leert het adres pas als zijn sessie veroudert en de handshake-pogingen op een zichtbare plek mislukken. De WireGuard-snelstart behandelt het endpointveld.

TLS-gebaseerde servers zijn het omgekeerde geval. Het certificaat is aan een naam gebonden, en een client die een adres kiest, vergelijkt wat hij koos met de alternatieve namen van het subject. Verbind via IP met een certificaat dat alleen een DNS-SAN draagt en de verificatie mislukt: de naam die de client gebruikte staat niet in het certificaat. Opnieuw uitgeven met een IP-SAN repareert die ene verbinding en maakt de volgende verhuizing erger. Een hostnaam in het profiel houden en verify-x509-name laten staan houdt de controle streng terwijl het adres eronder verandert.

Controleer dan waaraan de daemon gebonden is; een socket die aan het oude adres vastzit, faalt stil. Een OpenVPN-server die met local 203.0.113.10 start, weigert omhoog te komen zodra dat adres weg is, terwijl een luisteraar op 0.0.0.0 de wijziging gratis volgt. NAT splitst op dezelfde manier: MASQUERADE volgt welk adres de machine nu heeft, en een statische SNAT --to-source 203.0.113.10 blijft herschrijven naar een adres dat u niet meer bezit, dus retourverkeer verdwijnt. Als het nieuwe adres met een andere upstream-gateway komt, controleer rp_filter: reverse-path-filtering laat retourverkeer vallen dat aankomt op een interface die de kernel niet verwachtte.

Volgorde van de overgang en het bewijs dat het werkte

Verlaag de TTL een dag van tevoren, zet de nieuwe luisteraar op, en bewijs hem met een profiel dat alleen u hebt. Een test van binnen hetzelfde netwerk bewijst bijna niets, dus gebruik een telefoon op mobiel netwerk en test iets wat de tunnel moet dragen in plaats van een ping naar het endpoint.

Houd beide adressen in de gaten gedurende het venster. wg show all latest-handshakes op de nieuwe host, of het OpenVPN-statusbestand, vertelt hoeveel peers echt zijn verhuisd. Wanneer het nieuwe endpoint de peers heeft die u verwacht en het oude alleen achterblijvers, trek de oude luisteraar uit, verwijder de verouderde NAT-regel en haal het adres uit de firewall van de provider. De oude luisteraar verwijderen is de stap die wordt overgeslagen, en hij sluit het gat waar een verouderd profiel nog het oude netwerk bereikt.

Leg de rollback-trigger schriftelijk vast voordat u begint: als het nieuwe endpoint na het afgesproken venster geen handshake van één echte client heeft, herstel dan het oude adres en stop met het verspreiden van profielen. Draai de zoekactie daarna opnieuw en bevestig dat geen luisteraar nog aan een uitgerangeerd adres is gebonden. Twee dingen gaan mee naar de volgende verhuizing: een hostnaam in het clientprofiel zodat de volgende wijziging een DNS-bewerking is, en de inventaris die naast de herstelnotities van de server wordt bewaard.