VPN anda hanya berfungsi selepas log masuk kerana gelang kunci

Perintah itu berfungsi apabila anda log masuk, jadi anda letakkannya dalam skrip permulaan dan pulang. Keesokan paginya mesin berada dalam talian dan terowong tidak. Mitosnya ialah panggilan yang berfungsi bermakna perkhidmatan yang berfungsi. Dalam amalan perbezaannya biasanya salah satu daripada dua perkara: profil itu milik sesi pengguna anda dan bukan sistem, atau rahsia itu dibuka oleh sesuatu yang hanya wujud selepas anda log masuk. Kedua-duanya berfungsi sempurna dalam ujian manual dan gagal tepat pada saat tiada siapa yang memerhati.

Mengapa log masuk menjadikannya berfungsi

Log masuk grafik memulakan bas sesi dan ejen perkhidmatan rahsia, dan di situlah banyak klien berorientasikan desktop menyimpan kata laluan profil atau frasa laluan kunci peribadi. Pengaktifan yang berjalan sebagai pengguna anda selepas log masuk boleh meminta rahsia itu daripada ejen tersebut dan berjaya. Pengaktifan yang sama yang dijalankan oleh unit semasa boot tidak mempunyai sesi, bas mahupun ejen, jadi carian gagal atau tersekat pada gesaan yang tiada siapa nampak.

Jalankan profil yang sama sebelum dan selepas log masuk dan anda mendapat dua hasil berbeza daripada satu konfigurasi. Itulah tanda kebergantungan pada kelayakan, bukan terowong yang rosak, dan ia menjelaskan mengapa ujian manual dalam terminal membuktikan lebih sedikit daripada yang kelihatan. Terowong itu baik; perkara yang membuka rahsianya hilang.

Tentukan pemilik mana yang memulakan terowong

Terdapat dua corak yang disokong, dan mencampurkannya ialah cara lain ini gagal. NetworkManager boleh mengaktifkan sambungan berskala sistem, yang sesuai apabila mesin sudah memusatkan rangkaiannya di situ. Sebagai alternatif, unit systemd khusus menjalankan VPN secara langsung dan memiliki antara muka itu sendiri.

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

Jangan jalankan kedua-dua pemilik terhadap satu konfigurasi. Jika NetworkManager menguruskan antara muka dan unit juga menaikkannya, mereka akan berebut laluan dan DNS, dan keadaan yang terhasil bergantung pada siapa yang selesai terakhir.

Letakkan rahsia di tempat perkhidmatan boleh membacanya

Perkhidmatan latar belakang tidak boleh menjawab gesaan. Frasa laluan sijil, kata laluan akaun dan fail pengesahan yang dirujuk semuanya memerlukan susunan storan yang boleh dicapai oleh unit tanpa manusia, dimiliki oleh akaun yang menjalankan perkhidmatan dan tidak boleh dibaca oleh orang lain.

Jalan pintas yang menggoda ialah menjadikan fail itu boleh dibaca oleh semua orang sehingga ralat kebenaran hilang. Itu menukar kegagalan permulaan dengan pendedahan kelayakan jangka panjang, dan itulah jenis perubahan yang tidak disemak semula oleh sesiapa. Gunakan mekanisme yang sudah dipercayai oleh penggunaan: fail kelayakan terhad, kunci tidak disulitkan yang dilindungi oleh kebenaran fail, atau sambungan berskala sistem dengan storan rahsianya sendiri.

Uji peristiwa yang benar-benar berlaku

Memulakan perkhidmatan secara manual selepas log masuk hampir tidak menguji apa-apa. But semula, atau lumpuhkan log masuk grafik untuk satu kitaran, dan tonton unit itu naik sendiri. Itulah satu-satunya ujian yang melatih ketersediaan kelayakan, kesediaan rangkaian dan susunan unit serentak. Ia juga ujian yang menghasilkan semula kegagalan yang dilaporkan pengguna, yang tidak pernah dilakukan oleh permulaan manual.

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

Susunan sama pentingnya dengan kelayakan. Unit yang bermula sebelum pautan atas asas dikonfigurasikan akan berputus asa, dan sesetengah pengedaran berbeza sama ada mereka menunggu kesambungan. Jika unit melaporkan kegagalan semasa boot tetapi berjaya apabila dimulakan dengan tangan tiga puluh saat kemudian, anda telah menemui masalah susunan dan bukan masalah rahsia.

Sahkan laluan dan DNS, bukan hanya antara muka

Antara muka yang wujud bukan terowong yang berfungsi. Selepas permulaan tanpa pengawasan, periksa laluan, keadaan penyelesai dan satu destinasi mengikut alamat sebelum memeriksa nama. Kemudian periksa aplikasi yang menjadi sebab terowong itu wujud.

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 alamat berfungsi dan nama tidak, masalah yang tinggal ialah dasar DNS dan bukan terowong. Catat pemilik mana yang memulakan perkhidmatan dan di mana rahsia disimpan, kerana orang seterusnya yang akan but semula mesin ini memerlukan kedua-dua fakta.