Dua grup, dua profil akses, satu gateway VPN, dan pada akhirnya kedua grup mencapai server yang sama. Alasan biasanya bukan kebijakan yang rusak melainkan separuh kedua desain yang hilang: NPS memutuskan siapa yang boleh membangun sesi, dan sesuatu yang lain harus memutuskan apa yang boleh dicapai sesi itu. Ketika hanya separuh pertama yang ada, otorisasi berhasil bagi semua yang terautentikasi. Kebijakannya menjalankan tugasnya, dan desainnya masih belum lengkap.

Kebijakan jaringan yang cocok dengan grup adalah bukti tentang penerimaan. Itu bukan bukti tentang paket, dan celah antara kedua pernyataan itulah tempat sebagian besar pekerjaan ini terjadi.

Temukan kebijakan yang benar-benar menerima sesi

NPS mengevaluasi kebijakan jaringan yang berurutan, dan aturan aktif pertama yang kondisinya cocok yang menang. Kondisi dapat mencakup keanggotaan grup pengguna atau komputer, jenis koneksi, waktu, dan status perangkat. Karena itu kebijakan luas yang diletakkan lebih awal dalam daftar menerima koneksi sebelum aturan yang lebih sempit di bawahnya bahkan dipertimbangkan. Urutan bukan detail antarmuka; urutan adalah kebijakannya.

Baca daftar secara berurutan dan identifikasi yang cocok, lalu catat pengaturan apa yang dikembalikannya. Nama grup di editor bukan hasilnya; hasilnya adalah otorisasi yang diterima server. Pisahkan otorisasi pengguna dan otorisasi perangkat di tempat penerapan menggunakan keduanya, karena akun yang boleh membuka tunnel tidak otomatis merupakan akun yang seharusnya menjangkau setiap layanan internal.

Balasan RADIUS adalah instruksi, bukan filter

Atribut Filter-Id membawa nama daftar filter. Itu tidak mengirimkan kumpulan aturan filter paket portabel yang dipahami setiap penerima, dan mengirim nama yang tidak pernah didefinisikan gateway tidak menegakkan apa pun sama sekali. Kehati-hatian yang sama berlaku untuk atribut VLAN: menetapkan sesi tunnel ke sebuah VLAN dengan sendirinya bukan aturan akses terrutekan bagi pengguna itu.

Di sinilah desain yang tampak lengkap di sisi NPS diam-diam tidak melakukan apa pun. Pastikan dari dokumentasi vendor gateway atribut otorisasi mana yang didukung dan apa yang dilakukan penerima dengan masing-masingnya, alih-alih mengasumsikan bahwa nama atribut standar berarti perilaku standar.

Tempatkan penegakan di tempat lalu lintas lewat

Gateway yang memproses paket pengguna dapat menerapkan filter per sesi, memetakan grup ke kebijakan gateway, atau memberi sesi alamat dari kumpulan terpisah yang diperlakukan berbeda oleh firewall. Salah satu dari itu dapat berhasil, dan semuanya gagal dengan cara yang berbeda. Tentukan mekanisme mana yang didukung gateway Anda sebelum menulis kebijakan yang menyebutnya. Lalu tuliskan apa yang terjadi pada sesi ketika mekanisme itu tidak ada, karena diam adalah bawaan.

Jelaskan izin yang dimaksud dalam empat bagian: identitas sumber atau grup, tujuan, protokol, dan port. Tambahkan dependensi yang benar-benar dibutuhkan pengguna, seperti DNS atau layanan autentikasi, jika tidak pembatasan akan merusak alur masuk yang tidak terpikir untuk diuji. Tulis aturan terhadap antarmuka yang benar-benar memfilter, bukan terhadap antarmuka yang kebetulan terbuka di editor.

Pertimbangkan juga penerjemahan alamat. Jika firewall di hilir melihat satu alamat sumber yang diterjemahkan untuk setiap pengguna tunnel, itu tidak dapat membedakan individu hanya dari alamat itu, dan aturan yang ditulis seolah-olah bisa akan menjadi tidak berguna atau terlalu luas.

Profil klien berada di sisi yang tidak tepercaya

Profil VPN terkelola dapat mendorong rute, aturan tunnel terpisah, atau filter aplikasi, dan itu membentuk bagaimana perangkat yang berperilaku baik bertindak. Itu bukan perlindungan bagi layanan, karena klien adalah pihak yang Anda coba batasi. Menghapus rute dalam profil juga bukan otorisasi, karena klien mungkin memiliki jalur lain ke tujuan yang sama.

Perlakukan pengaturan klien sebagai kenyamanan dan pengaturan gateway sebagai kendali. Ketika keduanya berbeda pendapat, gateway yang benar karena dialah yang melihat paket.

Terima dengan dua akun, lalu telusuri secara berurutan

Buat dua akun uji biasa dengan izin yang dimaksud berbeda, bangun sesi baru, dan periksa kebijakan gateway yang efektif untuk masing-masing. Lalu uji satu operasi diizinkan yang tidak berbahaya dan satu sumber daya yang secara khusus ditolak. Ping yang gagal membuktikan sangat sedikit dengan sendirinya, karena ICMP mungkin difilter sementara layanan TCP di belakangnya menjawab dengan senang.

Ketika kedua akun masih mendapat akses luas, telusuri dalam urutan tetap: kebijakan mana yang cocok, otorisasi apa yang dibawa balasan, dan apa yang dilakukan gateway dengannya. Menambahkan lebih banyak atribut NPS sebelum memastikan penerima mengimplementasikannya adalah cara masalah otorisasi kecil menjadi jendela perubahan tanpa hasil.

Artikel terkait