In VPN-tsjinner nei in nij iepenbier IP ferhúzje: wat earst te kontrolearjen
It ferfangen op itselde plak en in parallelle oerstap brekke op ferskate plakken. Nim konfiguraasjes, NAT en sertifikaten troch, en besjoch dan hoe't elke klient de namme oplost.
It opnij tawizen fan in adres duorret in minút. De wike dêrnei is wêr't de ferhuzing brekt, en selden wêr't de console fan de oanbieder it suggerearret. In nij iepenbier IP wurdt op fjouwer plakken neamd: de socket dêr't de daemon op harket, it fertrouwensanker dat klanten ferifiearje, elke regel dy't it âlde adres neamt, en de DNS-record dy't se byinoar hâldt. Twa ferhuzingen lykje identyk fan in kontrôlepaniel, mar gedrage har folslein oars: it adres opnij tawize op de masine dy't jo bedriuwe, of in twadde endpoint opsette en klanten dêrhinne ferhúzje. De kontrôles hjirûnder sette de goedkeape fouten foarop, en elke seksje neamt foar hokker ferhuzing it jildt.
Ferfanging op itselde plak en parallelle oerstap binne ferskate taken
Ferfanging op itselde plak hâldt de host, de kaaien, de routingtabel en de brûkerslist; allinnich it adres feroaret. Dat docht in opnij tawizing fan in driuwend IP, en by ferskate oanbieders merkt de gast it net, om't de oersetting foar de instance bart. In werbou of opnij tawizing troch de oanbieder is hurder: de gast sjocht de feroaring, en alles wat de âlde wearde yn 't cache hie, leart it op itselde momint.
In parallelle endpoint is in twadde host dy't itselde wurk docht. Bou it, test it mei ien profyl, en lit de âlde antwurdzje oant de nije himsels bewissiget oer in echte rûte. De priis is tastân. Sûnder mienskiplike peer-ynfier, yntrekkingen en logging hawwe jo twa netwurken dy't tafallich in namme diele.
| 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 |
Fyn elk plak dêr't it âlde adres opskreaun is
Begjin mei in tekstsyktocht, want konfiguraasjebestannen binne de maklike helte. Sykje yn 'e daemon-konfiguraasje, firewall-fragminten, monitoringsdoelen en elk generearre kliïntpakket op skiif. Nim it IPv6-adres op as jo der ien publisearje; in ferhuzing dy't allinnich de A-record folget, lit dual-stack-klanten op it âlde paad.
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 endpointsGean dan it kernel troch, want in draaiend systeem hâldt it adres op plakken dy't gjin bestân neamt. In statyske boarne-NAT-regel, in ipset-ynfier, in bind-adres en in conntrack-ynfier oerlibje de konfiguraasjewizing dy't se fuorthelle, en guon oerlibje in werstart om't se weromkamen út in bewarre regelset. Ien laach heger binne feiligensgroepen fan 'e oanbieder, doelen fan 'e loadbalancer en monitoringkontrôles hielendal net op jo bestânssysteem.
Skriuw de ynventarisearring op foardat jo wat feroarje; it tsjinnet ek as weromset-skript.
Hostnamme-klanten herstelle har; literal-IP-klanten wurde stil
As klanten de tsjinner berikke fia hostnamme, is de oerstap foar it meastepart in DNS-probleem, en de TTL dy't jo juster ynsteld hawwe, beslút hoe slim it wurdt. Resolvers cacheje, stub-resolvers cacheje nochris, en in protte klanten sykje de namme allinnich op by in nije ferbining, dat in festige tunnel hâldt syn begjinadres.
As de endpoint in literal adres is, wurdt der neat opnij oplost en logt neat in klacht. WireGuard bewarret in oplost socketadres: Endpoint = vpn.example.net:51820 wurdt in IP op it momint dat wg-quick up rint en bliuwt dat IP oant jo it feroarje. OpenVPN is toleranter: it lost de hostnamme remote op by ferbining en besiket mei resolv-retry infinite wer DNS by werferbining. Mei in literal IP bliuwe beide in masine belje dy't net mear bestiet.
Wat minsken misliedt, is it spegelbyld. In klient dy't al nei it nije adres wiist, wylst de âlde listener noch antwurdet, slagget foar elke test dy't jo fan jo eigen buro dwaan. Ik bin der sels troch mislaat: de nije endpoint kaam op in telefoan by de earste poging omheech, en in klient mei in ferâldere profyl kaam pas oan it ljocht doe't de âlde listener folle letter útskeakele waard.
Fertrouwen ferhúzet net mei it adres
WireGuard skiedt identiteit fan berikberens, wat in adresferhuzing hast fergees makket. Peers wurde identifisearre mei in iepenbiere kaai, en de endpoint is allinnich wêr't pakketten op it stuit hinne geane; in host fernijt de endpoint fan in peer út it boarneadres fan it lêste autentisearre pakket. In idle peer hat noch altyd in reden nedich om mei it nije plak te praten, en it leart it adres pas as syn sesje ferrint en de handshake-pogingen op in sichtber plak mislearje. De flugge start fan WireGuard behannelet it endpoint-fjild.
TLS-basearre tsjinners binne it tsjinoerstelde gefal. It sertifikaat is bûn oan in namme, en in klient dy't in adres kiest, fergeliket wat er keas mei de alternative nammen fan it ûnderwerp. Ferbyn mei IP mei in sertifikaat dat allinnich in DNS-SAN draacht, en de ferifikaasje mislearret: de namme dy't de klient brûkte, stiet net yn it sertifikaat. Opnij útjaan mei in IP-SAN reparearret dy iene ferbining en makket de folgjende ferhuzing slimmer. In hostnamme yn it profyl hâlde en verify-x509-name stean litte hâldt de kontrôle strang wylst it adres dêrûnder feroaret.
Kontrolearje dan wêr't de daemon oan bûn is; in socket dy't oan it âlde adres fêstset is, mislearret stil. In OpenVPN-tsjinner start mei local 203.0.113.10 wegeret omheech te kommen as dat adres fuort is, wylst in listener op 0.0.0.0 de feroaring fergees folget. NAT splitst itselde: MASQUERADE folget hokker adres de masine no hat, en in statyske SNAT --to-source 203.0.113.10 bliuwt wer skriuwen nei in adres dat jo net mear hawwe, dat weromferkear ferdwynt. As it nije adres mei in oare upstream-gateway komt, kontrolearje rp_filter: reverse-path-filtern smyt weromferkear fuort dat oankomt op in ynterface dat it kernel net ferwachte.
Oerstapfolchoarder en it bewiis dat it wurke
Ferleegje de TTL in dei fan tefoaren, set de nije listener oerein, en bewissigje it mei in profyl dat allinnich jo hawwe. In test fan binnen itselde netwurk bewissiget hast neat, dus brûk in telefoan op mobyl netwurk en test eat dat de tunnel ferfiere moat, ynstee fan in ping nei de endpoint.
Hâld beide adressen yn it each troch it finster. wg show all latest-handshakes op de nije host, of it OpenVPN-statusbestân, fertelt hoefolle peers wier ferhuze binne. As de nije endpoint de peers hat dy't jo ferwachtsje en de âlde allinnich efterbliuwers, set de âlde listener út, ferwiderje de ferâldere NAT-regel en helje it adres út 'e firewall fan 'e oanbieder. It fuortheljen fan 'e âlde listener is de stap dy't oerslein wurdt, en it slút it gat dêr't in ferâldere profyl noch it âlde netwurk berikt.
Skriuw de weromset-trigger foarôf op: as de nije endpoint nei it ôfsprutsen finster gjin handshake hat fan ien echte klient, set it âlde adres werom en stopje mei it fersprieden fan profilen. Rin de syktocht dêrnei wer en befêstigje dat gjin listener noch oan in ôftanke adres bûn is. Twa dingen geane mei nei de folgjende ferhuzing: in hostnamme yn it kliïntprofyl sadat de folgjende feroaring in DNS-bewurking is, en de ynventarisearring dy't njonken de herstelnotysjes fan 'e tsjinner bewarre wurdt.