VPN yang mati pada saat pertama ialah haiwan yang berbeza daripada yang bersambung lalu gagal, dan kesilapan biasa ialah menganggap keduanya sama. Di sini tiada handshake, tiada pertukaran sijil dan tiada laluan untuk diperiksa. Satu baris dalam jurnal menentukan pembaikan mana antara beberapa pembaikan tidak berkaitan yang terpakai, dan melangkaunya menghabiskan satu petang menyunting konfigurasi yang tidak pernah dibaca. Baca baris itu dahulu.

Tiga arahan baca sahaja membawa anda ke sana: journalctl -u openvpn@server -b --no-pager dahulu, kemudian systemctl status openvpn@server, dan ss -lunp untuk pendengar UDP serta pemiliknya.

Baris pertama yang memilih cabang

Konflik port dan binari yang hilang kedua-duanya mematikan permulaan dalam satu saat, dan kedua-duanya meninggalkan baris pertama yang berbeza. Mesej alamat sudah digunakan menamakan port; binari yang hilang menamakan laluan yang tidak lagi wujud; syarat yang gagal atau fail konfigurasi yang tiada menamakan fail itu. Ketiga-tiganya membawa kepada pembaikan berbeza, dan tiada satu pun menjadi lebih baik dengan memasang semula klien. Salin kegagalan pertama ke dalam nota anda sebelum menjalankan apa-apa lagi.

Perhatikan gelung cuba semula yang menyembunyikan baris asal. Unit dengan dasar mula semula boleh menimbus kegagalan pertama di bawah selusin kegagalan serupa, jadi journalctl -b yang ditapis mengikut unit dan dibaca dari atas mengalahkan hujungnya.

Siapa lagi yang memegang port 1194

Pesalahnya biasanya bukan pelayan kedua yang sengaja dikonfigurasikan seseorang. Jangkakan klien yang dimulakan dengan tangan dan masih hidup di terminal lain, profil kedua yang kebetulan memilih port yang sama, atau bundel vendor yang terowongnya sendiri memegang 1194. Pemilik soket muncul dalam ss -lunp; berikan PID itu kepada systemctl status untuk mengetahui sama ada sesuatu unit bertanggungjawab. Hentikannya melalui laluan kawalannya sendiri, bukan dengan isyarat.

Isyarat kepada proses yang dikendalikan unit biasanya mencetuskan mula semula, dan kegagalan yang sama muncul semula beberapa saat kemudian seperti masalah baharu. Gunakan systemctl stop untuk unit, arahan perkhidmatan bundel itu sendiri untuk pemasangan vendor, dan isyarat hanya untuk sesuatu yang anda mulakan sendiri di dalam shell itu.

Unit yang tinggal selepas pembersihan

Pembersihan memadam binari; fail unit yang ditulis dengan tangan, biasanya di bawah /etc/systemd/system, terus hidup. Systemd kemudian mencuba semula unit yang menunjuk ke laluan yang tidak lagi wujud, dan mesejnya mengenai fail yang hilang itu, bukan penyingkiran semalam. systemctl status menunjukkan laluan serpihan unit berhampiran bahagian atas, jadi periksanya dengan dpkg -S sebelum memadam apa-apa. Setelah anak yatim itu hilang, systemctl daemon-reload dan systemctl reset-failed membersihkan keadaannya; jika tidak, setiap pemeriksaan status kemudian mewarisinya.

Apabila which openvpn menjawab dengan sesuatu di bawah /usr/local, binari yang digunakan datang daripada pemasang vendor dan bukan daripada apt. Pemasang sedemikian biasanya membawa pendengar sendiri, entri but sendiri dan direktori konfigurasi sendiri, jadi membuang arahan yang kelihatan membiarkan soket itu diduduki.

Nyahpasangnya seperti yang didokumenkan vendor, sahkan port itu bebas dengan ss -lunp, dan tambah klien edaran itu hanya jika anda memerlukannya.

Betulkan keadaan sebelum mencuba lagi

Bersihkan keadaan gagal sebelum membuat kesimpulan daripadanya: systemctl reset-failed membuang pembilangnya, dan systemctl status kemudian melaporkan keadaan unit semasa, bukan sejarahnya. Mulakannya sekali dan baca jurnal larian itu sendiri, bukan keadaan agregat mesin. Unit yang melaporkan aktif sedangkan terowong tidak membawa apa-apa ialah masalah berasingan, dan jauh lebih biasa. Kedua-duanya bercampur dalam laporan pepijat kerana kedua-duanya berakhir dengan pengguna berkata VPN tidak berfungsi.

Catat cabang yang anda ambil: konflik port, binari hilang, konfigurasi hilang. Kali seterusnya ia akan lebih cepat dikenali.

Artikel berkaitan