nmcli terus meminta kata laluan VPN: simpan rahsia secara setempat
Sesi desktop menjawab gesaan itu dengan agen rahsia. Melalui SSH tiada siapa yang berbuat demikian, jadi letakkan kelayakan dalam fail kunci dan muat semula profil.
Profil yang sama, dua sesi: ia bersambung dari desktop dan tergantung melalui SSH pada gesaan yang tiada apa-apa dapat menjawab. Tiada apa-apa rosak dan tiada tetapan hilang. NetworkManager meminta kelayakan daripada agen rahsia, dan agen rahsia ialah komponen desktop yang tidak wujud dalam sesi yang anda gunakan.
Jalankan urutan di bawah dan terowong akan naik tanpa antara muka grafik, dengan syarat menyimpan rahsia mengubah siapa yang boleh menggunakan profil itu.
Sahkan diagnosis sebelum mengubah apa-apa
Perbezaan antara pengaktifan interaktif dan bukan interaktif ialah keseluruhan diagnosis. Jika nmcli --ask connection up berjaya manakala pengaktifan biasa tersekat, profil itu betul dan sumber rahsia itu hilang. Perbandingan tunggal itu menyelamatkan anda daripada menulis semula konfigurasi yang berfungsi.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office IPsec" | grep -i flags
Baca bendera itu daripada menekanya. Nilai yang bermaksud "tanya agen" ialah apa yang anda cari, dan nama kunci yang tepat berbeza antara pemalam VPN kerana ia tinggal dalam kamus data pemalam itu sendiri. Profil FortiSSL dan profil IPsec tidak semestinya menggunakan nama yang sama, jadi bekerjalah daripada output profil anda sendiri.
Sahkan juga pakej pemalam untuk protokol itu telah dipasang. Pemalam yang hilang muncul sebagai jenis sambungan tidak diketahui atau sebagai ralat pengaktifan yang tidak menyebut apa-apa tentang kata laluan, dan mengejar rahsia dalam keadaan itu membuang jam yang sama dua kali. Satu pertanyaan pakej lebih murah daripada sepanjang petang menyunting fail kunci.
Pindahkan rahsia ke dalam fail kunci
Fail sambungan terletak di bawah /etc/NetworkManager/system-connections/. Rahsia tidak disimpan di situ secara lalai, dan itulah maksud bendera yang baru anda baca. Menukar bendera kepada sifar memberitahu NetworkManager bahawa nilai itu disimpan bersama profil dan bukannya diminta semasa pengaktifan.
[vpn]
password-flags=0
[vpn-secrets]
password=YOUR-VPN-PASSWORD
Untuk profil dengan dua rahsia, corak itu berulang: satu bendera bagi setiap rahsia dalam bahagian [vpn], dan nilainya dalam [vpn-secrets]. Profil IPsec biasanya membawa kunci yang dikongsi terlebih dahulu bersama kelayakan pengguna, dan pemalam menamakannya berbeza daripada medan kata laluan biasa, jadi salin nama kunci daripada output vpn.data dan bukan daripada catatan blog yang menggunakan pemalam lain. Satu nama kunci yang salah menghasilkan profil yang dimuatkan dan kemudian gagal semasa pengesahan, yang terbaca tepat seperti kata laluan yang salah. Bandingkan fail anda dengan profil yang berfungsi daripada pemalam yang sama sebelum menyambung semula.
Letakkan dalam tanda petik nilai yang mengandungi ruang, tanda petik atau tanda dolar. Nilai tanpa tanda petik yang mengandungi $ akan dibaca secara harfiah atau dikembangkan bergantung pada tempat ia dihuraikan, dan kegagalan pengesahan yang terhasil kelihatan seperti kata laluan yang salah.
Kemudian betulkan pemilikan dan mod fail. Fail kunci ini dibaca oleh perkhidmatan istimewa, dan fail yang boleh dibaca pengguna lain dianggap tidak boleh dipercayai, yang merupakan sebab biasa profil yang disunting kelihatan diabaikan. Pemilik root, mod 600, tiada pengecualian.
Muat semula, kemudian aktifkan
Fail dibaca apabila sambungan dimuatkan, jadi menyuntingnya tidak cukup. Muat semula profil dan kemudian naikkan sambungan secara jelas.
sudo nmcli connection reload
sudo nmcli connection up "Office IPsec"
Jika muat semula tidak mengambil perubahan itu, permulaan semula perkhidmatan sepenuhnya akan mengambilnya, dan ada laporan tentang perkara itu. Utamakan muat semula apabila pautan lain penting, kerana memulakan semula perkhidmatan memutuskan setiap sambungan yang diurus, dan pada hos jauh itu boleh menamatkan sesi anda sebelum terowong yang anda mahukan naik.
Gunakan UUID apabila nama kabur. Mesin dengan beberapa profil pelanggan mengumpul hampir pendua, dan mengaktifkan yang salah menghasilkan kegagalan yang kelihatan seperti masalah kelayakan.
Apabila rahsia yang disimpan bukan masalahnya
Profil FortiSSL boleh gagal walaupun dengan kelayakan tersimpan yang betul kerana klien tidak pernah mempercayai sijil get laluan. Tetapan itu tiada dalam dialog utama; ia terletak di sebalik pilihan lanjutan untuk VPN, tempat ringkasan sijil yang dipercayai dimasukkan. Jika log menyebut sijil dan bukan kata laluan, anda berada dalam cabang ini dan berapa banyak pun penyuntingan [vpn-secrets] tidak akan membantu.
Dua lagi pemeriksaan tergolong di sini. Sahkan profil itu tidak diimport daripada fail yang masih menunjuk ke laluan yang pemalam tidak dapat baca, dan sahkan bahawa profil itu yang aktif dan bukan pendua lama. Kedua-duanya menghasilkan kegagalan pengaktifan yang terbaca seperti ralat pengesahan.
Tentukan sama ada penyimpanan boleh diterima
PSK dan kata laluan yang disimpan boleh dibaca oleh apa-apa yang berjalan sebagai root pada mesin itu. Pada mesin yang anda kawal, itu pertukaran yang munasabah untuk perkhidmatan tanpa antara muka. Pada hos dikongsi, ia wajar dibincangkan, kerana profil itu kini mengandungi kelayakan yang sebelum ini dilindungi oleh cincin kunci desktop. Tanya siapa lagi yang boleh mencapai root pada hos itu sebelum anda membuat keputusan, bukan selepas perubahan itu dilaksanakan.
Jika dasar melarang penyimpanan rahsia VPN, jangan lemahkan profil itu supaya tugas cron berfungsi. Jalankan sambungan daripada sesi yang mempunyai agen, atau gunakan mekanisme lain untuk automasi.
Akhir sekali, catatkan profil mana yang membawa rahsia supaya tiada siapa menyalin satu ke komputer riba tanpa menyedarinya. Komen di atas bahagian rahsia dengan tarikh dan sebabnya sudah memadai, dan ia akan menyelamatkan seseorang daripada semakan yang janggal kemudian.