OpenVPN saat boot di Ubuntu: NetworkManager atau systemd?

Sebagian besar panduan menyajikan pilihan ini sebagai hal kosmetik: biarkan NetworkManager menaikkan terowongan, atau aktifkan instans systemd dan selesai. Kedua jalur berbeda dalam satu hal yang menentukan hasil pada mesin tanpa layar, dan itu tidak ada hubungannya dengan alat mana yang lebih baru. NetworkManager membuka rahasia melalui sesi; instans systemd tidak punya sesi untuk dibuka. Pilih yang penanganan rahasianya cocok dengan mesin di depan Anda.

Semua hal lain, dari pemasangan rute hingga perilaku penyambungan ulang, mengikuti keputusan pertama itu.

Gantungan kunci adalah perbedaan yang tidak disebut siapa pun

Ketika NetworkManager memiliki profil VPN, kata sandi dapat berada di gantungan kunci login, yang terbuka saat pengguna masuk. Itu bekerja baik di laptop: orangnya hadir, gantungan kunci terbuka, terowongan naik. Pada server yang boot tanpa pengawasan tidak ada orang untuk membuka apa pun, jadi profil menunggu rahasia yang tidak pernah datang. Koneksi tampak terkonfigurasi dan tidak pernah aktif.

Instans systemd menghindari masalah itu dengan membaca berkas kredensial dari disk, yang menjadikan berkas itu hal yang Anda lindungi. chmod 400 ditambah kepemilikan oleh root adalah minimum, dan berkas harus tetap di luar cadangan dan templat image yang tidak Anda kendalikan.

Melampirkan VPN ke koneksi bukan jaminan boot

Di nm-connection-editor, pilih koneksi kabel atau nirkabel alih-alih VPN, buka tab General, centang opsi untuk menyambung ke VPN secara otomatis dan beri nama profil. NetworkManager lalu mengaktifkan VPN sebagai koneksi sekunder saat koneksi primer mencapai status tersambung. Itu ketergantungan, bukan aturan firewall. Paket masih bisa keluar selama detik-detik sebelum terowongan naik, dan rahasia tersimpan yang gagal dibuka membuat mesin tetap daring tanpanya.

Jika persyaratannya tidak ada yang keluar tanpa terowongan, katakan itu dan bangun kill switch, karena pengaturan ini tidak akan menyediakannya. Uji juga suspend dan resume, karena koneksi sekunder dievaluasi ulang saat kembali.

Instans systemd membutuhkan nama berkas yang cocok

Letakkan profil di direktori klien yang diharapkan paket, seperti /etc/openvpn/client/office.conf, dan rujuk berkas kredensial dari dalamnya dengan auth-user-pass office.cred. Nama instans adalah nama berkas tanpa akhiran, jadi openvpn-client@office membaca office.conf. Aktifkan dengan sudo systemctl enable --now openvpn-client@office dan pastikan pemetaannya dengan systemctl cat openvpn-client@office alih-alih memercayai contoh dari blog.

Jalur di dalam profil diselesaikan relatif terhadap direktori kerja unit, bukan terhadap profil itu sendiri, jadi baris relatif ca atau auth-user-pass bisa gagal saat boot padahal berfungsi saat Anda mengujinya secara manual. Gunakan jalur absolut untuk semua yang harus ditemukan unit. Lalu baca journalctl -u openvpn-client@office -b setelah boot sungguhan; unit yang melaporkan aktif tanpa terowongan biasanya menyebut berkas yang hilang di log itu.

Paket lama menyertakan nama templat yang berbeda, jadi systemctl list-unit-files 'openvpn*' menentukan mana yang ada di host ini.

Perilaku penyambungan ulang adalah keputusan terpisah

Profil dengan ping-restart membangun ulang terowongan setelah putus, dan unit dengan direktif restart melakukan hal serupa di tingkat layanan. Itu kebijakan yang Anda pilih, bukan default yang Anda warisi. Jika koneksi seharusnya hanya naik sesuai permintaan, hapus perilaku restart dengan sengaja dan tuliskan alasannya. Jika unit mulai sebelum jaringan dapat digunakan, ia memerlukan kebijakan percobaan ulang, karena satu percobaan gagal saat boot tidak berulang dengan sendirinya.

Menghentikan sama literalnya: sudo systemctl disable --now openvpn-client@office menghentikan instans yang berjalan dan menghapus tautan boot. Menonaktifkan saja membiarkan terowongan berjalan sampai boot berikutnya, yang mengejutkan siapa pun yang menguji dengan menonaktifkan dan melihat antarmuka tetap naik.

Boot ulang, lalu periksa empat hal secara berurutan

Memulai ulang layanan menguji layanan; mem-boot ulang mesin menguji jalur boot. Setelah boot ulang, pastikan unit naik, lalu bahwa ada rute untuk subnet jarak jauh, lalu alamat mana yang ditampilkan mesin ke internet, dan akhirnya bahwa nama terurai melalui terowongan. Keempat pemeriksaan itu gagal dalam urutan itu ketika ada yang salah, yang membuat kegagalan pertama menjadi berguna.

Unit yang aktif tanpa rute biasanya berarti profil tersambung tetapi server tidak mendorong rute apa pun, atau rute dipasang pada antarmuka yang kemudian hilang. Rute tanpa pencarian nama yang berfungsi menunjuk ke konfigurasi DNS, bukan ke terowongan itu sendiri.

Putuskan sebelumnya apa yang harus terjadi ketika terowongan tidak bisa naik. Kembali ke konektivitas biasa adalah kebijakan, dan sebaiknya dituliskan alih-alih diserahkan kepada pengelola mana pun yang mulai lebih dulu.