Flytta en VPN-server till en ny offentlig IP: vad du bör kontrollera först
Byte på plats och parallell övergång går sönder på olika ställen. Gå igenom konfigurationer, NAT och certifikat och kontrollera sedan hur varje klient löser namnet.
Att tilldela en adress på nytt tar en minut. Veckan efter är där flytten går sönder, och sällan där leverantörens konsol antyder det. En ny offentlig IP refereras på fyra ställen: socketen som daemonen lyssnar på, förtroendeankaret som klienterna verifierar, varje regel som nämner den gamla adressen, och DNS-posten som binder dem samman. Två flyttar ser identiska ut från en kontrollpanel men beter sig helt olika: att tilldela adressen på nytt på maskinen du driftar, eller att resa en andra endpoint och flytta klienterna dit. Kontrollerna nedan sätter de billiga felen först, och varje avsnitt anger vilken flytt det gäller.
Byte på plats och parallell övergång är olika jobb
Byte på plats behåller värden, nycklarna, routingtabellen och användarlistan; bara adressen ändras. Det är vad en omtilldelning av en flytande IP gör, och hos flera leverantörer märker gästen ingenting, eftersom översättningen sker framför instansen. En ombyggnad eller leverantörens omtilldelning är hårdare: gästen ser ändringen, och allt som hade det gamla värdet i cache får veta det i samma ögonblick.
En parallell endpoint är en andra värd som gör samma arbete. Bygg den, testa den med en profil och låt den gamla svara tills den nya bevisar sig på en verklig väg. Priset är tillstånd. Utan delade peer-poster, återkallelser och loggning har du två nätverk som råkar dela ett namn.
| Question | In-place swap | Parallel endpoint |
|---|---|---|
| Rollback in one step? | Only if you can get the old address back | Point DNS back; old host still up |
| Blast radius | Every client at once | Only the clients you moved |
| Best when | The address is yours to reassign | The old address is gone for good |
Hitta varje ställe där den gamla adressen står skriven
Börja med en textsökning, eftersom konfigurationsfiler är den lätta halvan. Sök i daemonens konfiguration, brandväggsfragment, övervakningsmål och varje genererad klientpaket på disk. Ta med IPv6-adressen om du publicerar en; en flytt som bara följer A-posten lämnar dual-stack-klienter på den gamla vägen.
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 endpointsGå sedan igenom kärnan, eftersom ett körande system håller adressen på ställen som ingen fil nämner. En statisk käll-NAT-regel, en ipset-post, en bind-adress och en conntrack-post överlever konfigurationsändringen som tog bort dem, och några överlever en omstart eftersom de kom tillbaka från en sparad regeluppsättning. Ett lager högre upp finns leverantörens säkerhetsgrupper, lastbalanserarens mål och övervakningskontroller inte alls på ditt filsystem.
Skriv ner inventariet innan du ändrar något; det fungerar också som återställningsskript.
Hostname-klienter återhämtar sig; literal-IP-klienter tystnar
Om klienterna når servern via värdnamn är övergången mest ett DNS-problem, och TTL-värdet du satte i går avgör hur illa det blir. Resolvers cachar, stub-resolvers cachar igen, och många klienter slår bara upp namnet vid en ny anslutning, så en etablerad tunnel behåller sin startadress.
Om endpointen är en literal adress löses ingenting om, och ingenting loggar en klagomål. WireGuard lagrar en upplöst socketadress: Endpoint = vpn.example.net:51820 blir en IP i samma ögonblick som wg-quick up körs och förblir den IP-adressen tills du ändrar den. OpenVPN är mer förlåtande: det löser värdnamnet remote vid anslutning och försöker med resolv-retry infinite DNS igen vid återanslutning. Med en literal IP fortsätter båda att ringa en maskin som inte längre finns.
Det som lurar folk är spegelbilden. En klient som redan pekar på den nya adressen, medan den gamla lyssnaren fortfarande svarar, klarar varje test du kör från ditt eget skrivbord. Jag har själv blivit lurad av det: den nya endpointen kom upp på en telefon i första försöket, och en klient med en inaktuell profil dök först upp när den gamla lyssnaren stängdes av mycket senare.
Förtroende flyttar inte med adressen
WireGuard skiljer identitet från nåbarhet, vilket gör en adressflytt nästan gratis. Peers identifieras med offentlig nyckel, och endpointen är bara där paketen går just nu; en värd uppdaterar en peers endpoint från källadressen hos det senast autentiserade paketet. En inaktiv peer behöver ändå en anledning att tala med den nya platsen, och den lär sig adressen först när sessionen åldras och handshake-försöken misslyckas på en synlig plats. WireGuards snabbstart täcker endpoint-fältet.
TLS-baserade servrar är det omvända fallet. Certifikatet är bundet till ett namn, och en klient som slår en adress jämför det den slog med subjektets alternativa namn. Anslut via IP till ett certifikat som bara bär ett DNS-SAN och verifieringen misslyckas: namnet klienten använde finns inte i certifikatet. Att utfärda om med ett IP-SAN reparerar den enda anslutningen och gör nästa flytt värre. Att behålla ett värdnamn i profilen och låta verify-x509-name stå kvar håller kontrollen strikt medan adressen under ändras.
Kontrollera sedan vad daemonen är bunden till; en socket fäst vid den gamla adressen misslyckas tyst. En OpenVPN-server startad med local 203.0.113.10 vägrar komma upp när adressen är borta, medan en lyssnare på 0.0.0.0 följer ändringen gratis. NAT delar sig på samma sätt: MASQUERADE följer vilken adress maskinen nu har, och en statisk SNAT --to-source 203.0.113.10 fortsätter att skriva om till en adress du inte längre äger, så returtrafik försvinner. Om den nya adressen kommer med en annan upstream-gateway, kontrollera rp_filter: reverse-path-filtrering släpper returtrafik som anländer på ett gränssnitt som kärnan inte förväntade sig.
Övergångens ordning och beviset att den fungerade
Sänk TTL-värdet en dag i förväg, res den nya lyssnaren och bevisa den med en profil som bara du har. Ett test inifrån samma nätverk bevisar nästan ingenting, så använd en telefon på mobilnätet och testa något som tunneln ska bära i stället för en ping mot endpointen.
Bevaka båda adresserna genom fönstret. wg show all latest-handshakes på den nya värden, eller OpenVPN:s statusfil, berättar hur många peers som faktiskt flyttat. När den nya endpointen har de peers du förväntar dig och den gamla bara har eftersläntrare, pensionera den gamla lyssnaren, ta bort den inaktuella NAT-regeln och ta bort adressen från leverantörens brandvägg. Att ta bort den gamla lyssnaren är steget som hoppas över, och det stänger gapet där en inaktuell profil fortfarande når det gamla nätverket.
Skriv ner återställningsutlösaren innan du börjar: om den nya endpointen inte har handshake från en enda riktig klient efter det överenskomna fönstret, återställ den gamla adressen och sluta distribuera profiler. Kör sökningen igen efteråt och bekräfta att ingen lyssnare fortfarande är bunden till en pensionerad adress. Två saker följer med till nästa flytt: ett värdnamn i klientprofilen så att nästa ändring är en DNS-redigering, och inventariet som förvaras vid serverns återställningsanteckningar.