Log masuk VPN dengan sijil pada Mac: identiti, penggunaan kunci atau kepercayaan gerbang?
Tiga keputusan di sebalik log masuk dengan sijil: identiti mana yang dipilih, sama ada komponen VPN boleh menggunakan kuncinya, dan sama ada gerbang itu dipercayai.
Log masuk VPN berasaskan sijil meminta sesuatu yang lebih sempit daripada kata laluan daripada Mac: gunakan kunci persendirian tertentu ini, dalam konteks pelaksanaan ini, untuk membuktikan identiti kepada gerbang itu. Apabila ia gagal, mesej biasanya hanya menerangkan perkara terakhir yang tidak kena, dan itu jarang menjadi puncanya. Menelusuri tiga keputusan mengikut urutan sistem membuatnya mengekalkan diagnosis yang jujur, dan ia menghalang masalah kebenaran setempat daripada dianggap sebagai kegagalan pengesahan rantaian.
Telusuri log masuk mengikut urutan yang dibuat oleh Mac
Pertama klien memilih identiti: sijil yang dipasangkan dengan kunci persendirian yang boleh digunakan, tersedia melalui stor atau penyedia kelayakan yang disokong. Kemudian komponen VPN meminta operasi kriptografi dilakukan dengan kunci itu, dan model kebenaran setempat menjawab. Hanya selepas kedua-duanya berjaya, jabat tangan jauh berlaku, di mana Mac menilai gerbang dan gerbang menilai bukti klien.
| Decision | Typical symptom | Where to look |
|---|---|---|
| Identity selection | No valid identity, wrong certificate offered | Profile and which identity the client picked |
| Local key use | Signing or interaction error before any handshake | Execution context and key access rules |
| Remote authentication | Chain, name or client-admission rejection | Gateway identity and what it accepts |
Baca jadual dari atas ke bawah dan berhenti pada baris pertama yang gagal. Semua yang di bawah kegagalan tidak terbukti, itulah sebabnya “sijil itu tidak dipercayai” menjadi kesimpulan yang begitu biasa dan begitu tidak boleh diharap.
Apa yang sebenarnya diliputi oleh kebenaran setempat
Dalam model rantai kunci macOS, item yang dilindungi membawa peraturan akses khusus operasi dan senarai aplikasi yang dipercayai. Menandatangani dengan kunci persendirian ialah salah satu operasi itu, dan peraturan itu terpakai kepada fail boleh laku yang melakukannya, bukan kepada sijil sebagai dokumen. Rujukan kawalan akses Apple juga menarik garis antara model ini dan rantai kunci iCloud serta susunan kumpulan akses, jadi nasihat yang ditulis untuk satu tidak berpindah ke yang lain.
Dua akibat menyusul. Sijil awam yang kelihatan dalam senarai tidak membuktikan bahawa komponen latar VPN boleh mencapai kunci itu sama sekali. Dan kebenaran yang diberikan kepada aplikasi hadapan tidak berkata apa-apa tentang pembantu atau sambungan rangkaian yang berasingan, kerana ia kod berbeza dengan identiti berbeza.
Kenal pasti pelaksanaan sebenar dan mekanisme perkongsian kelayakan yang disokongnya, bukan menyalin laluan fail boleh laku daripada klien lama. Sahkan dahulu identiti mana yang akan ditawarkan oleh sistem:
security find-identity -v -p ssl-clientMembaca errSecInteractionNotAllowed
Status itu melaporkan interaksi yang tidak dibenarkan dengan Security Server, dan ia tidak berkata apa-apa tentang rantaian sijil. Bacalah bersama operasi yang menghasilkannya: permintaan tandatangan yang dikeluarkan daripada konteks yang tidak boleh memaparkan gesaan akan gagal dengan cara ini walaupun kunci dan sijil kedua-duanya sah sepenuhnya. Operasi yang merekodkannya, bukan stor sijil, ialah tempat untuk bermula. Apa sahaja yang anda ubah tentang sauh kepercayaan akan membiarkan ralat itu tepat di tempatnya.
Jadi anggap kod itu sebagai sebab untuk memeriksa konteks pelaksanaan dan kebenaran. Menganggapnya sebagai bukti bahawa CA gerbang tidak dipercayai membawa anda ke separuh masalah yang salah, dan perubahan yang anda buat di sana tidak akan menjejaskan ralat itu sama sekali.
Baiki secara sempit, bukan luas
Mulakan dengan arahan pendaftaran atau import milik pemilik sambungan. Catat versi klien, skop profil, identiti yang dipilih dan ralat setempat pertama yang berkaitan, kerana empat fakta itulah yang diperlukan oleh penyerahan kepada sokongan dan yang menjadi asas perbandingan kemudian. Profil terurus atau identiti yang disokong perkakasan mungkin memerlukan pentadbir atau penyedia membaiki penyerahan itu, dan tiada jumlah klik setempat yang menggantikannya.
Di tempat produk mengharapkan persetujuan pengguna, sahkan komponen mana yang meminta dan luluskan hanya akses itu melalui aliran yang disokong. Di tempat komponen tiada cara untuk memunculkan gesaan dalam konteks ia berjalan, peruntukan mesti mengikut laluan yang didokumenkan oleh vendor, bukan dialog yang ditarik keluar dari tetingkap terminal lain.
Dua perubahan digabungkan dalam nasihat lama, dan kedua-duanya terlalu luas. Memberi setiap aplikasi akses kepada kunci persendirian meluaskan penggunaan kunci setempat jauh melebihi keperluan, dan menetapkan sijil kepada Always Trust mengubah penilaian sijil untuk segala-galanya pada mesin. Tidak satu pun daripadanya menyatakan “pelaksanaan VPN yang diluluskan ini, menggunakan identiti yang dimaksudkan ini”.
Semak secara setempat sebelum membaca gerbang
Selepas pembaikan, sahkan bahawa operasi setempat berjaya sebelum anda mentafsir sebarang respons dari sebelah sana. Jika tandatangan kini berfungsi, penolakan nama, rantaian atau kemasukan klien selepas itu ialah hasil baharu dan bukan pengulangan, dan ia tergolong dalam keputusan lain dengan pemilik lain.
Penyerahan yang berguna menamakan keputusan mana antara tiga itu yang gagal dan berhenti di situ. Ia tidak pernah menyertakan kunci persendirian, dan ia tidak pernah menetapkan semula item rantai kunci yang tidak berkaitan dengan harapan bahawa keadaan bersih akan membantu. Tetapkan kedua-dua tabiat itu sebelum insiden dan bukan semasanya, ketika godaan untuk mencuba segala-galanya sekali gus paling kuat. Tiket yang berkata “rantai kunci dibina semula” hampir tidak memberitahu pembaca seterusnya apa-apa tentang kerosakan asalnya.