Flytte ein VPN-server til ein ny offentleg IP: kva du bør sjekke først

Å tildela ei adresse på nytt tek eitt minutt. Veka etter er der flyttinga bryt saman, og sjeldan der leverandøren sin konsoll antydar det. Ein ny offentleg IP vert referert fire stader: sockelen daemonen lyttar på, tillitsankeret klientane verifiserer, kvar regel som nemner den gamle adressa, og DNS-posten som bind dei saman. To flyttingar ser identiske ut frå eit kontrollpanel, men oppfører seg heilt ulikt: å tildela adressa på nytt på maskinen du driftar, eller å reisa ein andre endpoint og flytta klientane dit. Sjekkane nedanfor set dei billege feila først, og kvar del angir kva flytting han gjeld.

Utskifting på staden og parallell overgang er ulike jobbar

Utskifting på staden held på verten, nøklane, rutetabellen og brukarlista; berre adressa endrar seg. Det er kva ei ny tildeling av ein flytande IP gjer, og hos fleire leverandørar merkar gjesten ingenting, fordi omsetjinga skjer framfor instansen. Ein ombygging eller leverandøren si nye tildeling er hardare: gjesten ser endringa, og alt som hadde den gamle verdien i cache lærer det i same augneblink.

Ein parallell endpoint er ein andre vert som gjer same jobb. Bygg han, test han med éin profil, og la den gamle svara til den nye beviser seg på ein reell veg. Prisen er tilstand. Utan delte peer-oppføringar, tilbakekallingar og logging har du to nettverk som tilfeldigvis deler eit namn.

Finn kvar stad den gamle adressa står skriven

Byrja med eit tekstsøk, fordi konfigurasjonsfiler er den lette halvdelen. Søk i daemonkonfigurasjonen, brannmur-fragment, overvakingsmål og kvar generert klientpakke på disk. Ta med IPv6-adressa om du publiserer ei; ei flytting som berre følgjer A-posten, lèt dual-stack-klientar bli att på den gamle vegen.

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 eit køyrande system held adressa på stader ingen fil nemner. Ein statisk kjelde-NAT-regel, ein ipset-oppføring, ei bind-adresse og ein conntrack-oppføring overlever konfigurasjonsendringa som fjerna dei, og nokre overlever omstart fordi dei kom tilbake frå eit lagra regelsett. Eitt lag høgare er leverandøren sine tryggingsgrupper, måla for lastbalanseren og overvakingssjekkane ikkje på filsystemet ditt i det heile.

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

Hostname-klientar kjem seg; literal-IP-klientar blir stille

Viss klientane når serveren via vertsnamn, er overgangen mest eit DNS-problem, og TTL-en du sette i går avgjer kor ille det blir. Resolvarar cachar, stub-resolvarar cachar igjen, og mange klientar slår berre opp namnet på ei ny tilkopling, så ein etablert tunnel held på startadressa.

Viss endepunktet er ei literal adresse, vert ingenting løyst på nytt, og ingenting loggar ei klage. WireGuard lagrar ei oppløyst socket-adresse: Endpoint = vpn.example.net:51820 blir ein IP i det augneblinken wg-quick up køyrer, og blir verande den IP-en til du endrar han. OpenVPN er meir overberande: det slår opp vertsnamnet remote ved tilkopling og prøver med resolv-retry infinite DNS på nytt ved attilkopling. Med ein literal IP held begge fram med å ringja ein maskin som ikkje finst lenger.

Det som lurar folk, er spegelbiletet. Ein klient som alt peikar på den nye adressa, medan den gamle lyttaren framleis svarar, går gjennom kvar test du køyrer frå din eigen pult. Eg har sjølv blitt lurt av det: det nye endepunktet kom opp på ein telefon i første forsøk, og ein klient med ein utdatert profil dukka først opp då den gamle lyttaren vart slått av mykje seinare.

Tillit flyttar ikkje med adressa

WireGuard skil identitet frå tilgjenge, noko som gjer ei adresseflytting nesten gratis. Peers vert identifiserte med offentleg nøkkel, og endepunktet er berre der pakkane går akkurat no; ein vert oppdaterer endepunktet til ein peer frå kjeldeadressa til den siste autentiserte pakken. Ein inaktiv peer treng likevel ein grunn til å snakka med den nye staden, og han lærer adressa først når økta blir gammal og handshake-forsøka feilar på ein synleg stad. WireGuards hurtigstart dekkjer endepunktfeltet.

TLS-baserte serverar er det motsette tilfellet. Sertifikatet er bunde til eit namn, og ein klient som ringjer ei adresse, samanliknar det han ringde med subject alternative names. Kople til via IP til eit sertifikat som berre ber eit DNS-SAN, og verifiseringa feilar: namnet klienten brukte, står ikkje i sertifikatet. Å gje ut på nytt med eit IP-SAN rettar den eine tilkoplinga og gjer neste flytting verre. Å halda på eit vertsnamn i profilen og la verify-x509-name stå held sjekken streng medan adressa under endrar seg.

Sjekk deretter kva daemonen er bunde til; ein socket fest til den gamle adressa feilar lydlaust. Ein OpenVPN-server starta med local 203.0.113.10 nektar å koma opp når adressa er borte, medan ein lyttar på 0.0.0.0 følgjer endringa gratis. NAT deler seg på same måte: MASQUERADE følgjer kva adresse maskinen no har, og ein statisk SNAT --to-source 203.0.113.10 held fram med å skriva om til ei adresse du ikkje lenger eig, så returtrafikk forsvinn. Viss den nye adressa kjem med ein annan upstream-gateway, sjekk rp_filter: reverse-path-filtrering slepp returtrafikk som kjem inn på eit grensesnitt kjernen ikkje venta.

Rekkjefølgja for overgangen og provet på at han verka

Senk TTL-en ein dag i førevegen, reis den nye lyttaren, og prov han med ein profil berre du har. Ein test frå innsida av same nettverk provar nesten ingenting, så bruk ein telefon på mobilnett og test noko tunnelen skal bera i staden for ein ping til endepunktet.

Følg begge adressene gjennom vindauget. wg show all latest-handshakes på den nye verten, eller OpenVPN-statusfila, fortel kor mange peers som faktisk har flytta. Når det nye endepunktet har peerane du ventar og det gamle berre har etterslengarar, pensjoner den gamle lyttaren, fjern den utdaterte NAT-regelen og ta adressa ut av brannmuren til leverandøren. Å fjerna den gamle lyttaren er trinnet som vert hoppa over, og det lukkar gapet der ein utdatert profil framleis når det gamle nettverket.

Skriv ned rollback-utløysaren før du byrjar: viss det nye endepunktet ikkje har handshake frå éin einaste ekte klient etter det avtalte vindauget, gjenopprett den gamle adressa og slutt å distribuera profilar. Køyr søket på nytt etterpå og stadfest at ingen lyttar framleis er bunde til ei pensjonert adresse. To ting følgjer med til neste flytting: eit vertsnamn i klientprofilen slik at neste endring er ei DNS-redigering, og inventaret som vert oppbevart ved gjenopprettingsnotata til serveren.