Menetapkan semula alamat mengambil masa seminit. Minggu berikutnya ialah tempat pemindahan rosak, dan jarang di tempat yang dicadangkan konsol pembekal. IP awam baharu dirujuk di empat tempat: soket tempat daemon mendengar, sauh kepercayaan yang disahkan klien, setiap peraturan yang menamakan alamat lama, dan rekod DNS yang mengikatnya. Dua pemindahan kelihatan serupa dari panel kawalan tetapi berkelakuan sangat berbeza: menetapkan semula alamat pada mesin yang anda kendalikan, atau mendirikan endpoint kedua dan memindahkan klien ke sana. Pemeriksaan di bawah meletakkan kegagalan murah dahulu, dan setiap bahagian menyatakan pemindahan mana yang terpakai.

Penggantian di tempat dan pemotongan selari ialah kerja berbeza

Penggantian di tempat mengekalkan hos, kunci, jadual penghalaan dan senarai pengguna; hanya alamat berubah. Itulah yang dilakukan penetapan semula IP terapung, dan pada beberapa pembekal tetamu tidak menyedarinya, kerana terjemahan berlaku di hadapan instans. Pembinaan semula atau penetapan semula oleh pembekal lebih keras: tetamu melihat perubahan, dan semua yang menyimpan nilai lama dalam cache mengetahuinya pada saat yang sama.

Endpoint selari ialah hos kedua yang melakukan kerja yang sama. Binanya, ujinya dengan satu profil, dan biarkan yang lama menjawab sehingga yang baharu membuktikan dirinya di laluan sebenar. Harganya ialah keadaan. Tanpa entri peer dikongsi, pembatalan dan pengelogan, anda mempunyai dua rangkaian yang kebetulan berkongsi nama.

QuestionIn-place swapParallel endpoint
Rollback in one step?Only if you can get the old address backPoint DNS back; old host still up
Blast radiusEvery client at onceOnly the clients you moved
Best whenThe address is yours to reassignThe old address is gone for good

Cari setiap tempat alamat lama ditulis

Mulakan dengan sapuan teks, kerana fail konfigurasi ialah separuh yang mudah. Cari dalam konfigurasi daemon, serpihan firewall, sasaran pemantauan dan mana-mana bundel klien yang dijana pada cakera. Sertakan alamat IPv6 jika anda menerbitkannya; pemindahan yang hanya mengikut rekod A meninggalkan klien dwi-stack di laluan lama.

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

Kemudian sapu kernel, kerana sistem yang berjalan menyimpan alamat di tempat yang tiada fail menyebutnya. Peraturan NAT sumber statik, entri ipset, alamat bind dan entri conntrack hidup lebih lama daripada suntingan konfigurasi yang mengalihkannya, dan sesetengahnya bertahan melepasi but semula kerana kembali daripada set peraturan tersimpan. Satu lapisan di atas, kumpulan keselamatan pembekal, sasaran pengimbang beban dan pemeriksaan pemantauan sama sekali tiada pada sistem fail anda.

Tulis inventori sebelum mengubah apa-apa; ia juga berfungsi sebagai skrip pengunduran.

Klien nama hos pulih; klien IP literal menjadi senyap

Jika klien mencapai pelayan melalui nama hos, pemotongan itu kebanyakannya masalah DNS, dan TTL yang anda tetapkan semalam menentukan betapa buruknya. Penyelesai menyimpan cache, penyelesai stub menyimpan lagi, dan banyak klien hanya mencari nama pada sambungan baharu, jadi terowong yang telah terbentuk mengekalkan alamat permulaannya.

Jika endpoint ialah alamat literal, tiada apa diselesaikan semula dan tiada apa merekodkan aduan. WireGuard menyimpan alamat soket yang telah diselesaikan: Endpoint = vpn.example.net:51820 menjadi IP pada saat wg-quick up berjalan dan kekal sebagai IP itu sehingga anda mengubahnya. OpenVPN lebih bertolak ansur: ia menyelesaikan nama hos remote semasa sambungan dan, dengan resolv-retry infinite, mencuba DNS semula semasa sambung semula. Dengan IP literal, kedua-duanya terus mendail mesin yang tidak lagi wujud.

Yang mengelirukan orang ialah bayangan cermin. Klien yang sudah menuju alamat baharu, sementara pendengar lama masih menjawab, lulus setiap ujian yang anda jalankan dari meja anda sendiri. Saya juga tertipu: endpoint baharu naik pada telefon dalam satu percubaan, dan klien dengan profil lama hanya muncul apabila pendengar lama dimatikan jauh kemudian.

Kepercayaan tidak berpindah bersama alamat

WireGuard memisahkan identiti daripada kebolehcapaian, yang menjadikan pemindahan alamat hampir percuma. Peer dikenal pasti dengan kunci awam, dan endpoint hanyalah tempat paket pergi sekarang; hos mengemas kini endpoint peer daripada alamat sumber paket terakhir yang disahkan. Peer yang menganggur masih perlukan sebab untuk bercakap dengan tempat baharu, dan ia mempelajari alamat hanya apabila sesinya menjadi tua dan cubaan semula handshake gagal di tempat yang kelihatan. Panduan pantas WireGuard merangkumi medan endpoint.

Pelayan berasaskan TLS ialah kes sebaliknya. Sijil terikat pada nama, dan klien yang mendail alamat membandingkan apa yang didail dengan nama alternatif subjek. Sambung melalui IP ke sijil yang hanya membawa SAN DNS dan pengesahan gagal: nama yang digunakan klien tiada dalam sijil. Mengeluarkan semula dengan SAN IP membaiki satu sambungan itu dan menjadikan pemindahan seterusnya lebih buruk. Mengekalkan nama hos dalam profil dan membiarkan verify-x509-name di tempatnya mengekalkan pemeriksaan yang ketat sementara alamat di bawahnya berubah.

Kemudian periksa apa daemon terikat; soket yang dipaku pada alamat lama gagal tanpa bunyi. Pelayan OpenVPN yang dimulakan dengan local 203.0.113.10 enggan naik sebaik alamat itu hilang, manakala pendengar pada 0.0.0.0 mengikut perubahan secara percuma. NAT berpecah dengan cara yang sama: MASQUERADE mengikut apa jua alamat yang mesin ada sekarang, dan SNAT --to-source 203.0.113.10 statik terus menulis semula ke alamat yang anda tidak miliki lagi, jadi trafik balik lenyap. Jika alamat baharu datang dengan gateway upstream berbeza, periksa rp_filter: penapisan laluan songsang menggugurkan trafik balik yang tiba pada antara muka yang kernel tidak jangkakan.

Urutan pemotongan dan bukti bahawa ia berjaya

Turunkan TTL sehari lebih awal, dirikan pendengar baharu, dan buktikannya dengan profil yang hanya anda miliki. Ujian dari dalam rangkaian yang sama hampir tidak membuktikan apa-apa, jadi gunakan telefon pada selular dan uji sesuatu yang sepatutnya dibawa terowong, bukan ping ke endpoint.

Pantau kedua-dua alamat sepanjang tetingkap. wg show all latest-handshakes pada hos baharu, atau fail status OpenVPN, memberitahu berapa peer yang benar-benar berpindah. Apabila endpoint baharu mempunyai peer yang anda jangkakan dan yang lama hanya mempunyai yang tertinggal, bersarakan pendengar lama, buang peraturan NAT lama dan keluarkan alamat daripada firewall pembekal. Membuang pendengar lama ialah langkah yang sering dilangkau, dan ia menutup jurang tempat profil lama masih mencapai rangkaian lama.

Tetapkan pencetus pengunduran secara bertulis sebelum bermula: jika endpoint baharu tidak mendapat handshake daripada seorang pun klien sebenar selepas tetingkap yang dipersetujui, pulihkan alamat lama dan hentikan pengedaran profil. Jalankan sapuan semula selepas itu dan sahkan tiada pendengar masih terikat pada alamat yang bersara. Dua perkara dibawa ke pemindahan seterusnya: nama hos dalam profil klien supaya perubahan berikutnya ialah suntingan DNS, dan inventori yang disimpan di sebelah nota pemulihan pelayan.

Artikel berkaitan