MULTI: alamat sumber buruk dari klien - ada solusi satu kali?

Setup: Saya memiliki setup klien / server openvpn (file konfigurasi di bagian bawah), dan saya mendapatkan MULTI: bad source address from client [192.168.x.x], packet droppedpesan terkenal di server. Server memiliki alamat IP publik, sementara klien berada di belakang NAT.

Kekurangan dari solusi yang diusulkan sebelumnya: Yang client-config-dirdidefinisikan dalam konfigurasi server saat ini kosong. Posting sebelumnya (di sini dan di forum dukungan openvpn) menyarankan untuk menambahkan file yang dinamai DEFAULTdengan aturan yang tepat client-config-dir, atau menambahkan file per pengguna dengan aturan tersebut untuk menyelesaikan masalah.

Namun, ini sepertinya bukan solusi jangka panjang, karena aturan ini khusus untuk lokasi klien. Jadi, saya bisa menambahkan aturan untuk memungkinkan klien 192.168.x.0untuk terhubung. Tetapi jika mereka terhubung dari jaringan lain yang digunakan 192.168.y.0untuk NAT, aturan baru akan diperlukan.

Pertanyaan:

• Bisakah aturan yang diperlukan ditulis secara generik / satu kali?
• Adakah yang bisa menjelaskan mengapa masalah ini terjadi?

Konfigurasi server:

port 1234
proto tcp
dev tun

ca ca.crt
cert openvpn.crt
key openvpn.key
dh dh2048.pem

server 10.78.96.0 255.255.255.0
keepalive 10 120
comp-lzo
cipher CAMELLIA-128-CBC

user nobody
group nogroup  
persist-key
persist-tun
client-cert-not-required
plugin /usr/lib/openvpn/openvpn-auth-pam.so login

status openvpn-status.log

push "redirect-gateway def1"
push "remote-gateway 1.2.3.4"
push "dhcp-option DNS 8.8.8.8"

client-config-dir ccd
verb 4

Konfigurasi klien:

ca ca.crt
client
dev tun
proto tcp
remote 1.2.3.4 1234

auth-user-pass
script-security 2
keepalive 5 60
topology subnet
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
cipher CAMELLIA-128-CBC
comp-lzo
verb 4

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):

1. setelah meninggalkan R_PC1 NIC, paket mencapai klien OpenVPN;
2. Klien OpenVPN (yang dikonfigurasi untuk bertindak sebagai router umum), rutekan sesuai dengan tabel peruteannya. Karena default-gateway adalah tunnel, ia mengirim paket ke tunnel;
3. 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;
4. 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.

5. 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 ...

6. 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?

Saya memiliki masalah yang tampaknya serupa, tetapi saya tidak yakin apakah itu sama dengan masalah Anda. Saya mencoba untuk melakukan ping dari klien openvpn ke komputer di jaringan lokal server openvpn (dialihkan dalam konfigurasi server), tidak mendapat balasan dan saya bisa melihat pesan "alamat sumber buruk" di log openvpn server.

Untuk mengatasinya, saya harus melakukan 2 hal:

1. Aktifkan penerusan ip di server.
2. Tambahkan rute untuk vpn subnet di gateway server, karena gateway untuk jaringan lokal server dalam kasus saya bukan server itu sendiri, tetapi router. Komputer ping mencoba membalas melalui gateway, yang tidak tahu apa yang harus dilakukan untuk subnet vpn. Jadi saya menambahkan rute statis di router menggunakan subnet vpn untuk tujuan, dan ip server openvpn sebagai gateway untuk itu.

Itu memperbaikinya bagi saya.