Mengapa klien OpenVPN melewatkan selektor IPsec gateway

Ping host di balik tunnel IPsec jarak jauh dari gateway dan ia menjawab dengan bersih, jadi tunnel tampak sehat dan tiket berlanjut. Lalu klien yang terhubung mencoba host yang sama dan tidak mendapat balasan apa pun. Ping itu tidak pernah menjadi bukti bagi alur klien, karena keluar dengan alamat sumber milik gateway sendiri dan cocok dengan selektor IPsec yang berbeda. Memahami mengapa kedua kasus berbeda adalah sebagian besar perbaikannya.

Ping gateway menguji alur yang tidak pernah dipakai klien Anda

Alamat sumber yang menentukan kebijakan mana yang berlaku. Paket yang dibuat di gateway keluar dengan alamat dari LAN lokalnya atau dari titik akhir tunnelnya, dan kebijakan yang cocok dengannya ditulis persis untuk kasus itu. Paket klien tiba di antarmuka OpenVPN dengan alamat dari kumpulan klien, yang merupakan selektor yang sama sekali berbeda.

Itu sebabnya kegagalan tampak seperti masalah perutean padahal sebenarnya masalah cakupan kebijakan. Keterjangkauan dari gateway membuktikan peer aktif dan proposal telah dinegosiasikan, dan tidak membuktikan apa pun tentang apakah kumpulan itu terlindungi.

Dorong prefiks jarak jauh yang benar-benar dibutuhkan aplikasi

Ambil pasangan ilustratif 10.8.0.0/24 untuk klien yang terhubung dan 172.30.239.0/25 untuk jaringan jarak jauh yang dilindungi. Yang dibutuhkan klien adalah rute ke prefiks kedua itu, bukan ke LAN gateway dan bukan ke alamat tunnel lain. Rute yang didorong ke kumpulan itulah yang membuat klien menyerahkan lalu lintas itu ke gateway. Tanpanya, paket tidak akan pernah mencapai keputusan kebijakan yang sedang Anda debug.

Di server Community yang menerima rute yang didorong, direktifnya memakai mask yang sebenarnya: push "route 172.30.239.0 255.255.255.128". Access Server mengonfigurasi tujuan yang sama melalui pengaturan jaringan privat atau aturan akses versi yang terpasang, dengan mode dirutekan atau diterjemahkan dipilih secara sadar. Menyunting rantai firewall yang dihasilkan alih-alih konfigurasi pemiliknya adalah cara sebuah penyiapan yang berfungsi menjadi mustahil direproduksi.

Setelah terhubung, baca tabel perutean klien, bukan niat server. Rute yang hanya mencakup kumpulan berarti dorongan tidak pernah tiba, dan rute default melalui tunnel lebih luas dari kebutuhan ini dan akan mengejutkan Anda nanti. Periksa mask sekaligus prefiks, karena /25 yang didorong sebagai /24 mengirim lalu lintas alamat tetangga ke jalur yang tidak dapat membawanya. Lalu pastikan klien memilih antarmuka tunnel untuk tujuan itu.

Buat selektor menyertakan kumpulan klien

Untuk akses dirutekan yang mempertahankan alamat klien, kebijakan IPsec harus melindungi lalu lintas antara kumpulan dan prefiks jarak jauh. Selektor yang ditulis untuk LAN gateway sendiri meloloskan ping dan membuang permintaan klien, dan itulah tepatnya asimetri yang memulai penyelidikan ini.

Periksa kebijakan yang dinegosiasikan serta proposal yang dikonfigurasi, misalnya dengan ipsec statusall pada strongSwan atau perintah status yang setara untuk implementasi Anda. Pada IPsec berbasis kebijakan, rute biasa dapat menunjuk ke antarmuka fisik sementara lalu lintas yang cocok tetap terenkripsi, jadi tidak adanya perangkat tunnel tidak membuktikan apa pun. Bandingkan pasangan selektor dengan kumpulan dan prefiks yang Anda catat.

NAT sumber generik di gateway juga dapat merusak kecocokan. Jika aturan masquerade menulis ulang sumber klien sebelum pemeriksaan kebijakan, paket tidak lagi tampak seperti selektor yang Anda tulis. Itu salah satu alasan aturan masquerade yang lebar adalah perbaikan yang buruk untuk VPN kedua: ia mengubah kebijakan mana yang berlaku dan alamat mana yang dicatat sisi jauh. Kecualikan lalu lintas yang ingin Anda rutekan, atau terjemahkan dengan sengaja dan perbarui selektornya.

Pilih perutean atau penerjemahan dengan sengaja

Perutean menjaga alamat klien tetap terlihat oleh sisi jauh, sehingga log jarak jauh dan aturan per sumber tetap bermakna, dan itu menuntut gateway jarak jauh mengetahui jalur balik ke kumpulan. Penerjemahan menyembunyikan kumpulan di balik satu alamat, yang menghapus masalah rute balik dan menghancurkan identitas per klien.

Pilih satu desain dan tuliskan, karena keduanya membutuhkan selektor berbeda dan urutan firewall berbeda. Masquerade yang diterapkan setengah berada di antaranya dan tidak memuaskan keduanya. Pilihan yang tertulis juga yang memungkinkan insinyur berikutnya membedakan bug dari keputusan yang disengaja.

Tutup lingkaran pada penerusan dan balasan

Gateway harus meneruskan protokol dan tujuan yang Anda maksud, yang berarti penerusan IP aktif dan rantai penerusan yang mengizinkan pasangan itu. Sisi jauh kemudian harus mengirim balasan kembali melalui jalur IPsec, dan itu keputusan perutean di gateway mereka, bukan di gateway Anda. Kedua belah pihak adalah konfigurasi biasa, dan keduanya mudah tertinggal setengah jadi. Uji secara terpisah agar aturan penerusan yang hilang tidak dikira tunnel rusak.

Verifikasi dengan satu permintaan nyata dari klien ke aplikasi, sambil mengamati permintaan itu melewati antarmuka OpenVPN, keputusan IPsec, dan host jarak jauh. Periksa balasannya sebagai pengamatan terpisah, karena permintaan yang tiba dan balasan yang tidak pernah kembali terlihat sama dari tempat klien. Satu permintaan yang dilacak lebih bernilai daripada berapa pun ping dari gateway.

Jaga otorisasi tujuan tetap sempit selama pengujian, dan pastikan klien tanpa aturan itu tidak dapat mencapai layanan. Rute yang terpasang plus asosiasi yang terbentuk tidak sama dengan akses yang diberikan.