Instans OpenVPN yang manakah sebenarnya menggunakan profil PiVPN anda?

PiVPN menulis konfigurasi pelayan dan profil klien, kemudian keluar; ia tidak pernah menjadi proses yang membawa trafik anda. Jadi handshake yang gagal, klien yang mendail titik hujung yang salah, atau perkhidmatan yang kembali rosak selepas but semula tidak dapat dijelaskan daripada menu pemasang. Gejala-gejala itu milik daemon OpenVPN yang sedang berjalan sekarang, konfigurasi yang benar-benar dimuatkan oleh daemon itu, dan log yang ditujunya. Empat arahan baca sahaja biasanya menyelesaikannya, dan tiada satu pun mengubah sijil atau kunci anda.

Pembantu dan daemon ialah objek yang berbeza

Kekeliruan mudah dijelaskan: satu direktori menyimpan fail yang dihasilkan pembantu, fail yang dibaca daemon, dan kadangkala salinan usang kedua-duanya. Pembantu ialah skrip penyediaan. Ia memasang pakej, menulis fail unit dan mencetak profil klien, kemudian tugasnya tamat. Yang tinggal ialah entri dalam pengurus perkhidmatan dan satu baris arahan.

Pada hos systemd, mulakan daripada unit aktif dan bukan senarai direktori. Namanya bergantung pada pembungkusan: imej Debian dan Raspberry Pi OS biasanya menyediakan instans templat seperti openvpn-server@server, manakala pemasangan lama menggunakan openvpn@server. Tanya pengurus yang mana sedang berjalan daripada meneka daripada nama fail.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Baca ExecStart= dalam output itu. Ia menamakan fail boleh laku dan pilihan yang benar-benar dilancarkan pengurus, termasuk mana-mana --config laluan; fail konfigurasi yang terletak berdekatan dan tidak dirujuk oleh mana-mana arahan bukan sebahagian daripada terowong yang berjalan.

Ikut rantaian konfigurasi yang diselesaikan oleh daemon

OpenVPN tidak mengimbas direktori untuk tetapan. Ia membaca fail yang dihantar dengan --config, mengikut mana-mana config arahan di dalamnya, kemudian menggunakan pilihan baris arahan. Manual 2.6 menerangkan susunan itu, dan ia penting apabila dua fail tidak bersetuju tentang port, peranti atau sifer.

Buang dahulu seruan berkesan, kemudian lihat arahan yang menentukan identiti dan kebolehsampaian. Kedua-dua arahan adalah baca sahaja dan selamat pada pelayan hidup, walaupun yang kedua mencetak laluan yang mungkin anda tidak mahu dalam tiket awam.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Fail .ovpn dalam direktori rumah ialah artifak klien. Daemon pelayan tidak pernah membacanya, jadi menyunting fail itu untuk membaiki kegagalan handshake di sebelah pelayan tidak mencapai apa-apa.

Sertaan ialah perangkap yang lain. Baris config menarik fail kedua yang pilihannya diproses pada titik itu, jadi arahan nilai tunggal yang lebih lewat boleh mengatasi apa yang kelihatannya dikatakan fail utama. Jika fail yang kelihatan itu betul tetapi daemon masih berkelakuan lain, baca fail sertaan itu sebelum mengubah apa-apa.

Padankan log dengan proses, bukan dengan ralat yang anda ingat

Dua destinasi log biasa, dan hanya satu daripadanya ialah journal. Dengan log-append ditetapkan, daemon menulis ke fail itu dan journal menyimpan sedikit selain baris permulaan. Tanpanya, journalctl ialah sumber peristiwa.

journalctl -u openvpn-server@server -n 80 --no-pager

Kaitkan satu percubaan sambungan dengan satu tetingkap masa. Catat titik hujung klien, kemudian baca peristiwa pelayan daripada saat yang sama. Handshake TLS yang tidak pernah sampai ke pertukaran sijil menunjukkan kebolehsampaian atau ketidakpadanan protokol, manakala penolakan pengesahan datang selepas parameter terowong sudah dipersetujui.

Entri log lama tidak membuktikan apa-apa tentang profil yang anda muat turun lima minit lalu. Hasilkan semula fail klien, sambung sekali, dan baca hanya baris yang muncul semasa percubaan itu.

Catat kegagalan khusus yang pertama, bukan yang umum terakhir. Ralat bind, pertukaran luar tanpa jawapan, penolakan sijil dan penolakan akaun masing-masing membawa anda ke lapisan berbeza, dan tamat masa di hujung sering menyembunyikan peristiwa berguna di atasnya.

Membina semula terowong bukan langkah diagnostik

Jalan pintas yang menggoda ialah mendirikan terowong kedua yang lebih ringkas: kunci statik, tiada sijil, tiada pengesahan tambahan. Ia selalunya akan bersambung, dan ia hanya membuktikan dua hos boleh melepaskan UDP atau TCP antara satu sama lain. Ia tidak berkata apa-apa tentang mengapa penggunaan yang disahkan sijil gagal, dan ia menggantikan model keselamatan yang diminta anda kekalkan secara senyap.

Perkara sama berlaku untuk menyahdayakan tls-auth atau tls-crypt, melonggarkan verify-x509-name, atau menggugurkan faktor kedua untuk mendapatkan status hijau. Terowong yang bersambung kerana pengesahan dibuang ialah sistem lain, bukan yang dibaiki.

Lakukan satu perubahan terhad pada lapisan yang dinamakan log, mula semula unit yang sama, dan ulangi satu percubaan sambungan itu. Itu mengekalkan perbandingan jujur, dan meninggalkan perubahan yang boleh anda balikkan.

Apa yang hendak diserahkan kepada orang seterusnya

Tulis empat fakta selagi anda masih memilikinya: versi OpenVPN daripada openvpn --version, unit yang aktif, rantaian konfigurasi dengan sertaan-nya, dan tetingkap log yang meliputi satu percubaan. Empat itu mengubah aduan kabur menjadi kes yang boleh dihasilkan semula.

Sunting dulu sebelum berkongsi. Kunci peribadi, auth-user-pass fail, bahan kunci statik dan himpunan klien penuh tidak wajar masuk tiket; nama pilihan dan bentuk rantaian biasanya cukup untuk sepasang mata kedua.

Jika rantaian utuh dan log masih menunjuk ke rangkaian, langkah seterusnya ialah laluan antara klien dan pelayan dan bukan pemasangan lain. Itulah satu-satunya bahagian cerita yang tidak pernah dimiliki pembantu.