Mengapa klien OpenVPN terlepas pemilih IPsec gateway

Ping hos di belakang terowong IPsec jauh dari gateway dan ia menjawab dengan bersih, jadi terowong kelihatan sihat dan tiket bergerak. Kemudian klien yang bersambung mencuba hos yang sama dan tidak menerima apa-apa balasan. Ping itu tidak pernah menjadi bukti bagi aliran klien, kerana ia keluar dengan alamat sumber gateway sendiri dan sepadan dengan pemilih IPsec yang berbeza. Memahami mengapa kedua-dua kes berbeza ialah sebahagian besar pembaikan.

Ping gateway menguji aliran yang klien anda tidak pernah guna

Alamat sumber menentukan dasar mana yang terpakai. Paket yang dijana pada gateway keluar dengan alamat dari LAN tempatannya atau dari titik akhir terowongnya, dan dasar yang sepadan dengannya ditulis khusus untuk kes itu. Paket klien tiba di antara muka OpenVPN dengan alamat dari kumpulan klien, yang merupakan pemilih yang sama sekali berbeza.

Sebab itu kegagalan kelihatan seperti masalah penghalaan sedangkan sebenarnya masalah skop dasar. Kebolehsampaian dari gateway membuktikan rakan sebaya aktif dan cadangan telah dirunding, dan ia tidak membuktikan apa-apa tentang sama ada kumpulan itu dilindungi.

Tolak awalan jauh yang benar-benar diperlukan aplikasi

Ambil pasangan ilustratif 10.8.0.0/24 untuk klien bersambung dan 172.30.239.0/25 untuk rangkaian jauh yang dilindungi. Apa yang klien perlukan ialah laluan ke awalan kedua itu, bukan ke LAN gateway dan bukan ke alamat terowong lain. Laluan yang ditolak ke kumpulan itulah yang membuat klien menyerahkan trafik itu kepada gateway. Tanpanya, paket tidak akan sampai ke keputusan dasar yang anda nyahpepijat.

Pada pelayan Community yang menerima laluan yang ditolak, arahan itu mengambil topeng sebenar: push "route 172.30.239.0 255.255.255.128". Access Server mengkonfigurasi destinasi yang sama melalui tetapan rangkaian peribadi atau peraturan akses versi yang dipasang, dengan mod dihalakan atau diterjemah dipilih secara sedar. Menyunting rantai tembok api yang dijana dan bukannya konfigurasi pemilik ialah cara pemasangan yang berfungsi menjadi mustahil untuk dihasilkan semula.

Selepas bersambung, baca jadual penghalaan klien dan bukan niat pelayan. Laluan yang hanya meliputi kumpulan bermakna tolakan itu tidak pernah tiba, dan laluan lalai melalui terowong lebih luas daripada keperluan ini dan akan mengejutkan anda kemudian. Semak topeng dan juga awalan, kerana /25 yang ditolak sebagai /24 menghantar trafik alamat jiran ke laluan yang tidak dapat membawanya. Kemudian pastikan klien memilih antara muka terowong untuk destinasi itu.

Jadikan pemilih merangkumi kumpulan klien

Untuk akses dihalakan yang mengekalkan alamat klien, dasar IPsec mesti melindungi trafik antara kumpulan dan awalan jauh. Pemilih yang ditulis untuk LAN gateway sendiri meluluskan ping dan menggugurkan permintaan klien, dan itulah tepatnya asimetri yang memulakan siasatan ini.

Periksa dasar yang dirunding serta cadangan yang dikonfigurasi, contohnya dengan ipsec statusall pada strongSwan atau arahan status yang setara untuk pelaksanaan anda. Dalam IPsec berasaskan dasar, laluan biasa boleh menunjuk ke antara muka fizikal sementara trafik yang sepadan masih disulitkan, jadi peranti terowong yang tiada tidak membuktikan apa-apa. Bandingkan pasangan pemilih dengan kumpulan dan awalan yang anda catat.

NAT sumber generik pada gateway juga boleh memecahkan padanan. Jika peraturan masquerade menulis semula sumber klien sebelum semakan dasar, paket itu tidak lagi kelihatan seperti pemilih yang anda tulis. Itu salah satu sebab peraturan masquerade yang luas ialah pembaikan yang buruk untuk VPN kedua: ia mengubah dasar mana yang terpakai dan alamat mana yang direkod oleh pihak jauh. Kecualikan trafik yang anda mahu halakan, atau terjemahkannya secara sedar dan kemas kini pemilih.

Pilih penghalaan atau terjemahan dengan sengaja

Penghalaan mengekalkan alamat klien kelihatan kepada pihak jauh, jadi log jauh dan peraturan mengikut sumber kekal bermakna, dan ia memerlukan gateway jauh mengetahui laluan balik ke kumpulan. Terjemahan menyembunyikan kumpulan di sebalik satu alamat, yang menghapuskan masalah laluan balik dan memusnahkan identiti setiap klien.

Pilih satu reka bentuk dan tuliskan, kerana kedua-duanya memerlukan pemilih berbeza dan susunan tembok api berbeza. Masquerade yang digunakan separuh terletak di antara keduanya dan tidak memuaskan mana-mana. Pilihan yang ditulis juga yang membolehkan jurutera seterusnya membezakan pepijat daripada keputusan yang disengajakan.

Tutup gelung pada penghantaran dan balasan

Gateway mesti menghantar protokol dan destinasi yang anda maksudkan, yang bererti penghantaran IP dihidupkan dan rantai penghantaran yang membenarkan pasangan itu. Pihak jauh kemudian mesti menghantar balasan kembali melalui laluan IPsec, dan itu keputusan penghalaan pada gateway mereka, bukan pada anda. Kedua-dua bahagian ialah konfigurasi biasa, dan kedua-duanya mudah ditinggalkan separuh siap. Uji secara berasingan supaya peraturan penghantaran yang hilang tidak disangka terowong rosak.

Sahkan dengan satu permintaan sebenar dari klien ke aplikasi, sambil memerhati ia melintasi antara muka OpenVPN, keputusan IPsec dan hos jauh. Periksa balasan sebagai pemerhatian berasingan, kerana permintaan yang tiba dan balasan yang tidak pernah kembali kelihatan sama dari tempat duduk klien. Satu permintaan yang dijejaki lebih bernilai daripada berapa banyak ping pun dari gateway.

Kekalkan kebenaran destinasi sempit semasa menguji, dan sahkan bahawa klien tanpa peraturan itu tidak dapat mencapai perkhidmatan. Laluan yang dipasang bersama persatuan yang terbentuk bukanlah sama dengan akses yang diberikan.