PSK L2TP/IPsec ditolak: telusuri dialog dahulu, kemudian fail
Kunci pada skrin masih boleh kalah kepada fail rahsia lama atau pemisah baris yang tidak kelihatan. Jejakinya dari medan NetworkManager sehingga ke /etc/ipsec.d.
Anda menampal kunci pra-kongsi daripada mesej pentadbir ke dalam dialog NetworkManager, menandakan kotak untuk menunjukkannya, dan ia sepadan huruf demi huruf. Sambungan tetap berakhir dengan kegagalan pengesahan sebelum terowong naik. Kali pertama saya melihatnya, saya menyangka kuncinya salah; ia bukan salah. Dua perkara lain menentukan apa yang benar-benar dibaca oleh daemon: fail rahsia yang ditulis pemalam untuk sambungan itu, dan sama ada nilainya melintasi dialog tanpa perubahan.
Laluan di bawah mengikut kunci dari medan ke fail, dan urutan itulah yang memberitahu anda di mana ia hilang. Lakukan pada mesin yang gagal, bukan pada mesin yang berfungsi, kerana perbezaan antara kedua-dua mesin itu biasanya susun atur fail, bukan kuncinya.
Mulakan dari dialog, tetapi jangan percaya pada medan
Buka tab IPsec sambungan dan taip semula kunci itu dan bukan menampalnya. Kunci yang disalin daripada mesej sembang, PDF atau pengurus kata laluan boleh tiba dengan pemisah baris di hujung yang tidak dipaparkan oleh medan, dan aksara yang kelihatan masih kelihatan betul.
Klik kawalan tunjuk kata laluan dan lihat hujung rentetan, bukan tengahnya. Jika kursor meninggalkan baris kosong di bawah teks, hapuskannya dan taip semula aksara terakhir. Satu pembetulan itu menyelesaikan sebahagian besar laporan seperti ini, dan kosnya lebih rendah daripada membaca mana-mana log.
Jika kunci datang daripada sistem tiket yang membalut baris panjang, minta melalui saluran yang tidak membalut. Bandingkan panjang dengan pentadbir dan bukan meneliti dua rentetan bersebelahan; aksara yang hilang pada titik balutan tidak kelihatan dalam fon berkadar.
Ikuti kunci ke dalam /etc/ipsec.d
Pemalam tidak pernah menyerahkan PSK kepada daemon IPsec sebagai hujah pada baris arahan. Sebaliknya ia menyimpan nilai dalam fail rahsia dan mengatur supaya daemon menyertakan fail itu, dengan menambah baris include pada /etc/ipsec.secrets jika tiada. Apa yang dipegang dialog ialah input kepada fail yang dijana itu, bukan nilai yang digunakan.
Senaraikan apa yang wujud sebelum anda mengubah apa-apa:
ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets
Keluaran pemalam yang lebih lama menulis satu fail bagi setiap sambungan, dinamakan sempena UUID sambungan, contohnya /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Memadam profil dalam applet tidak memadam fail itu secara boleh dipercayai. Jika fail lama daripada pelayan terdahulu masih ada pada cakera dan masih disertakan, daemon boleh memilih rahsia milik profil yang tidak lagi anda gunakan, dan sambungan gagal sedangkan medan yang kelihatan adalah betul.
Fahami apa yang perubahan 1.2.12 lakukan kepada naik taraf
Versi pemalam 1.2.12 menggantikan fail rahsia setiap sambungan dengan satu fail dikongsi, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Naik taraf tidak membersihkan fail lama mengikut UUID, dan baris include /etc/ipsec.d/*.secrets yang sedia ada masih menyertakannya. Versi 1.2.16 mengubah pengendalian cadangan lalai, bukan susun atur rahsia.
Sejarah itu menjelaskan mengapa dua mesin dengan profil yang kelihatan sama berkelakuan berbeza. Kuncinya sama; set fail yang disertakan daemon tidak sama. Apabila membuang fail yatim, alihkannya ke tepi dan bukan memadamnya, sahkan sambungan, kemudian padamkannya setelah keadaan berfungsi direkodkan. Menamakan semula mengekalkan nilai lama boleh dipulihkan jika rupa-rupanya kerosakan itu ada di tempat lain.
Pisahkan aksara yang tidak dapat ditampung oleh format storan
Dokumentasi strongSwan untuk rentetan rahsia dikongsi menyatakan bahawa nilai itu tidak boleh mengandungi pemisah baris atau aksara petikan berganda. Kunci yang ditampal daripada dokumen boleh membawa salah satu daripadanya tanpa sebarang perbezaan visual dalam dialog biasa.
Sejak 1.2.12 nilai yang disimpan bukan teks biasa. Pemalam mengekod PSK dengan base64 sebelum ia sampai ke fail, dan nota keluaran menyebut pengekodan itu sebagai sebab petikan berganda kini boleh diterima dalam kunci. Petikan yang ditaip dalam medan itu boleh diwakili; perkara yang sama tidak benar bagi setiap aksara kawalan.
Panjang ialah kekangan lain. Tiada minimum sejagat terpakai merentas perisian L2TP/IPsec: sesetengah klien menerima kunci lebih pendek daripada dua puluh aksara dan sesetengah get laluan mengenakan minimum. Jika kunci pendek ditolak, peraturannya milik dasar pelayan atau pengesahan klien itu, dan menaikkan sesuatu secara setempat tidak akan mengubahnya.
Baca lapisan pengesahan mana yang gagal
Jalankan ipsec --version dahulu, kerana strongSwan dan Libreswan menggunakan nama fail dan sintaks yang berbeza, dan nasihat untuk satu boleh merosakkan yang lain. Kemudian baca peringkat kegagalan daripada mesej klien atau log daemon: aduan tentang kunci pra-kongsi ialah peristiwa berbeza daripada nama pengguna dan kata laluan yang ditolak.
PSK mengesahkan hujung terowong. Nama pengguna dan kata laluan mengesahkan orang di dalam L2TP, dan PPP mengendalikannya selepas persatuan IPsec naik. PSK yang betul dengan akaun yang salah tetap gagal, dan menukar akaun tidak akan membaiki kunci yang tidak pernah dibaca dengan betul oleh daemon.
Apabila menutup tiket, tuliskan kesemuanya empat: versi pemalam, fail rahsia yang digunakan, sama ada kunci ditaip semula atau ditampal, dan lapisan yang dinamakan dalam ralat. Dengan itu sesiapa yang mengulangi laluan ini kemudian boleh terus melompat kepada perbezaan antara mesin yang berfungsi dan yang gagal.