Mutarea unui server VPN pe un IP public nou: ce trebuie verificat mai întâi

Reatribuirea unei adrese durează un minut. Săptămâna următoare este locul unde mutarea se strică, și rareori acolo unde sugerează consola furnizorului. Un IP public nou este referit în patru locuri: socketul pe care ascultă daemonul, ancora de încredere pe care o verifică clienții, fiecare regulă care numește adresa veche și înregistrarea DNS care le leagă. Două mutări arată identic într-un panou de control dar se comportă complet diferit: reatribuirea adresei pe mașina pe care o administrați, sau ridicarea unui al doilea endpoint și mutarea clienților pe el. Verificările de mai jos pun primele defecțiunile ieftine, iar fiecare secțiune spune la ce mutare se aplică.

Înlocuirea la fața locului și comutarea paralelă sunt lucrări diferite

Înlocuirea la fața locului păstrează gazda, cheile, tabela de rutare și lista de utilizatori; se schimbă doar adresa. Asta face o reatribuire de IP flotant, iar la mai mulți furnizori oaspetele nu observă nimic, pentru că traducerea are loc în fața instanței. O reconstrucție sau o reatribuire de la furnizor este mai dură: oaspetele vede schimbarea, iar tot ce a ținut valoarea veche în cache află despre ea în același moment.

Un endpoint paralel este o a doua gazdă care face aceeași muncă. Construiți-l, testați-l cu un profil și lăsați-l pe cel vechi să răspundă până când cel nou se dovedește pe o cale reală. Prețul este starea. Fără intrări peer comune, revocări și jurnalizare, aveți două rețele care împart din întâmplare un nume.

Găsiți fiecare loc unde este scrisă adresa veche

Începeți cu o căutare text, pentru că fișierele de configurare sunt jumătatea ușoară. Căutați în configurația daemonului, în fragmentele de firewall, în țintele de monitorizare și în orice pachet de client generat pe disc. Includeți adresa IPv6 dacă publicați una; o mutare care urmează doar înregistrarea A lasă clienții cu stivă dublă pe calea veche.

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

Apoi parcurgeți nucleul, pentru că un sistem în funcțiune ține adresa în locuri pe care niciun fișier nu le menționează. O regulă NAT de sursă statică, o intrare ipset, o adresă bind și o intrare conntrack supraviețuiesc modificării de configurare care le-a eliminat, iar unele supraviețuiesc și unei reporniri pentru că au revenit dintr-un set de reguli salvat. Un nivel mai sus, grupurile de securitate ale furnizorului, țintele balansatorului de încărcare și verificările de monitorizare nu sunt deloc pe sistemul dumneavoastră de fișiere.

Scrieți inventarul înainte de a schimba ceva; servește și ca script de revenire.

Clienții cu nume de gazdă se refac; clienții cu IP literal amuțesc

Dacă clienții ajung la server prin nume de gazdă, comutarea este în principal o problemă DNS, iar TTL-ul setat ieri decide cât de rău va fi. Resolverele cache-uiesc, resolverele stub cache-uiesc din nou, și mulți clienți caută numele doar la o conexiune nouă, așa că un tunel stabilit își păstrează adresa de start.

Dacă endpointul este o adresă literală, nimic nu se rezolvă din nou și nimic nu înregistrează o plângere. WireGuard stochează o adresă de socket rezolvată: Endpoint = vpn.example.net:51820 devine IP în momentul în care rulează wg-quick up și rămâne acel IP până îl schimbați. OpenVPN este mai îngăduitor: rezolvă numele de gazdă remote la conectare și, cu resolv-retry infinite, încearcă din nou DNS la reconectare. Cu un IP literal, ambele continuă să sune o mașină care nu mai există.

Ce îi păcălește pe oameni este imaginea în oglindă. Un client deja îndreptat spre adresa nouă, în timp ce vechiul ascultător încă răspunde, trece fiecare test pe care îl faceți de la biroul dumneavoastră. Am fost și eu păcălit: noul endpoint a pornit pe un telefon din prima încercare, iar un client cu profil învechit a apărut abia când vechiul ascultător a fost oprit mult mai târziu.

Încrederea nu se mută cu adresa

WireGuard separă identitatea de accesibilitate, ceea ce face mutarea adresei aproape gratuită. Peerii sunt identificați prin cheie publică, iar endpointul este doar locul unde merg pachetele acum; o gazdă actualizează endpointul unui peer din adresa sursă a ultimului pachet autentificat. Un peer inactiv are totuși nevoie de un motiv să vorbească cu locul nou, și învață adresa doar când sesiunea îi îmbătrânește și reîncercările de handshake eșuează într-un loc vizibil. Ghidul rapid WireGuard acoperă câmpul endpoint.

Servere bazate pe TLS sunt cazul opus. Certificatul este legat de un nume, iar un client care formează o adresă compară ce a format cu numele alternative ale subiectului. Conectați-vă prin IP la un certificat care poartă doar un SAN DNS și verificarea eșuează: numele folosit de client nu este în certificat. Reemiterea cu un SAN IP repară acea conexiune și înrăutățește următoarea mutare. Păstrarea unui nume de gazdă în profil și lăsarea verify-x509-name la locul lui menține verificarea strictă în timp ce adresa de dedesubt se schimbă.

Apoi verificați de ce este legat daemonul; un socket fixat pe adresa veche eșuează în tăcere. Un server OpenVPN pornit cu local 203.0.113.10 refuză să pornească odată ce adresa dispare, în timp ce un ascultător pe 0.0.0.0 urmează schimbarea gratis. NAT se împarte la fel: MASQUERADE urmează orice adresă are mașina acum, iar un SNAT --to-source 203.0.113.10 static rescrie în continuare către o adresă pe care nu o mai dețineți, așa că traficul de retur dispare. Dacă adresa nouă vine cu alt gateway upstream, verificați rp_filter: filtrarea pe cale inversă aruncă traficul de retur care sosește pe o interfață la care nucleul nu se aștepta.

Ordinea comutării și dovezile că a funcționat

Coborâți TTL-ul cu o zi înainte, ridicați noul ascultător și dovediți-l cu un profil pe care îl aveți doar dumneavoastră. Un test din interiorul aceleiași rețele nu dovedește aproape nimic, așa că folosiți un telefon pe rețea mobilă și testați ceva ce tunelul trebuie să transporte, nu un ping către endpoint.

Urmăriți ambele adrese pe toată fereastra. wg show all latest-handshakes pe gazda nouă, sau fișierul de stare OpenVPN, vă spune câți peeri s-au mutat efectiv. Când noul endpoint are peerii așteptați și cel vechi doar întârziați, retrageți ascultătorul vechi, eliminați regula NAT învechită și scoateți adresa din firewall-ul furnizorului. Eliminarea ascultătorului vechi este pasul care se sare, și închide golul în care un profil învechit ajunge încă în rețeaua veche.

Stabiliți în scris declanșatorul de revenire înainte de a începe: dacă noul endpoint nu are handshake de la niciun client real după fereastra convenită, restabiliți adresa veche și opriți distribuirea profilelor. Rulați din nou căutarea și confirmați că niciun ascultător nu mai este legat de o adresă retrasă. Două lucruri trec la următoarea mutare: un nume de gazdă în profilul clientului pentru ca următoarea schimbare să fie o editare DNS, și inventarul păstrat lângă notele de recuperare ale serverului.