Flyt en VPN-server til en ny offentlig IP: hvad du skal tjekke først

At gentildele en adresse tager et minut. Ugen efter er der, hvor flytningen brækker, og sjældent der, hvor udbyderens konsol antyder. En ny offentlig IP refereres fire steder: den socket, daemonen lytter på, det tillidsanker klienterne verificerer, hver regel der nævner den gamle adresse, og den DNS-post, der binder dem sammen. To flytninger ser identiske ud fra et kontrolpanel, men opfører sig helt forskelligt: at gentildele adressen på den maskine, du kører, eller at rejse et andet endpoint og flytte klienter over på det. Tjekkene nedenfor sætter de billige fejl først, og hvert afsnit angiver, hvilken flytning det gælder.

Udskiftning på stedet og parallel overgang er forskellige opgaver

En udskiftning på stedet beholder værten, nøglerne, routingtabellen og brugerlisten; kun adressen ændres. Det er, hvad en gentildeling af en flydende IP gør, og hos flere udbydere bemærker gæsten det slet ikke, fordi oversættelsen sker foran instansen. En genopbygning eller udbyderens gentildeling er hårdere: gæsten ser ændringen, og alt, der har cachet den gamle værdi, lærer det i samme øjeblik.

Et parallelt endpoint er en anden vært, der gør det samme arbejde. Byg det, test det med én profil, og lad den gamle svare, indtil den nye beviser sig over en rigtig vej. Prisen er tilstand. Uden delte peer-poster, tilbagekaldelser og logning har du to netværk, der tilfældigvis deler et navn.

Find hvert sted, hvor den gamle adresse står skrevet

Begynd med en tekstgennemgang, fordi konfigurationsfiler er den lette halvdel. Søg i daemonens konfiguration, firewall-fragmenter, overvågningsmål og enhver genereret klientpakke på disken. Medtag IPv6-adressen, hvis du udgiver en; en flytning, der kun følger A-posten, efterlader dual-stack-klienter på den gamle vej.

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

Gennemgå derefter kernen, fordi et kørende system holder adressen på steder, som ingen fil nævner. En statisk kilde-NAT-regel, en ipset-post, en bind-adresse og en conntrack-post overlever den konfigurationsændring, der fjernede dem, og nogle overlever en genstart, fordi de kom tilbage fra et gemt regelsæt. Et lag højere oppe er udbyderens sikkerhedsgrupper, load balancer-mål og overvågningstjek slet ikke på dit filsystem.

Skriv inventaret ned, før du ændrer noget; det fungerer også som rollback-script.

Hostname-klienter kommer sig; literal-IP-klienter tier

Hvis klienterne når serveren via hostname, er overgangen mest et DNS-problem, og den TTL, du satte i går, afgør, hvor slemt det bliver. Resolvere cacher, stub-resolvere cacher igen, og mange klienter slår kun navnet op ved en ny forbindelse, så en etableret tunnel beholder sin startadresse.

Hvis endpointet er en literal adresse, genopløses intet, og intet logger en klage. WireGuard gemmer en opløst socketadresse: Endpoint = vpn.example.net:51820 bliver en IP i det øjeblik, wg-quick up kører, og forbliver den IP, indtil du ændrer den. OpenVPN er mere overbærende: det opløser remote-hostnamet ved forbindelse og forsøger med resolv-retry infinite DNS igen ved genforbindelse. Givet en literal IP bliver begge ved med at ringe til en maskine, der ikke findes længere.

Det, der vildleder folk, er spejlbilledet. En klient, der allerede peger på den nye adresse, mens den gamle lytter stadig svarer, består enhver test, du kører fra dit eget skrivebord. Jeg er selv blevet narret af det: det nye endpoint kom op på en telefon i første forsøg, og en klient med en forældet profil dukkede først op, da den gamle lytter blev slukket meget senere.

Tillid flytter ikke med adressen

WireGuard adskiller identitet fra tilgængelighed, hvilket gør en adresseflytning næsten gratis. Peers identificeres ved offentlig nøgle, og endpointet er kun dér, hvor pakkerne aktuelt går hen; en vært opdaterer en peers endpoint ud fra kildeadressen på den seneste autentificerede pakke. En inaktiv peer har stadig brug for en grund til at tale med det nye sted, og den lærer adressen, først når dens session udløber, og handshake-forsøgene fejler et synligt sted. WireGuards hurtige start dækker endpoint-feltet.

TLS-baserede servere er det modsatte tilfælde. Certifikatet er bundet til et navn, og en klient, der ringer til en adresse, sammenligner det, den ringede til, med subject alternative names. Forbind via IP til et certifikat, der kun bærer et DNS-SAN, og verifikationen fejler: det navn, klienten brugte, står ikke i certifikatet. Genudstedelse med et IP-SAN retter den ene forbindelse og gør den næste flytning værre. At beholde et hostname i profilen og lade verify-x509-name blive stående holder tjekket strengt, mens adressen under det ændrer sig.

Tjek derefter, hvad daemonen er bundet til; en socket, der er låst til den gamle adresse, fejler lydløst. En OpenVPN-server startet med local 203.0.113.10 nægter at komme op, når den adresse er væk, mens en lytter på 0.0.0.0 følger ændringen gratis. NAT deler sig på samme måde: MASQUERADE følger, hvilken adresse maskinen nu har, og en statisk SNAT --to-source 203.0.113.10 bliver ved med at omskrive til en adresse, du ikke længere ejer, så returtrafik forsvinder. Hvis den nye adresse kommer med en anden upstream-gateway, tjek rp_filter: reverse-path-filtrering dropper returtrafik, der ankommer på et interface, kernen ikke forventede.

Overgangsrækkefølge og beviset for, at det virkede

Sænk TTL'en en dag før, rejs den nye lytter, og bevis den med en profil, som kun du har. En test indefra det samme netværk beviser næsten intet, så brug en telefon på mobilnettet og test noget, tunnelen skal bære, i stedet for et ping til endpointet.

Overvåg begge adresser gennem vinduet. wg show all latest-handshakes på den nye vært, eller OpenVPN-statusfilen, fortæller, hvor mange peers der faktisk er flyttet. Når det nye endpoint har de peers, du forventer, og det gamle kun har efterslæb, så pensionér den gamle lytter, fjern den forældede NAT-regel og fjern adressen fra udbyderens firewall. At fjerne den gamle lytter er det trin, der bliver sprunget over, og det lukker hullet, hvor en forældet profil stadig når det gamle netværk.

Skriv rollback-udløseren ned, før du begynder: hvis det nye endpoint ikke har handshake fra en eneste rigtig klient efter det aftalte vindue, gendan den gamle adresse og stop med at distribuere profiler. Kør gennemgangen igen bagefter og bekræft, at ingen lytter stadig er bundet til en pensioneret adresse. To ting følger med til næste flytning: et hostname i klientprofilen, så den næste ændring er en DNS-redigering, og inventaret, der opbevares ved serverens gendannelsesnoter.