Flytte en VPN-server til en ny offentlig IP: hva du bør sjekke først

Å tildele en adresse på nytt tar ett minutt. Uken etter er der flyttingen bryter sammen, og sjelden der leverandørens konsoll antyder det. En ny offentlig IP refereres fire steder: socketen daemonen lytter på, tillitsankeret klientene verifiserer, hver regel som nevner den gamle adressen, og DNS-posten som binder dem sammen. To flyttinger ser identiske ut fra et kontrollpanel, men oppfører seg helt ulikt: å tildele adressen på nytt på maskinen du drifter, eller å reise et andre endpoint og flytte klientene dit. Sjekkene nedenfor setter de billige feilene først, og hver del angir hvilken flytting den gjelder.

Utskifting på stedet og parallell overgang er forskjellige jobber

Utskifting på stedet beholder verten, nøklene, rutetabellen og brukerlisten; bare adressen endres. Det er hva en ny tildeling av en flytende IP gjør, og hos flere leverandører merker gjesten ingenting, fordi oversettelsen skjer foran instansen. En ombygging eller leverandørens nye tildeling er hardere: gjesten ser endringen, og alt som hadde den gamle verdien i cache lærer det i samme øyeblikk.

Et parallelt endpoint er en andre vert som gjør samme jobb. Bygg det, test det med én profil, og la den gamle svare til den nye beviser seg på en reell vei. Prisen er tilstand. Uten delte peer-oppføringer, tilbakekallinger og logging har du to nettverk som tilfeldigvis deler et navn.

Finn hvert sted den gamle adressen står skrevet

Begynn med et tekstsøk, fordi konfigurasjonsfiler er den lette halvparten. Søk i daemonkonfigurasjonen, brannmur-fragmenter, overvåkingsmål og enhver generert klientpakke på disk. Ta med IPv6-adressen hvis du publiserer en; en flytting som bare følger A-posten, lar dual-stack-klienter bli igjen på den gamle veien.

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

Gå så gjennom kjernen, fordi et kjørende system holder adressen på steder ingen fil nevner. En statisk kilde-NAT-regel, en ipset-oppføring, en bind-adresse og en conntrack-oppføring overlever konfigurasjonsendringen som fjernet dem, og noen overlever omstart fordi de kom tilbake fra et lagret regelsett. Ett lag høyere er leverandørens sikkerhetsgrupper, målene for lastbalansereren og overvåkingssjekkene ikke på filsystemet ditt i det hele tatt.

Skriv ned inventaret før du endrer noe; det fungerer også som rollback-skript.

Hostname-klienter kommer seg; literal-IP-klienter blir stille

Hvis klientene når serveren via vertsnavn, er overgangen mest et DNS-problem, og TTL-en du satte i går avgjør hvor ille det blir. Resolvere cacher, stub-resolvere cacher igjen, og mange klienter slår bare opp navnet på en ny tilkobling, så en etablert tunnel beholder startadressen.

Hvis endepunktet er en literal adresse, løses ingenting på nytt, og ingenting logger en klage. WireGuard lagrer en oppslått socket-adresse: Endpoint = vpn.example.net:51820 blir en IP i det øyeblikket wg-quick up kjøres, og forblir den IP-en til du endrer den. OpenVPN er mer overbærende: det slår opp vertsnavnet remote ved tilkobling og prøver med resolv-retry infinite DNS på nytt ved gjenoppkobling. Med en literal IP fortsetter begge å ringe en maskin som ikke finnes lenger.

Det som lurer folk, er speilbildet. En klient som allerede peker på den nye adressen, mens den gamle lytteren fortsatt svarer, består hver test du kjører fra din egen pult. Jeg har selv blitt lurt av det: det nye endepunktet kom opp på en telefon i første forsøk, og en klient med en utdatert profil dukket først opp da den gamle lytteren ble slått av mye senere.

Tillit flytter ikke med adressen

WireGuard skiller identitet fra tilgjengelighet, noe som gjør en adresseflytting nesten gratis. Peers identifiseres med offentlig nøkkel, og endepunktet er bare der pakkene går akkurat nå; en vert oppdaterer en peers endepunkt fra kildeadressen til den siste autentiserte pakken. En inaktiv peer trenger likevel en grunn til å snakke med det nye stedet, og den lærer adressen først når økten blir gammel og handshake-forsøkene feiler på et synlig sted. WireGuards hurtigstart dekker endepunktfeltet.

TLS-baserte servere er det motsatte tilfellet. Sertifikatet er bundet til et navn, og en klient som ringer en adresse, sammenligner det den ringte med subject alternative names. Koble til via IP til et sertifikat som bare bærer et DNS-SAN, og verifiseringen feiler: navnet klienten brukte, står ikke i sertifikatet. Å utstede på nytt med et IP-SAN retter den ene tilkoblingen og gjør neste flytting verre. Å beholde et vertsnavn i profilen og la verify-x509-name stå holder sjekken streng mens adressen under endres.

Sjekk deretter hva daemonen er bundet til; en socket festet til den gamle adressen feiler lydløst. En OpenVPN-server startet med local 203.0.113.10 nekter å komme opp når adressen er borte, mens en lytter på 0.0.0.0 følger endringen gratis. NAT deler seg på samme måte: MASQUERADE følger hvilken adresse maskinen nå har, og en statisk SNAT --to-source 203.0.113.10 fortsetter å skrive om til en adresse du ikke lenger eier, så returtrafikk forsvinner. Hvis den nye adressen kommer med en annen upstream-gateway, sjekk rp_filter: reverse-path-filtrering slipper returtrafikk som ankommer et grensesnitt kjernen ikke forventet.

Rekkefølgen for overgangen og beviset på at den virket

Senk TTL-en en dag i forveien, reis den nye lytteren, og bevis den med en profil bare du har. En test fra innsiden av samme nettverk beviser nesten ingenting, så bruk en telefon på mobilnett og test noe tunnelen skal bære i stedet for en ping til endepunktet.

Følg begge adressene gjennom vinduet. wg show all latest-handshakes på den nye verten, eller OpenVPN-statusfilen, forteller hvor mange peers som faktisk har flyttet. Når det nye endepunktet har peerne du forventer og det gamle bare har etterslengere, pensjoner den gamle lytteren, fjern den utdaterte NAT-regelen og ta adressen ut av leverandørens brannmur. Å fjerne den gamle lytteren er trinnet som hoppes over, og det lukker gapet der en utdatert profil fortsatt når det gamle nettverket.

Skriv ned rollback-utløseren før du begynner: hvis det nye endepunktet ikke har handshake fra én eneste ekte klient etter det avtalte vinduet, gjenopprett den gamle adressen og slutt å distribuere profiler. Kjør søket på nytt etterpå og bekreft at ingen lytter fortsatt er bundet til en pensjonert adresse. To ting følger med til neste flytting: et vertsnavn i klientprofilen slik at neste endring er en DNS-redigering, og inventaret som oppbevares ved serverens gjenopprettingsnotater.