Anda bertanya: " Dapatkah seseorang menjelaskan mengapa masalah ini terjadi? "
Berdasarkan apa yang dilaporkan dalam FAQ OpenVPN resmi, saya yakin itu disebabkan oleh masalah perutean di dalam mesin OpenVPN.
Untuk lebih memperjelas skenario, izinkan saya merujuk ke diagram berikut:
Di sini Anda dapat melihat:
- "server" OpenVPN yang terhubung ke jaringan internal HEADQUARTER (10.0.1.0/24)
- "klien" OpenVPN yang berjalan di Situs Jarak Jauh, dan terhubung ke jaringan 192.168.1.0/24 jarak jauh
Juga
- kami mengasumsikan bahwa terowongan OpenVPN dibuat dan:
- OpenVPN "server" dapat dijangkau melalui antarmuka tun -nya sendiri , dengan alamat 10.10.0.1. Juga alamat P2P, yang digunakan oleh antarmuka tun adalah 10.10.0.2 ( ini penting untuk diskusi nanti, jadi mari kita tekankan )
- OpenVPN "klien" memiliki antarmuka tun dengan IP 10.10.0.2
Sekarang, mari kita asumsikan bahwa:
- OpenVPN "Client" telah mendefinisikan ulang gateway default-nya, jadi untuk mengarahkan ulang dalam terowongan semua lalu lintas IP keluar;
- OpenVPN "Client" telah mengaktifkan IP_FORWARDING dan, dengan demikian, dapat merutekan paket yang berasal dari LAN internal (192.168.1.0/24) ( Saya menekankan poin ini, karena ini sangat penting untuk diskusi kita ).
Dengan skenario seperti itu, mari kita periksa secara rinci apa yang terjadi ketika R_PC1 (192.168.1.2) mengirim paket, seperti permintaan gema, ke L_PC1 (10.0.1.2):
- setelah meninggalkan R_PC1 NIC, paket mencapai klien OpenVPN;
- Klien OpenVPN (yang dikonfigurasi untuk bertindak sebagai router umum), rutekan sesuai dengan tabel peruteannya. Karena default-gateway adalah tunnel, ia mengirim paket ke tunnel;
- Paket mencapai antarmuka tun dari server OpenVPN. OpenVPN akan "melihatnya" dan, karena (server OpenVPN) tahu bahwa 10.0.1.2 adalah alamat milik subnet LAN-nya, ia "meneruskan" paket, dari TUN ke LAN;
- Paket mencapai L_PC1.
Jadi semuanya baik-baik saja ...
Sekarang mari kita periksa apa yang terjadi dengan echo-reply yang L_PC1 balas ke R_PC1.
- echo-reply meninggalkan L_PC1 NIC dan mencapai antarmuka LAN server OpenVPN (10.0.1.1);
Sekarang, jika kita ingin OpenVPN Server dapat menjangkau situs jarak jauh, kita perlu mendefinisikan perutean dengan "rute statis". Sesuatu seperti:
route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.0.2
Harap perhatikan alamat P2P yang digunakan sebagai gateway .
Rute statis semacam itu akan beroperasi pada level OS. Dengan kata lain, sistem operasi diperlukan untuk merutekan paket dengan benar. Ini berarti sesuatu seperti: "Tolong, semua lalu lintas yang ditujukan ke subnet 192.168.1.0/24 perlu diteruskan ke mesin OpenVPN, yang dengannya OS dapat berbicara melalui alamat P2P". Berkat rute statis seperti itu, sekarang ...
- paket meninggalkan konteks OS-routing dan mencapai OpenVPN. Contoh OpenVPN berjalan pada Server OpenVPN. Jadi, pada titik ini, OS tidak ada lagi yang harus dilakukan dan semua perutean (dalam VPN) diserahkan kepada perangkat lunak server OpenVPN.
Jadi, sekarang, masalahnya adalah: bagaimana, perangkat lunak server openvpn, akan dapat memutuskan rute suatu paket, dengan SRC_IP 10.0.1.2 dan DST_IP 192.168.1.2 ?
Harap dicatat bahwa, berdasarkan konfigurasi server OpenVPN, ia tidak tahu apa - apa tentang jaringan 192.168.1.0/24, atau host 192.168.1.2. Itu bukan klien yang terhubung. Itu bukan klien lokal. Dan sebagainya? OpenVPN, juga, tahu bahwa itu bukan "OS-Router", jadi ia tidak benar-benar ingin (dan dapat ....) mengirim paket kembali ke gateway lokal. Jadi satu-satunya pilihan, di sini, adalah untuk meningkatkan kesalahan. Persis kesalahan yang Anda alami
Untuk mengatakannya dengan bahasa FAQ: " ... ia tidak tahu cara merutekan paket ke mesin ini, jadi ia menjatuhkan paket ... ".
Bagaimana kita bisa menyelesaikan masalah?
Seperti yang dapat Anda lihat dari dokumentasi resmi , opsi iroute persis melayani ruang lingkup kami:
--iroute network [netmask]
Generate an internal route to a specific client. The netmask
parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server
to a particular client, regardless of where the client is
connecting from. Remember that you must also add the route to the
system routing table as well (such as by using the --route
directive). The reason why two routes are needed is that the
--route directive routes the packet from the kernel to OpenVPN.
Once in OpenVPN, the --iroute directive routes to the specific
client.
Jadi, Anda membutuhkan:
--iroute 192.168.1.0 255.255.255.0
untuk diterapkan (ke server) ketika klien OpenVPN Anda terhubung, misalnya melalui file konfigurasi ad-hoc yang ditentukan pada server (client-config-dir, dll.).
Jika Anda bertanya-tanya mengapa masalah ini tidak terjadi pada langkah 2) di atas, pemahaman saya adalah bahwa Klien OpenVPN tahu cara merutekannya, karena ia tahu bahwa terowongan VPN adalah gateway default.
Hal yang sama tidak dapat dilakukan di OpenVPN Server, karena di sana gateway default tipically tidak diganti. Juga, pertimbangkan bahwa Anda dapat memiliki satu server OpenVPN dengan banyak klien OpenVPN: setiap klien tahu bagaimana menjangkau server tetapi ... bagaimana bisa, server, memutuskan klien mana yang bertindak sebagai gateway untuk subnet yang tidak dikenal?
Adapun pertanyaan pertama Anda ( Bisakah aturan yang diperlukan ditulis dengan cara generik / satu kali? ), Saya minta maaf tapi saya tidak mendapatkan masalah Anda. Bisakah Anda ulangi memberikan rincian lebih lanjut?