OpenVPN tanpa sijil klien: dasar pelayan, bukan profil

Anda memadam baris sijil dan kunci, menyerahkan profil, dan sambungan masih gagal dengan ralat sijil. Profil tidak pernah menjadi perkara yang menguatkuasakan syarat itu. Pelayan yang memutuskan sama ada sijil klien wajib, dan tiada suntingan di sebelah klien yang merundingkannya. Jadi pembetulannya ialah perubahan dasar pelayan, dilakukan dengan sengaja, dengan semua yang bergantung padanya dikemas kini dalam langkah yang sama.

Profil bukan dasar

Community OpenVPN 2.6 hadir dengan sijil klien wajib, kerana verify-client-cert secara lalai ialah require. Menetapkannya kepada none ialah yang menghentikan tuntutan sijil dan menyerahkan pengesahan klien kepada aturan nama pengguna dan kata laluan yang sudah dijalankan oleh pelayan. Panduan lama mencapai client-cert-not-required, ejaan lama bagi idea yang sama, jadi gunakan arahan yang didokumenkan oleh versi terpasang anda. Walau apa pun, perubahan berlaku di pelayan, dan tiada profil klien boleh melakukannya.

Serpihan di bawah ialah keseluruhan perubahan di sebelah pelayan, dan dengan sendirinya ia bukan konfigurasi pengesahan yang berfungsi. verify-client-cert none membuang syarat sijil, manakala username-as-common-name menjadikan nama akaun sebagai identiti yang dilihat oleh panggilan balik kemudian dan fail setiap klien. Tiada baris yang memeriksa kata laluan, jadi pengesah masih mesti wujud.

verify-client-cert none
username-as-common-name

Pengesah itu ialah pemalam atau skrip yang dikendalikan oleh auth-user-pass-verify, dan ia mesti ada sebelum mana-mana baris di atas bermakna apa-apa. Membalikkan urutan memberi anda tetingkap di mana pelayan tidak meminta sijil dan tidak memeriksa akaun.

Apa yang masih mengesahkan pelayan

Melepaskan sijil klien bukan bermakna melepaskan TLS. Pelayan menyimpan sijil dan kuncinya, dan klien menyimpan kepercayaan CA serta pemeriksaan nama hos yang menghalangnya daripada bercakap dengan penipu. Membuang remote-cert-tls server atau berkas CA kerana klien tidak lagi mempunyai sijil ialah salah baca yang biasa dan serius, dan rujukan 2.6 jelas menyatakan kedua-dua arah adalah bebas. Satu membuktikan pelayan kepada klien; yang lain membuktikan klien kepada pelayan.

Profil juga boleh membawa blok tls-auth atau tls-crypt. Itu kunci saluran kawalan dikongsi dengan kitaran pengedaran dan putarannya sendiri, jadi fail tanpa baris sijil atau kunci tidak selamat secara automatik untuk diterbitkan. Anggap ia sebagai rahsia sehingga anda membacanya.

Fail sijil yang disalin daripada profil yang berfungsi tidak membuktikan apa-apa dengan sendirinya; pemilikan bermakna memegang kunci peribadi yang sepadan dengannya, yang diperiksa oleh penggunaan yang disahkan sijil. Fail yang mengandungi sijil bukan fail yang boleh digunakan untuk mengesahkan.

Apa yang pengesah mesti lakukan

Setelah syarat sijil dibuang, semuanya bergantung pada pengesah: pemalam, atau skrip yang dikendalikan oleh auth-user-pass-verify. Ia mesti menolak kelayakan tidak sah, menolak akaun yang dilumpuhkan atau tidak layak, dan gagal tertutup apabila tidak dapat mencapai backendnya. username-as-common-name sering didayakan di sisinya, dan ia mengubah identiti yang dilihat oleh panggilan balik kemudian dan fail konfigurasi setiap klien. Ia tidak mengesahkan kata laluan, dan tidak menjadikan akaun yang tidak layak menjadi layak. Itu tugas berasingan, dan mencampurkannya ialah cara migrasi lulus ujian laluan gembiranya dan gagal pada insiden sebenarnya yang pertama.

Uji kes negatif sepenuh teliti seperti kes positif. Profil yang menunjukkan gesaan kata laluan hanya membuktikan klien boleh melukis gesaan, manakala pelayan yang menerima kata laluan yang salah membuktikan sesuatu yang jauh lebih buruk. Tambahkan akaun yang dilumpuhkan dan kelayakan yang tamat tempoh kepada set ujian, bukan hanya kata laluan yang buruk.

Ubah dasar, profil dan pemetaan bersama-sama

Selaraskan tiga perkara: arahan pelayan, profil klien, dan pemetaan identiti setiap klien. Ubah secara berasingan maka klien gagal sebelum pengesahan, atau bersambung dengan nama yang tidak dijangka oleh pentadbir, yang lebih buruk kerana ia kelihatan seperti kejayaan. Sambungan yang berjaya di bawah identiti yang salah lebih sukar disedari daripada yang gagal.

Kekalkan dua akaun ujian untuk laluan ini, satu sah dan satu yang diketahui buruk, dan gunakan kedua-duanya selepas sebarang perubahan pada pengesah. Akaun sah membuktikan laluan gembira dan pemetaan identiti; yang buruk membuktikan penolakan masih berfungsi. Tiada ujian yang memberitahu anda apa-apa tentang peraturan kelayakan, jadi tambahkan akaun yang sepatutnya ditolak atas sebab dasar jika penggunaan memilikinya. Jalankan ketiga-tiganya selepas setiap perubahan, kerana pengesah yang mula menerima segala-galanya kelihatan tepat seperti log masuk yang berfungsi.

Catat kaedah pengesahan yang benar-benar diterima oleh pelayan, bukan yang dicadangkan oleh profil. Catatan itu menjawab soalan yang orang terus tanyakan, iaitu siapa yang boleh bersambung ke perkhidmatan ini. Ia juga bertahan melebihi pentadbir seterusnya, yang jika tidak akan menemuinya semula daripada tangkapan paket.