Dua identiti dalam satu log masuk IKEv2: mesin dahulu, kemudian pengguna

Sijil klien disahkan, pertukaran pertama selesai, dan kemudian sambungan berhenti dengan ralat tentang pusingan pengesahan tambahan. Tiada apa yang salah dalam rantaian sijil dan tiada apa yang berubah dalam rangkaian. Gateway dikonfigurasikan untuk menuntut bukti kedua daripada pihak yang menyambung, dan klien tidak pernah menghantarnya. Memutuskan siapa membuktikan apa, dan dalam urutan apa, ialah keseluruhan tugas, dan ia bermula dengan membaca dasar dari titik akhir tempat anda berdiri. Dua bukti berlainan jenis, dalam urutan tetap, ialah keputusan reka bentuk dan bukan kotak semak.

Gejalanya: kegagalan selepas bukti pertama yang berjaya

Pertukaran pertama selesai dan log kelihatan sihat, sehingga gateway meminta identiti pengguna melalui EAP. Kemudian jabat tangan terhenti atau memulangkan ralat protokol yang menamakan pusingan tambahan. Sijil mesin yang sah sepenuhnya ditolak atas sebab yang tiada kaitan dengan kesahihannya. Dasar meminta bukti kedua, dan jawapan klien tidak pernah tiba.

Kedua-dua huraian kegagalan itu tepat bergantung pada tempat anda berdiri. Dari sisi klien ia kelihatan seperti pelayan yang menolak sijil sah, dan dari sisi pelayan ia kelihatan seperti klien yang tidak dapat menyelesaikan log masuk. Peristiwa yang sama dibaca sebagai masalah kepercayaan dalam satu log dan masalah keupayaan dalam log yang lain. Hanya dasar yang dikonfigurasikan memberitahu anda yang mana satu.

Apa yang ditambah oleh sambungan itu dan apa yang tidak

IKEv2 membawa sambungan untuk menjalankan lebih daripada satu pertukaran pengesahan dalam satu sesi. RFC 4739 menggariskan, antara urutan lain, klien yang membuktikan identiti sijil dan kemudian mengesahkan seseorang melalui EAP. Dokumen itu berstatus Experimental, bermakna tiada pelaksanaan yang terhutang budi kepada anda dengan ciri ini. Jangan andaikan apa-apa tentang sokongan sehingga rakan berunding untuknya.

Kedua-dua pihak mesti menyokong sambungan itu dan bersetuju mengenainya semasa pertukaran. Gateway yang dikonfigurasikan untuk pusingan kedua tidak boleh memaksa klien melakukannya, dan klien yang menyokongnya tidak akan menggunakannya melainkan pelayan memintanya. Asimetri itulah sebabnya kegagalan biasanya muncul sebagai tamat masa atau ralat protokol dan bukannya kenyataan jelas tentang keupayaan. Membaca konfigurasi satu pihak memberitahu anda separuh daripada apa yang akan berlaku.

Satu bukti bagi setiap titik akhir ialah bentuk biasa, dan ini bukan reka bentuk itu. Gateway membentangkan sijilnya, pengguna menjawab melalui EAP, dan setiap pihak telah mengesahkan pihak lain tepat sekali. Kedua-dua bukti itu datang dari titik akhir yang bertentangan, jadi tidak satu pun menyatakan apa-apa yang berasingan tentang mesin dan orang yang menggunakannya.

EAP-TLS ialah bentuk ketiga, dan ia juga bukan ini. Di sana sijil klien dibentangkan di dalam kaedah EAP, jadi klien masih menyelesaikan satu pengesahan IKE. Kelayakan boleh kelihatan sama seperti kes berbilang pusingan sementara protokol membawa satu pusingan dan bukannya dua. Itulah sebabnya reka bentuk yang disalin daripada penggunaan EAP-TLS gagal tepat pada titik di mana bukti kedua dijangka.

Fail yang sama dibaca berbeza pada gateway

Fail swanctl yang sama dibaca secara berbeza bergantung pada tempat ia berjalan, dan itulah bahagian yang membuat orang tersandung. Pada komputer riba gateway ialah rakan, dan pada gateway komputer riba ialah rakan, jadi tulis sisi local sebagai siapa saya dan sisi remote sebagai siapa yang akan saya terima. Blok local menghuraikan bagaimana titik akhir ini mengesahkan dirinya, dan blok remote menyatakan apa yang dituntutnya daripada hujung yang lain. Menyalin blok antara dua fail membalikkan maksudnya tanpa mengubah satu aksara pun. Membandingkan kedua-dua fail hampir tidak memberitahu apa-apa, kerana perkataan yang sama bermaksud berlawanan dalam setiap satu.

Kedudukan sesuatu bahagian menetapkan urutannya melainkan nombor pusingan mengatasinya. Oleh itu bahagian local atau remote tambahan menghuraikan pusingan tambahan dan bukan alternatif, dan nombor pusingan eksplisit dalam rujukan swanctl.conf wujud semata-mata untuk menjadikan urutan itu disengajakan. Tanpanya, memindahkan blok mengubah tingkah laku. Itulah sebabnya dua konfigurasi yang kelihatan setara di atas kertas boleh bertindak dalam urutan berlawanan.

Peraturan urutan itu menghasilkan mod kegagalan yang wajar diingat. Blok remote kedua bukan pilihan lain yang boleh diterima; ia tuntutan kedua, itulah sebabnya dasar yang dibaca seperti sama ada/atau bertindak seperti dan-kemudian. Dasar gateway boleh menerima sijil mesin yang berdaftar dan kemudian menuntut pertukaran EAP pengguna itu, dalam urutan itu.

Bezakan pusingan daripada faktor bebas

Dua pusingan tidak semestinya dua faktor bebas. Mengulang bukti, atau menyimpan dua kelayakan dalam stor yang sama, tidak memberikan kekuatan yang sepatutnya ditambah oleh reka bentuk itu. Kebebasan ialah sifat bagaimana rahsia disimpan dan apa yang menjejaskannya, bukan berapa banyak pertukaran yang dijalankan oleh protokol. Reka bentuk yang mengira pusingan sebagai faktor melebih-lebihkan apa yang dimilikinya. Perbezaan itu paling penting apabila soalan pematuhan bertanya berapa banyak faktor yang sebenarnya digunakan oleh log masuk.

Sijil mesin membuktikan pemilikan kuncinya yang diterima, dan tidak lebih. Ia bukan atestasi perkakasan dan bukan laporan kesihatan peranti, jadi dasar yang memerlukan maklumat postur memerlukan mekanisme lain. Medan subject juga bukan label inventori yang boleh dipercayai, kerana subject dipilih oleh sesiapa yang mengeluarkan atau mendaftarkan sijil itu. Jika reka bentuk memerlukan bukti bahawa mesin itu sihat, bukti itu mesti datang daripada komponen yang mengukur mesin.

Tuliskan apa yang sebenarnya dibuktikan oleh setiap pusingan sebelum menambahnya. Apabila dua pusingan membuktikan perkara yang sama dua kali, yang kedua menambah kependaman dan tiket sokongan dan bukannya jaminan. Nota itu juga yang menghentikan perdebatan tentang sama ada pusingan tambahan itu berbaloi dengan kosnya.

Tulis peraturan pemasangan dan uji penolakannya

Putuskan identiti mesin mana yang boleh dipasangkan dengan orang yang mana, dan tulis peraturan itu di tempat penguatkuasaan berada. Dua kelayakan sah yang bersebelahan tidak membuktikan apa-apa tentang pemasangan, kerana pemasangan ialah keputusan kebenaran dan bukan hasil pengesahan. Rekod pendaftaran atau backend pengesahan mesti menguatkuasakan hubungan yang dikehendaki oleh organisasi.

Kemudian uji apa yang sepatutnya gagal: pengguna yang diterima pada mesin yang tidak diluluskan, pengguna yang tidak diluluskan yang memegang kelayakan mesin, dan rakan yang tidak dapat melakukan pusingan tambahan. Jika ketiga-tiganya menerima akses yang sama secara senyap, dasar itu menghuraikan niat dan bukannya menguatkuasakannya. Bandingkan konfigurasi yang diisytiharkan dengan apa yang dilaporkan oleh daemon, kerana sambungan yang tidak pernah sepadan kelihatan sama seperti peraturan yang lulus:

swanctl --list-conns
swanctl --list-sas

Periksa pusingan yang dirundingkan dan kebenaran yang terhasil, bukan hanya log masuk yang berjaya. Dan jangan mencapai tetapan IKEv1 XAuth lama sebagai jalan pintas: padankan protokol, peranan, urutan dan tingkah laku sebenar klien dan bukannya memadam pusingan yang diperlukan sehingga sambungan berjaya. Memadam pusingan yang gagal ialah cara reka bentuk dua bukti secara senyap menjadi reka bentuk satu bukti yang tidak disemak oleh sesiapa. Simpan pemadaman itu dalam rekod perubahan.