Anda mengganti nama antarmuka jaringan, atau memulihkan mesin yang adaptornya kembali dengan nama lain, dan sekarang daemon OpenVPN Access Server tidak mau menyala. Antarmuka web mungkin masih menjawab atau tidak, tergantung komponen mana yang terikat ke nama lama. Layanan tidak rusak dan konfigurasi tidak hilang; satu pengaturan masih menunjuk ke antarmuka yang tidak lagi dimiliki host.

Refleksnya adalah memasang ulang, menginisialisasi ulang, atau menyunting basis data sampai galat hilang. Masing-masing lebih besar daripada kerusakannya, dan yang terakhir dapat menghapus pengguna, izin, dan dependensi yang membuat server layak dipulihkan. Ini masalah binding, dan ada perbaikan yang disebutkan namanya.

Apa yang sebenarnya dikatakan gejala

Daemon yang tidak dapat mengikat biasanya mengatakannya di log sendiri: alamat tidak tersedia atau antarmuka tidak ada. Pesannya spesifik: ia menyebut alamat yang dicoba daemon; bandingkan dengan ip -br addr di host untuk mengetahui apakah antarmuka diganti nama, dihapus, atau dinaikkan tanpa alamat lamanya.

Selalu buka konsol pemulihan resmi selama proses berlangsung. Jika binding yang akan Anda ubah membawa satu-satunya sesi administratif Anda, Anda memutus jalan kembali. Konsol lokal, alamat manajemen kedua, atau jalur luar pita yang terdokumentasi membuat perubahan dapat dibalik.

Kueri konfigurasi sebelum menyuntingnya

Access Server menampilkan konfigurasinya melalui CLI-nya sendiri. Tampilan yang terdokumentasi adalah:

sacli ConfigQuery

Jalankan di lingkungan administratif yang terdokumentasi untuk versi Anda, bukan dari shell tak terkait di host lain. Simpan nilai saat ini di tempat terlindungi sebelum mengubah apa pun, dan jangan menempelkan keluaran lengkap ke utas dukungan publik.

Keluaran itu adalah tampilan konfigurasi server, bukan cadangan lengkap. Properti pengguna dan grup dikueri terpisah, jadi binding yang bersih tidak memulihkan identitas, dan identitas yang dipulihkan tidak memperbaiki listener. Catat keduanya sebagai dua artefak terpisah.

Tentukan listener mana yang rusak

Access Server menjalankan lebih dari satu listener. Daemon OpenVPN membawa lalu lintas tunnel, layanan web membawa portal admin dan klien, dan komponen lain mungkin punya portnya sendiri. Permintaan peramban yang gagal tidak memberi tahu mana yang gagal, begitu pula nomor port dalam pesan galat.

Kunci binding daemon didokumentasikan per daemon, dan dalam tutorial resmi nilainya adalah pengenal antarmuka meskipun nama kunci berakhiran ip_address. Baca kalimat itu dua kali. Tutorial juga mengharapkan daemon UDP dan TCP berbagi satu antarmuka, jadi memperbaiki satu kunci saja adalah perbaikan sebagian.

Ubah pengaturan yang disebutkan, bukan baris yang cocok

Tutorial mendokumentasikan ConfigPut pada kunci tertentu, seperti vpn.daemon.0.server.ip_address dan vpn.daemon.0.listen.ip_address. Gunakan metode produk itu sendiri dengan nama kunci dan nilai baru, dalam sintaksis yang didokumentasikan versi Anda, dan ubah hanya kunci milik listener yang Anda diagnosis.

Yang tidak boleh Anda lakukan adalah mencari di basis data setiap baris yang nilainya sama dengan nama antarmuka lama lalu menggantinya semua. Itu mengasumsikan nama lama hanya muncul di pengaturan listener, yang tidak dijanjikan skema. Itu juga membuat perubahan mustahil ditinjau.

Dua godaan lain layak ditolak. Memulihkan nilai bawaan yang mendengarkan di semua antarmuka adalah keputusan paparan, bukan koreksi ejaan; binding lokal yang dimaksud, jalur yang diterbitkan, dan penyaringan di depannya harus cocok dengan pilihan itu. Menginisialisasi ulang konfigurasi mengganti nama masalah, bukan menyelesaikannya, karena pemasangan baru membuang justru pengguna dan izin yang berfungsi sebelum penggantian nama.

Terapkan, lalu buktikan jalurnya bekerja

Setelah nilai diperbaiki, terapkan melalui siklus hidup produk yang terdokumentasi ( siklus hidup ). Tutorial menggunakan sacli start setelah kunci ditetapkan; itu bukan reboot host penuh atau reset basis data.

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

Periksa listener, lalu buat satu koneksi VPN resmi, capai satu sumber daya privat, dan muat halaman administratif melalui jalur yang diharapkan. Pertahankan izin dan pencabutan yang ada; pemulihan yang mengatur ulang semuanya telah memperbaiki binding dan kehilangan penerapan. Pekerjaan selesai ketika layanan yang sama berjalan pada antarmuka yang dimaksud.

Artikel terkait