VPN zerbitzaria IP publiko berri batera mugitzea: zer egiaztatu lehenengo
Lekukoa ordezkatzeak eta paraleloko mozketak leku desberdinetan hausten dira. Berrikusi konfigurazioak, NATa eta ziurtagiriak, eta gero egiaztatu nola ebazten duen izena bezero bakoitzak.
Helbide bat berriz esleitzeak minutu bat behar du. Hurrengo astea da mugiketa hausten den tokia, eta gutxitan hornitzailearen kontsolak iradokitzen duen tokian. IP publiko berria lau tokitan aipatzen da: daemonak entzuten duen socket-ean, bezeroek egiaztatzen duten konfiantza-ankeran, helbide zaharra izendatzen duen arau bakoitzean eta haiek lotzen dituen DNS erregistroan. Bi mugikek berdin dirudite kontrol-panel batetik, baina erabat desberdin jokatzen dute: helbidea zuk gidatzen duzun makinan berriz esleitzea, edo bigarren endpoint bat altxatzea eta bezeroak hara mugitzea. Azpiko egiaztapenek hutsegite merkeak jartzen dituzte lehenengo, eta atal bakoitzak zein mugikketari dagokion adierazten du.
Lekukoa ordezkatzea eta paraleloko mozketa lan desberdinak dira
Lekukoa ordezkatzeak ostalaria, gakoak, bideratze-taula eta erabiltzaile-zerrenda mantentzen ditu; helbidea soilik aldatzen da. Hori egiten du IP flotatzaile baten berresleipenak, eta hainbat hornitzailerekin ostalariak ez du ezer nabaritzen, itzulpena instantziaren aurrean gertatzen delako. Birsorkuntza batek edo hornitzailearen berresleipenak gogorrago jokatzen du: ostalariak aldaketa ikusten du, eta balio zaharra cachean zuen guztiak une berean ikasten du.
Endpoint paralelo bat lan bera egiten duen bigarren ostalari bat da. Eraiki, probatu profil batekin, eta utzi zaharrak erantzuten berriak bide erreal batean bere burua frogatu arte. Prezioa egoera da. Peer erregistro, ezeztatze eta erregistratze partekaturik gabe, izena kasualitatez partekatzen duten bi sare dituzu.
| 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 |
Aurkitu helbide zaharra idatzita dagoen toki bakoitza
Hasi testu-araketa batekin, konfigurazio-fitxategiak erdia erraza direlako. Bilatu daemonaren konfigurazioan, suebaki-zatietan, monitorizazio-helburuetan eta diskoan sortutako edozein bezero-paketetan. Sartu IPv6 helbidea argitaratzen baduzu; A erregistroa soilik jarraitzen duen mugiketa batek pila bikoitzeko bezeroak bide zaharrean uzten ditu.
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 endpointsGero arakatu kernela, martxan dagoen sistema batek helbidea inolako fitxategik aipatzen ez dituen tokietan gordetzen duelako. NAT iturri arau estatiko batek, ipset sarrera batek, bind helbide batek eta conntrack sarrera batek kendu zituzten konfigurazio-aldaketak baino gehiago irauten dute, eta batzuek berrabiaraztea ere gainditzen dute gordetako arau-multzo batetik itzuli zirelako. Maila bat gorago, hornitzailearen segurtasun-taldeak, karga-balantzagailuaren helburuak eta monitorizazio-egiaztapenak ez dira zure fitxategi-sisteman ere.
Idatzi inbentarioa ezer aldatu aurretik; atzeratzeko script gisa ere balio du.
Host-izena duten bezeroak suspertu egiten dira; IP literaleko bezeroak isildu egiten dira
Bezeroak ostalari-izenaren bidez iristen badira zerbitzarira, mozketa batez ere DNS arazoa da, eta atzo ezarri zenuen TTLak erabakitzen du zein txarra izango den. Ebazleek cachean gordetzen dute, stub ebazleek berriro cachean, eta bezero askok konexio berri batean soilik bilatzen dute izena, beraz ezarritako tunel batek hasierako helbidea mantentzen du.
Endpoint-a helbide literala bada, ezer ez da berriro ebazten eta ezerk ez du kexarik erregistratzen. WireGuardek socket helbide ebatzita gordetzen du: Endpoint = vpn.example.net:51820 IP bihurtzen da wg-quick up exekutatzen den unean, eta IP hori mantentzen da aldatzen duzun arte. OpenVPN toleranteagoa da: remote ostalari-izena konexio unean ebazten du eta, resolv-retry infinite erabiliz, DNS berriro saiatzen du berrkonektatzean. IP literala emanda, biek existitzen ez den makina bat deitzen jarraitzen dute.
Jendea engainatzen duena ispilu-irudia da. Helbide berrira jada zuzenduta dagoen bezero batek, entzule zaharrak oraindik erantzuten duen bitartean, zure mahaitik egiten duzun proba guztiak gainditzen ditu. Nik horrekin engainatu ninduten: endpoint berria telefono batean lehen saiakeran altxatu zen, eta profil zaharra zuen bezero bat entzule zaharra askoz geroago itzali zenean agertu zen soilik.
Konfiantza ez da helbidearekin mugitzen
WireGuardek identitatea irisgarritasunetik bereizten du, eta horrek helbide-mugiketa ia doakoa egiten du. Peer-ak gako publikoaren bidez identifikatzen dira, eta endpoint-a paketeak oraintxe doazen tokia baino ez da; ostalari batek peer baten endpoint-a eguneratzen du autentifikatutako azken paketearen iturburu-helbidetik. Peer inaktibo batek oraindik arrazoi bat behar du toki berriarekin hitz egiteko, eta helbidea bere saioa zahartzen denean eta handshake berriro-saiakerak toki ikusgarriren batean huts egiten dutenean ikasten du. WireGuarden abio azkarrak endpoint eremua lantzen du.
TLSan oinarritutako zerbitzariak kontrako kasua dira. Ziurtagiria izen bati lotuta dago, eta helbide bat markatzen duen bezeroak markatu duena subjektuaren izen alternatiboekin alderatzen du. Konektatu IPz DNS SAN bat soilik daraman ziurtagiri batera eta egiaztapenak huts egiten du: bezeroak erabili duen izena ez dago ziurtagirian. IP SAN batekin berrargitaratzeak konexio hori konpontzen du eta hurrengo mugiketa okerragoa egiten du. Profilan ostalari-izen bat mantentzeak eta verify-x509-name bere tokian uzteak egiaztapena zorrotz mantentzen du helbidea azpian aldatzen den bitartean.
Gero egiaztatu zeri lotuta dagoen daemona; helbide zaharrean finkatutako socket batek isil-isilik huts egiten du. local 203.0.113.10 rekin abiatutako OpenVPN zerbitzari batek ez du altxatu nahi izaten helbide hori desagertzen denean, 0.0.0.0 en dagoen entzule batek aldaketa doan jarraitzen duen bitartean. NATak modu berean banatzen da: MASQUERADE makina orain duen helbideari jarraitzen dio, eta SNAT --to-source 203.0.113.10 estatiko batek jada ez duzun helbide batera berridazten jarraitzen du, beraz itzulerako trafikoa desagertzen da. Helbide berria upstream ate ezberdin batekin badator, egiaztatu rp_filter: bide alderantzizko iragazketak kernelak espero ez zuen interfaze batean iristen den itzulerako trafikoa botatzen du.
Mozketaren ordena eta funtzionatu duen froga
Jaitsi TTL-a egun bat lehenago, altxatu entzule berria, eta frogatu zu bakarrik duzun profil batekin. Sare bereko barrutik egindako probak ia ezer ez du frogatzen, beraz erabili telefono bat mugikor-sarean eta probatu tuneletik garraiatu behar duen zerbait, endpoint-era ping bat egin beharrean.
Begiratu bi helbideak leiho osoan zehar. wg show all latest-handshakes ostalari berrian, edo OpenVPN egoera-fitxategiak, zenbat peer mugitu diren esaten dizu. Endpoint berriak espero dituzun peer-ak dituenean eta zaharrak atzeratuak soilik, erretiratu entzule zaharra, kendu NAT arau zaharkitua eta atera helbidea hornitzailearen suebakitik. Entzule zaharra kentzea da gainean pasatzen den urratsa, eta profil zaharkitu batek oraindik sare zaharrean sartzen den hutsunea ixten du.
Idatzi atzeratze-abiarazlea hasteko: akordiozko leihoaren ondoren endpoint berriak benetako bezero bakar batetik handshake-rik ez badu, berrezarri helbide zaharra eta utzi profilak banatzeari. Exekutatu araketa berriro ondoren eta baieztatu entzulerik ez dagoela erretiratutako helbide bati lotuta. Bi gauza pasatzen dira hurrengo mugiketera: bezeroaren profilean ostalari-izen bat, hurrengo aldaketa DNS edizioa izan dadin, eta zerbitzariaren berreskuratze-oharren ondoan gordetako inbentarioa.