Apakah Anda mengira mengganti nama server Pritunl mengubah endpoint-nya?
Mengganti nama server Pritunl mengubah label, bukan endpoint yang dihubungi klien. Atur Alamat Publik host, lalu kirim namanya ke profil yang sudah ada.
Mengganti nama server Pritunl mengubah label di konsol. Itu tidak mengubah alamat yang dihubungi profil klien, dan tidak membuat catatan DNS. Nilai yang penting adalah Alamat Publik host, dan itu menerima nama sama mudahnya seperti alamat.
Nama yang dihubungi klien hidup di satu bidang host
Pritunl mengekspos endpoint melalui pengaturan Alamat Publik host, yang menerima alamat IP publik atau nama DNS. Letakkan vpn.example.net di sana, dan profil yang dihasilkan serta sinkronisasi terautentikasi akan menyerahkan nama itu kepada klien. Catatan itu harus sudah ada dan mengarah ke listener yang menerima transport VPN; bidang itu mengumumkan tujuan, bukan menerbitkannya. Nama tampilan objek server adalah metadata administratif dan tidak pernah mencapai upaya koneksi klien.
Jadi langkah pertama bukan mengganti nama apa pun. Buka pengaturan host, ubah Alamat Publik, dan simpan melalui antarmuka yang didukung.
Tiga bidang yang tampak serupa dan tidak
Alamat Lokal melayani replikasi dan perutean antar host Pritunl. Alamat Tautan menjelaskan bagaimana server yang tertaut saling menjangkau. Keduanya bukan alamat yang dihubungi klien, dan menyalin nama publik ke dalamnya merusak topologi yang dijelaskannya. Alamat IPv6 Publik adalah bidang terpisah dengan catatan dan jalurnya sendiri; catatan A untuk IPv4 tidak membangun keterjangkauan IPv6.
Nama DNS juga tidak membawa pemetaan port maupun listener. Jika layanan mendengarkan pada 1194 UDP, nama itu tetap mengarah ke host yang harus menerima 1194 UDP. Proxy terbalik HTTP pada port 443 yang melayani konsol web bukan endpoint transport VPN, bahkan ketika keduanya berbagi nama yang sama.
Perutean berbasis domain di dalam tunnel adalah lapisan lain lagi. Penamaan endpoint luar tidak mengatakan apa pun tentang tujuan privat mana yang dapat dijangkau klien.
Kirim nama baru ke klien yang sudah ada
Mengubah bidang itu tidak menulis ulang profil yang sudah meninggalkan server. Sinkronisasi konfigurasi terautentikasi Pritunl dapat mengirimkan perubahan alamat dan port host ke klien yang kompatibel, dan klien CLI yang didokumentasikan menyinkronkan sebelum terhubung atau terhubung kembali. Profil yang diimpor ke NetworkManager atau klien OpenVPN mandiri tidak memiliki saluran semacam itu dan memerlukan penggantian yang disetujui. Sesi yang ada tidak membuktikan apa pun, karena sesi itu dibangun terhadap nilai lama.
Ketika konsol web berada di belakang penyeimbang beban, Pritunl mendokumentasikan pengaturan terpisah Alamat Sinkronisasi untuk jalur sinkronisasi. Jangan menggunakan ulang nama host konsol untuk listener VPN hanya karena keduanya Pritunl.
Kirimkan perubahan dalam urutan ini: simpan pengaturan host, ekspor atau sinkronkan profil saat ini, ganti salinan klien, lalu hubungkan kembali. Catat klien mana yang dikelola oleh sinkronisasi dan mana yang menyimpan berkas impor, karena kelompok kedua tidak akan mengikuti secara otomatis. Daftar kepemilikan klien lebih berguna di sini daripada catatan DNS lain.
Terima perubahan dengan koneksi sungguhan
Resolusi adalah uji terlemah yang mungkin. dig +short vpn.example.net yang mengembalikan alamat hanya membuktikan bahwa catatan itu ada.
Uji penerimaan adalah koneksi terautentikasi baru dari klien yang memegang profil baru, diikuti permintaan ke sumber daya privat yang seharusnya dapat dijangkau melalui tunnel. Periksa di log klien endpoint yang benar-benar digunakan, bukan yang Anda maksudkan. Pertahankan jalur manajemen yang tidak bergantung pada nama yang diubah dengan benar, agar kesalahan tidak dapat mengunci Anda dari konsol.
Nanti, ketika alamat publik berpindah, perbarui catatan dan rencanakan cache klien serta perilaku penyambungan ulang. Nama host memisahkan klien dari alamat numerik; itu tidak memindahkan soket aktif atau membuat listener yang tak terjangkau menjawab.