OpenVPN tidak mau start: baca baris pertama, bukan konfigurasinya

VPN yang mati pada detik pertama adalah hewan yang berbeda dari VPN yang tersambung lalu gagal, dan kesalahan umum adalah memperlakukan keduanya sebagai hal yang sama. Di sini tidak ada handshake, tidak ada pertukaran sertifikat, dan tidak ada rute untuk diperiksa. Satu baris di jurnal menentukan perbaikan mana dari beberapa perbaikan yang tidak saling terkait yang berlaku, dan melewatinya menghabiskan satu sore untuk menyunting konfigurasi yang tidak pernah dibaca. Baca baris itu lebih dulu.

Tiga perintah hanya-baca membawa Anda ke sana: journalctl -u openvpn@server -b --no-pager dulu, lalu systemctl status openvpn@server, dan ss -lunp untuk pendengar UDP beserta pemiliknya.

Baris pertama yang memilih cabang

Konflik port dan biner yang hilang sama-sama mematikan start dalam satu detik, dan keduanya meninggalkan baris pertama yang berbeda. Pesan alamat sudah dipakai menyebut portnya; biner yang hilang menyebut jalur yang sudah tidak ada; kondisi yang gagal atau berkas konfigurasi yang tidak ada menyebut berkasnya. Ketiganya mengarah ke perbaikan yang berbeda, dan tidak satu pun membaik dengan memasang ulang klien. Salin kegagalan pertama ke catatan Anda sebelum menjalankan apa pun lagi.

Perhatikan lingkaran percobaan ulang yang menyembunyikan baris aslinya. Unit dengan kebijakan restart bisa mengubur kegagalan pertama di bawah selusin kegagalan identik, jadi journalctl -b yang disaring menurut unit dan dibaca dari atas mengalahkan ekornya.

Siapa lagi yang memegang port 1194

Pelakunya biasanya bukan server kedua yang sengaja dipasang seseorang. Perkirakan klien yang dijalankan manual dan masih hidup di terminal lain, profil kedua yang kebetulan memilih port yang sama, atau bundel vendor yang tunnelnya sendiri memegang 1194. Pemilik soket muncul di ss -lunp; berikan PID itu ke systemctl status untuk mengetahui apakah ada unit yang bertanggung jawab. Matikan lewat jalur kendalinya sendiri, bukan dengan sinyal.

Sinyal ke proses yang dikelola unit biasanya memicu restart, dan kegagalan yang sama muncul lagi beberapa saat kemudian seperti masalah baru. Gunakan systemctl stop untuk unit, perintah layanan milik bundel untuk pemasangan vendor, dan sinyal hanya untuk sesuatu yang Anda jalankan sendiri di shell itu.

Unit yang tersisa setelah pembersihan

Pembersihan menghapus biner; berkas unit yang ditulis tangan, biasanya di /etc/systemd/system, tetap bertahan. Systemd lalu mencoba lagi unit yang menunjuk jalur yang sudah tidak ada, dan pesannya menyangkut berkas yang hilang itu, bukan penghapusan kemarin. systemctl status menampilkan jalur fragmen unit di bagian atas, jadi periksa dengan dpkg -S sebelum menghapus apa pun. Setelah yatim itu hilang, systemctl daemon-reload dan systemctl reset-failed membersihkan keadaannya; kalau tidak, setiap pemeriksaan status berikutnya mewarisinya.

Ketika which openvpn menjawab dengan sesuatu di bawah /usr/local, biner yang dipakai berasal dari pemasang vendor, bukan dari apt. Pemasang semacam itu biasanya membawa pendengar sendiri, entri boot sendiri, dan direktori konfigurasi sendiri, sehingga menghapus perintah yang terlihat tetap membuat soket terpakai.

Copot pemasangannya sesuai yang didokumentasikan vendor, pastikan port bebas dengan ss -lunp, dan tambahkan klien distribusi hanya jika Anda membutuhkannya.

Rapikan keadaan sebelum mencoba lagi

Bersihkan keadaan gagal sebelum menarik kesimpulan darinya: systemctl reset-failed menghapus penghitungnya, dan systemctl status kemudian melaporkan kondisi unit saat ini, bukan riwayatnya. Jalankan sekali dan baca jurnal dari jalannya itu, bukan keadaan agregat mesin. Unit yang melaporkan aktif sementara tunnel tidak mengangkut apa pun adalah masalah terpisah, dan jauh lebih umum. Keduanya menyatu dalam laporan bug karena keduanya berakhir dengan pengguna mengatakan VPN tidak bekerja.

Catat cabang yang Anda ambil: konflik port, biner hilang, konfigurasi hilang. Kejadian berikutnya akan lebih cepat dikenali.