Memindahkan server VPN ke IP publik baru: apa yang harus diperiksa lebih dulu

Menetapkan ulang alamat hanya butuh satu menit. Pekan setelahnya adalah tempat perpindahan rusak, dan jarang di tempat yang disarankan konsol penyedia. IP publik baru dirujuk di empat tempat: soket tempat daemon mendengarkan, jangkar kepercayaan yang diverifikasi klien, setiap aturan yang menyebut alamat lama, dan catatan DNS yang mengikatnya. Dua perpindahan terlihat sama dari panel kontrol tetapi berperilaku sangat berbeda: menetapkan ulang alamat pada mesin yang Anda jalankan, atau menyiapkan endpoint kedua dan memindahkan klien ke sana. Pemeriksaan di bawah menempatkan kegagalan murah lebih dulu, dan setiap bagian menyebutkan perpindahan mana yang berlaku.

Penggantian di tempat dan pemotongan paralel adalah pekerjaan berbeda

Penggantian di tempat mempertahankan host, kunci, tabel perutean, dan daftar pengguna; hanya alamatnya yang berubah. Itulah yang dilakukan penetapan ulang IP mengambang, dan pada beberapa penyedia tamu tidak menyadarinya, karena penerjemahan terjadi di depan instans. Membangun ulang atau penetapan ulang oleh penyedia lebih keras: tamu melihat perubahan, dan semua yang menyimpan nilai lama di cache mengetahuinya pada saat yang sama.

Endpoint paralel adalah host kedua yang mengerjakan pekerjaan yang sama. Bangun, uji dengan satu profil, dan biarkan yang lama menjawab sampai yang baru membuktikan diri di jalur nyata. Harganya adalah status. Tanpa entri peer bersama, pencabutan, dan pencatatan log, Anda punya dua jaringan yang kebetulan berbagi nama.

Temukan setiap tempat alamat lama ditulis

Mulai dengan penyisiran teks, karena berkas konfigurasi adalah separuh yang mudah. Cari di konfigurasi daemon, potongan firewall, target pemantauan, dan bundel klien yang dihasilkan di disk. Sertakan alamat IPv6 jika Anda menerbitkannya; perpindahan yang hanya mengikuti catatan A meninggalkan klien dual-stack di jalur 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

Lalu sisir kernel, karena sistem yang berjalan menyimpan alamat di tempat yang tidak disebut berkas mana pun. Aturan NAT sumber statis, entri ipset, alamat bind, dan entri conntrack hidup lebih lama daripada suntingan konfigurasi yang menghapusnya, dan sebagian bertahan melewati reboot karena kembali dari kumpulan aturan tersimpan. Satu lapis di atasnya, grup keamanan penyedia, target penyeimbang beban, dan pemeriksaan pemantauan sama sekali tidak ada di sistem berkas Anda.

Tulis inventaris sebelum mengubah apa pun; itu juga berfungsi sebagai skrip pemulihan.

Klien bernama host pulih; klien IP literal menjadi diam

Jika klien menjangkau server melalui nama host, perpindahan terutama masalah DNS, dan TTL yang Anda tetapkan kemarin menentukan seberapa buruk jadinya. Resolver menyimpan cache, resolver stub menyimpan lagi, dan banyak klien hanya mencari nama pada koneksi baru, jadi terowongan yang sudah terbentuk mempertahankan alamat awalnya.

Jika endpoint berupa alamat literal, tidak ada yang menyelesaikan ulang dan tidak ada yang mencatat keluhan. WireGuard menyimpan alamat soket yang sudah diselesaikan: Endpoint = vpn.example.net:51820 menjadi IP saat wg-quick up dijalankan dan tetap IP itu sampai Anda mengubahnya. OpenVPN lebih pemaaf: ia menyelesaikan nama host remote saat koneksi dan, dengan resolv-retry infinite, mencoba DNS lagi saat menyambung ulang. Dengan IP literal, keduanya terus menghubungi mesin yang sudah tidak ada.

Yang menyesatkan orang adalah bayangan cermin. Klien yang sudah diarahkan ke alamat baru, sementara pendengar lama masih menjawab, lolos setiap uji yang Anda jalankan dari meja sendiri. Saya pernah tertipu: endpoint baru menyala di ponsel dalam sekali coba, dan klien dengan profil usang baru muncul ketika pendengar lama dimatikan jauh kemudian.

Kepercayaan tidak berpindah bersama alamat

WireGuard memisahkan identitas dari keterjangkauan, yang membuat perpindahan alamat hampir gratis. Peer diidentifikasi dengan kunci publik, dan endpoint hanyalah tempat paket pergi sekarang; host memperbarui endpoint peer dari alamat sumber paket terautentikasi terakhir. Peer yang menganggur tetap butuh alasan untuk berbicara dengan tempat baru, dan ia mempelajari alamat hanya ketika sesinya menua dan percobaan ulang handshake gagal di tempat yang terlihat. Panduan cepat WireGuard mencakup bidang endpoint.

Server berbasis TLS adalah kasus sebaliknya. Sertifikat terikat pada nama, dan klien yang menghubungi alamat membandingkan yang dihubungi dengan nama alternatif subjek. Sambungkan lewat IP ke sertifikat yang hanya membawa SAN DNS dan verifikasi gagal: nama yang dipakai klien tidak ada di sertifikat. Menerbitkan ulang dengan SAN IP memperbaiki satu koneksi itu dan membuat perpindahan berikutnya lebih buruk. Menjaga nama host di profil dan membiarkan verify-x509-name di tempatnya membuat pemeriksaan tetap ketat sementara alamat di bawahnya berubah.

Lalu periksa ke apa daemon terikat; soket yang dipatok ke alamat lama gagal tanpa suara. Server OpenVPN yang dimulai dengan local 203.0.113.10 menolak menyala begitu alamat itu hilang, sedangkan pendengar di 0.0.0.0 mengikuti perubahan dengan gratis. NAT terbelah dengan cara yang sama: MASQUERADE mengikuti alamat apa pun yang kini dimiliki mesin, dan SNAT --to-source 203.0.113.10 statis terus menulis ulang ke alamat yang tidak lagi Anda miliki, sehingga lalu lintas balik lenyap. Jika alamat baru datang dengan gateway upstream berbeda, periksa rp_filter: penyaringan jalur balik menjatuhkan lalu lintas balik yang tiba di antarmuka yang tidak diharapkan kernel.

Urutan perpindahan dan bukti bahwa itu berhasil

Turunkan TTL sehari sebelumnya, siapkan pendengar baru, dan buktikan dengan profil yang hanya Anda miliki. Uji dari dalam jaringan yang sama hampir tidak membuktikan apa pun, jadi gunakan ponsel di jaringan seluler dan uji sesuatu yang seharusnya diangkut terowongan, bukan ping ke endpoint.

Pantau kedua alamat sepanjang jendela. wg show all latest-handshakes di host baru, atau berkas status OpenVPN, memberi tahu berapa peer yang benar-benar pindah. Ketika endpoint baru memiliki peer yang Anda harapkan dan yang lama hanya punya yang tertinggal, hentikan pendengar lama, hapus aturan NAT usang, dan keluarkan alamat dari firewall penyedia. Menghapus pendengar lama adalah langkah yang dilewatkan, dan itu menutup celah tempat profil usang masih menjangkau jaringan lama.

Tetapkan pemicu pemulihan secara tertulis sebelum mulai: jika endpoint baru tidak mendapat handshake dari satu pun klien nyata setelah jendela yang disepakati, pulihkan alamat lama dan hentikan distribusi profil. Jalankan penyisiran lagi setelahnya dan pastikan tidak ada pendengar yang masih terikat ke alamat yang sudah dipensiunkan. Dua hal terbawa ke perpindahan berikutnya: nama host di profil klien agar perubahan berikutnya berupa suntingan DNS, dan inventaris yang disimpan di samping catatan pemulihan server.