Instans OpenVPN mana yang sebenarnya memakai profil PiVPN Anda?

PiVPN menulis konfigurasi server dan profil klien, lalu keluar; ia tidak pernah menjadi proses yang membawa lalu lintas Anda. Karena itu, handshake yang gagal, klien yang menghubungi endpoint yang salah, atau layanan yang kembali rusak setelah reboot tidak dapat dijelaskan dari menu pemasang. Gejala-gejala itu milik daemon OpenVPN yang sedang berjalan sekarang, konfigurasi yang benar-benar dimuat daemon itu, dan log yang dituju. Empat perintah hanya-baca biasanya menyelesaikannya, dan tidak satu pun mengubah sertifikat atau kunci Anda.

Pembantu dan daemon adalah objek yang berbeda

Kebingungannya mudah dijelaskan: satu direktori menyimpan berkas yang dibuat pembantu, berkas yang dibaca daemon, dan kadang salinan usang keduanya. Pembantu adalah skrip penyediaan. Ia memasang paket, menulis berkas unit, dan mencetak profil klien, lalu tugasnya selesai. Yang tersisa adalah entri di manajer layanan dan sebuah baris perintah.

Di host systemd, mulailah dari unit yang aktif, bukan dari daftar direktori. Namanya bergantung pada pengemasan: image Debian dan Raspberry Pi OS biasanya menyediakan instans templat seperti openvpn-server@server, sedangkan pemasangan lama memakai openvpn@server. Tanyakan kepada manajer mana yang berjalan daripada menebak dari nama berkas.

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

Baca ExecStart= pada keluaran itu. Itu menyebut berkas yang dieksekusi dan opsi yang benar-benar diluncurkan manajer, termasuk jalur --config apa pun; berkas konfigurasi yang tergeletak di dekatnya dan tidak dirujuk perintah mana pun bukan bagian dari terowongan yang berjalan.

Ikuti rantai konfigurasi yang diuraikan daemon

OpenVPN tidak memindai direktori untuk mencari pengaturan. Ia membaca berkas yang diberikan dengan --config, mengikuti setiap config direktif di dalamnya, lalu menerapkan opsi baris perintah. Manual 2.6 menjelaskan urutan itu, dan itu penting ketika dua berkas tidak sepakat soal port, perangkat, atau cipher.

Buang dulu pemanggilan efektifnya, lalu lihat direktif yang menentukan identitas dan keterjangkauan. Kedua perintah hanya-baca dan aman di server hidup, meski yang kedua mencetak jalur yang mungkin tidak Anda inginkan di tiket publik.

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

Berkas .ovpn di direktori rumah adalah artefak klien. Daemon server tidak pernah membacanya, jadi menyunting berkas itu untuk memperbaiki kegagalan handshake di sisi server tidak menghasilkan apa pun.

Sertaan adalah jebakan lainnya. Baris config menarik berkas kedua yang opsinya diproses di titik itu, sehingga direktif bernilai tunggal yang lebih belakangan bisa menimpa apa yang tampaknya dikatakan berkas utama. Jika berkas yang terlihat sudah benar tetapi daemon tetap berperilaku lain, baca berkas sertaan itu sebelum mengubah apa pun.

Cocokkan log dengan prosesnya, bukan dengan galat yang Anda ingat

Dua tujuan log lazim, dan hanya satu di antaranya adalah journal. Dengan log-append disetel, daemon menulis ke berkas itu dan journal menyimpan sedikit di luar baris awal. Tanpanya, journalctl adalah sumber peristiwa.

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

Korelasikan satu percobaan koneksi dengan satu jendela waktu. Catat endpoint klien, lalu baca peristiwa server dari detik yang sama. Handshake TLS yang tidak pernah mencapai pertukaran sertifikat menunjuk ke keterjangkauan atau ketidakcocokan protokol, sedangkan penolakan autentikasi datang setelah parameter terowongan sudah disepakati.

Entri log lama tidak membuktikan apa pun tentang profil yang Anda unduh lima menit lalu. Buat ulang berkas klien, hubungkan sekali, dan baca hanya baris yang muncul selama percobaan itu.

Catat kegagalan spesifik pertama, bukan yang umum terakhir. Galat bind, pertukaran luar tanpa jawaban, penolakan sertifikat, dan penolakan akun masing-masing mengantar Anda ke lapisan berbeda, dan timeout di akhir sering menyembunyikan peristiwa berguna di atasnya.

Membangun ulang terowongan bukan langkah diagnostik

Jalan pintas yang menggoda adalah mendirikan terowongan kedua yang lebih sederhana: kunci statis, tanpa sertifikat, tanpa autentikasi tambahan. Ia sering akan terhubung, dan itu hanya membuktikan dua host dapat melewatkan UDP atau TCP di antara mereka. Ia tidak mengatakan apa pun tentang mengapa penerapan bertanda tangan sertifikat gagal, dan diam-diam mengganti model keamanan yang diminta Anda pertahankan.

Hal yang sama berlaku untuk menonaktifkan tls-auth atau tls-crypt, melonggarkan verify-x509-name, atau membuang faktor kedua demi status hijau. Terowongan yang terhubung karena verifikasi dihapus adalah sistem lain, bukan sistem yang diperbaiki.

Lakukan satu perubahan terbatas pada lapisan yang disebut log, mulai ulang unit yang sama, dan ulangi satu percobaan koneksi itu. Itu menjaga perbandingan tetap jujur, dan meninggalkan perubahan yang dapat Anda batalkan.

Apa yang harus diserahkan ke orang berikutnya

Tuliskan empat fakta selagi Anda masih memilikinya: versi OpenVPN dari openvpn --version, unit yang aktif, rantai konfigurasi beserta sertaan-nya, dan jendela log yang mencakup satu percobaan. Empat hal itu mengubah keluhan kabur menjadi kasus yang dapat direproduksi.

Sunting dulu sebelum berbagi. Kunci privat, auth-user-pass berkas, materi kunci statis, dan bundel klien lengkap tidak pantas masuk tiket; nama opsi dan bentuk rantainya biasanya cukup untuk sepasang mata kedua.

Jika rantainya utuh dan log masih menunjuk ke jaringan, langkah berikutnya adalah jalur antara klien dan server alih-alih pemasangan lain. Itu satu-satunya bagian cerita yang tidak pernah dimiliki pembantu.