OpenVPN semasa boot di Ubuntu: NetworkManager atau systemd?

Kebanyakan panduan membentangkan pilihan ini sebagai hal kosmetik: sama ada biarkan NetworkManager menaikkan terowong, atau aktifkan contoh systemd dan selesai. Kedua-dua laluan berbeza dalam satu perkara yang menentukan hasil pada mesin tanpa skrin, dan ia tidak ada kaitan dengan alat mana yang lebih baharu. NetworkManager membuka rahsia melalui sesi; contoh systemd tiada sesi untuk dibuka. Pilih laluan yang pengendalian rahsianya sepadan dengan mesin di hadapan anda.

Semua yang lain, daripada pemasangan laluan hingga tingkah laku sambungan semula, mengikut keputusan pertama itu.

Gelang kunci ialah perbezaan yang tiada siapa sebut

Apabila NetworkManager memiliki profil VPN, kata laluan boleh tinggal dalam gelang kunci log masuk, yang dibuka apabila pengguna log masuk. Itu berfungsi baik pada komputer riba: orangnya hadir, gelang kunci terbuka, terowong naik. Pada pelayan yang boot tanpa pengawasan tiada sesiapa untuk membuka apa-apa, jadi profil menunggu rahsia yang tidak pernah tiba. Sambungan kelihatan dikonfigurasikan dan tidak pernah diaktifkan.

Contoh systemd mengelakkan masalah itu dengan membaca fail kelayakan dari cakera, yang menjadikan fail itu perkara yang anda lindungi. chmod 400 serta pemilikan oleh root ialah minimum, dan fail itu patut kekal di luar sandaran dan templat imej yang anda tidak kawal.

Melampirkan VPN pada sambungan bukan jaminan boot

Dalam nm-connection-editor, pilih sambungan berwayar atau wayarles dan bukan VPN, buka tab General, tandakan pilihan untuk menyambung ke VPN secara automatik dan namakan profil. NetworkManager kemudian mengaktifkan VPN sebagai sambungan sekunder apabila sambungan utama mencapai keadaan bersambung. Itu kebergantungan, bukan peraturan tembok api. Paket masih boleh keluar dalam saat sebelum terowong naik, dan rahsia tersimpan yang gagal dibuka membiarkan mesin dalam talian tanpanya.

Jika keperluannya ialah tiada apa keluar tanpa terowong, katakan begitu dan bina suis bunuh, kerana tetapan ini tidak akan menyediakannya. Uji juga gantung dan sambung semula, kerana sambungan sekunder dinilai semula dalam perjalanan balik.

Contoh systemd memerlukan nama fail yang sepadan

Letakkan profil dalam direktori klien yang dijangka oleh pakej, seperti /etc/openvpn/client/office.conf, dan rujuk fail kelayakan dari dalamnya dengan auth-user-pass office.cred. Nama contoh ialah nama fail tanpa akhiran, jadi openvpn-client@office membaca office.conf. Dayakan dengan sudo systemctl enable --now openvpn-client@office dan sahkan pemetaan dengan systemctl cat openvpn-client@office dan bukan mempercayai contoh daripada blog.

Laluan di dalam profil diselesaikan berbanding direktori kerja unit, bukan profil itu sendiri, jadi baris relatif ca atau auth-user-pass boleh gagal semasa boot walaupun berfungsi apabila anda mengujinya secara manual. Gunakan laluan mutlak untuk semua yang unit mesti temui. Kemudian baca journalctl -u openvpn-client@office -b selepas boot sebenar; unit yang melaporkan aktif tanpa terowong biasanya menamakan fail yang hilang dalam log itu.

Pakej lama membawa nama templat yang berbeza, jadi systemctl list-unit-files 'openvpn*' menentukan mana yang wujud pada hos ini.

Tingkah laku sambungan semula ialah keputusan berasingan

Profil dengan ping-restart membina semula terowong selepas ia jatuh, dan unit dengan arahan mula semula melakukan sesuatu yang serupa pada peringkat perkhidmatan. Itu dasar yang anda pilih, bukan lalai yang anda warisi. Jika sambungan hanya patut naik atas permintaan, buang tingkah laku mula semula secara sengaja dan tuliskan sebabnya. Jika unit bermula sebelum rangkaian boleh digunakan, ia memerlukan dasar cuba semula, kerana satu percubaan gagal semasa boot tidak berulang dengan sendirinya.

Berhenti juga sama literal: sudo systemctl disable --now openvpn-client@office menghentikan contoh yang berjalan dan membuang pautan boot. Menyahdayakan sahaja membiarkan terowong berjalan sehingga boot semula seterusnya, yang mengejutkan sesiapa yang menguji dengan menyahdayakan dan melihat antara muka kekal naik.

Boot semula, kemudian semak empat perkara mengikut urutan

Memulakan semula perkhidmatan menguji perkhidmatan; but semula mesin menguji laluan boot. Selepas boot semula, sahkan unit naik, kemudian bahawa laluan wujud untuk subrangkaian jauh, kemudian alamat mana yang mesin tunjukkan kepada internet, dan akhirnya bahawa nama diselesaikan melalui terowong. Keempat-empat semakan itu gagal dalam urutan itu apabila ada yang tidak kena, yang menjadikan kegagalan pertama yang berguna.

Unit yang aktif tanpa laluan biasanya bermakna profil bersambung tetapi pelayan tidak menolak sebarang laluan, atau laluan itu dipasang pada antara muka yang hilang kemudian. Laluan tanpa carian nama yang berfungsi menunjuk ke konfigurasi DNS dan bukan ke terowong itu sendiri.

Putuskan lebih awal apa yang patut berlaku apabila terowong tidak dapat naik. Kembali ke sambungan biasa ialah dasar, dan ia patut dituliskan dan bukan diserahkan kepada pengurus mana pun yang bermula dahulu.