VPN Anda hanya berfungsi setelah login karena keyring

Perintah itu berfungsi saat Anda sudah login, jadi Anda menaruhnya di skrip startup dan pulang. Pagi berikutnya mesinnya daring dan terowongannya tidak. Mitosnya adalah pemanggilan yang berfungsi berarti layanan yang berfungsi. Dalam praktiknya perbedaannya biasanya salah satu dari dua hal: profilnya milik sesi pengguna Anda, bukan sistem, atau rahasianya dibuka oleh sesuatu yang hanya ada setelah Anda login. Keduanya bekerja sempurna dalam uji manual dan gagal tepat pada saat tidak ada yang mengawasi.

Mengapa login membuatnya berfungsi

Login grafis memulai bus sesi dan agen layanan rahasia, dan di sanalah banyak klien berorientasi desktop menyimpan kata sandi profil atau frasa sandi kunci privat. Aktivasi yang berjalan sebagai pengguna Anda setelah login dapat meminta rahasia itu kepada agen tersebut dan berhasil. Aktivasi yang sama yang dijalankan oleh unit saat boot tidak memiliki sesi, bus, maupun agen, sehingga pencariannya gagal atau terblokir pada permintaan yang tidak dilihat siapa pun.

Jalankan profil yang sama sebelum dan sesudah login dan Anda mendapatkan dua hasil berbeda dari satu konfigurasi. Itu tanda ketergantungan pada kredensial, bukan terowongan yang rusak, dan menjelaskan mengapa uji manual di terminal membuktikan lebih sedikit daripada yang terlihat. Terowongannya baik-baik saja; yang membuka rahasianya justru hilang.

Putuskan pemilik mana yang memulai terowongan

Ada dua pola yang didukung, dan mencampurnya adalah cara lain ini gagal. NetworkManager dapat mengaktifkan koneksi berskala sistem, yang cocok saat mesin sudah memusatkan jaringannya di sana. Alternatifnya, unit systemd khusus menjalankan VPN langsung dan memiliki antarmukanya sendiri.

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

Jangan menjalankan kedua pemilik pada satu konfigurasi. Jika NetworkManager mengelola antarmuka dan sebuah unit juga menaikkannya, keduanya akan berebut rute dan DNS, dan keadaan yang dihasilkan bergantung pada siapa yang selesai terakhir.

Taruh rahasia di tempat layanan bisa membacanya

Layanan latar belakang tidak bisa menjawab permintaan. Frasa sandi sertifikat, kata sandi akun, dan berkas autentikasi yang dirujuk semuanya memerlukan tataan penyimpanan yang dapat dijangkau unit tanpa manusia, dimiliki oleh akun yang menjalankan layanan, dan tidak terbaca oleh semua orang lain.

Jalan pintas yang menggoda adalah membuat berkas itu dapat dibaca semua orang sampai galat izin hilang. Itu menukar kegagalan startup dengan pemaparan kredensial jangka panjang, dan itulah jenis perubahan yang tidak pernah ditinjau lagi. Gunakan mekanisme yang sudah dipercaya oleh penerapan: berkas kredensial terbatas, kunci tanpa enkripsi yang dilindungi izin berkas, atau koneksi berskala sistem dengan penyimpanan rahasianya sendiri.

Uji peristiwa yang benar-benar terjadi

Menjalankan layanan secara manual setelah login hampir tidak menguji apa pun. Boot ulang, atau nonaktifkan login grafis selama satu siklus, dan lihat unitnya naik sendiri. Itu satu-satunya uji yang melatih ketersediaan kredensial, kesiapan jaringan, dan urutan unit sekaligus. Itu juga uji yang mereproduksi kegagalan yang dilaporkan pengguna, yang tidak pernah dilakukan oleh start manual.

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

Urutan sama pentingnya dengan kredensial. Unit yang mulai sebelum uplink yang mendasarinya dikonfigurasi akan menyerah, dan sebagian distribusi berbeda dalam hal apakah mereka menunggu konektivitas. Jika unit melaporkan kegagalan saat boot tetapi berhasil saat dijalankan dengan tangan tiga puluh detik kemudian, Anda menemukan masalah urutan dan bukan masalah rahasia.

Verifikasi rute dan DNS, bukan hanya antarmuka

Antarmuka yang ada bukan terowongan yang berfungsi. Setelah start tanpa pengawasan, periksa rute, keadaan resolver, dan satu tujuan berdasarkan alamat sebelum memeriksa nama. Lalu periksa aplikasi yang menjadi alasan terowongan itu ada.

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

Jika alamatnya berfungsi dan namanya tidak, masalah yang tersisa adalah kebijakan DNS dan bukan terowongannya. Catat pemilik mana yang memulai layanan dan di mana rahasianya tinggal, karena orang berikutnya yang mem-boot ulang mesin ini akan memerlukan kedua fakta itu.