Profil yang berfungsi di satu desktop adalah uji berhasil untuk satu klien. Itu bukan penyebaran lintas platform, dan memperlakukannya demikian menghasilkan pola dukungan yang sudah dikenal: Windows terhubung, ponsel gagal pada pemeriksaan identitas, dan laptop terkelola menyambung ulang setiap kali bangun. Perbedaannya nyata dan sebagian besar dapat diprediksi, karena itu rencananya harus berupa matriks, bukan tangkapan layar.

Tentukan dulu kontrak identitas

Dokumentasikan identitas server, kepercayaan sertifikat, dan metode autentikasi klien sebelum membahas algoritme. Ketiganya menentukan apakah klien dapat mengautentikasi sama sekali, dan itulah bagian yang diungkapkan platform secara berbeda.

Periksa bagaimana setiap platform menamai pengenal yang diharapkan dan bagaimana ia menangani nama alternatif subjek. Profil yang menerima nama server pada satu klien mungkin menolak sertifikat yang sama pada klien lain karena kolom pengenal diisi dari nilai yang berbeda.

Contract elementWhat to decideWhere platforms diverge
Server identityName or address the client must seeIdentifier field and SAN matching
Client authenticationCertificate, EAP method or bothWhich EAP variants exist and how prompts appear
Trust anchorWhich CA and how it is deliveredStore location and provisioning path

Lalu pilih irisan kriptografis

Bandingkan proposal yang dapat ditawarkan setiap klien yang didukung dan pilih irisan modern yang juga diizinkan gateway. Jangan aktifkan daftar lama yang kebesaran agar satu perangkat lama terhubung, karena daftar itu menjadi default gateway bagi semua yang menyusul. Catat mengapa setiap opsi lama masih ada. Jika tidak ada yang dapat menyebutkan perangkat yang membutuhkannya, itu bukan persyaratan.

Pisahkan pengaturan IKE dan CHILD dalam rencana. Proposal yang dapat diterima untuk pertukaran IKE tidak otomatis dapat diterima untuk lalu lintas terlindungi, dan keduanya dinegosiasikan terpisah. Gateway yang menerima proposal pada satu lapisan masih dapat menolaknya pada lapisan lain, dan log akan menunjukkan kegagalan yang tampak seolah lapisan pertama berhasil.

Sediakan kredensial melalui proses yang terverifikasi, dan simpan kata sandi pengguna, rahasia bersama, serta kunci privat klien di kolomnya sendiri. Coba-coba pada kotak dengan nama serupa adalah cara uji yang berfungsi menjadi tidak dapat direproduksi.

Uji siklus hidup, bukan keadaan stabil

Untuk setiap klien, uji autentikasi awal, aplikasi yang dimaksud, resolusi DNS, dan cakupan keluarga alamat. Lalu latih bagian yang hanya muncul belakangan: pembaruan, tidur, dan perubahan jaringan normal.

Dukungan MOBIKE dan perilaku autentikasi ulang dapat berbeda dari hasil stabil yang baru saja Anda ukur. Catat peristiwa dan status asosiasi pada saat itu, bukan hanya apakah antarmuka akhirnya terlihat terhubung.

Tentukan apa yang boleh dilakukan lalu lintas langsung saat VPN tidak tersedia. Itu keputusan kebijakan terpisah dari apakah klien menyambung ulang, dan sebagian besar penyebaran menjawab pertanyaan kedua sambil mengabaikan yang pertama. Tulis jawabannya di catatan penyebaran di samping nama profil. Seseorang akan membutuhkannya saat gangguan, dan ia tidak akan punya waktu untuk merekonstruksinya.

Gunakan pemeriksaan identitas server saat satu platform tidak setuju

Ketika profil berfungsi di satu platform dan platform lain menolak namanya, bandingkan pengenal yang benar-benar dikirim klien dengan pengenal yang dibawa sertifikat. Perbandingan itu menyelesaikan sebagian besar kasus ini lebih cepat daripada mengubah daftar cipher.

Simpan matriks yang diuji bersama sumber konfigurasi dan prosedur pembaruan. Saat dukungan untuk klien lama berakhir, hapus pengecualiannya dengan sengaja alih-alih membiarkan pengaturan kompatibilitas yang lebih lemah tersembunyi di gateway untuk ditemukan audit berikutnya. Dokumentasi IKEv2 strongSwan adalah referensi berguna tentang cara pertukaran dikonfigurasi.

Artikel terkait