Pengguna jauh tidak dapat mencapai tapak kedua melalui hab VPN

Pengguna jauh menyambung ke hab, mencapai pelayan fail pada LAN hab itu sendiri, dan semuanya kelihatan sihat. Kemudian dia membuka perkongsian pada 10.20.0.50 di ibu pejabat, yang dicapai hab melalui terowong tapak-ke-tapak berasingan, dan ia tamat masa. Kedua-dua terowong aktif dan kedua-dua pembilang meningkat, jadi tiada terowong rosak. Melintasi hab ialah tiga keputusan penghalaan pada tiga peranti, dan terowong hanya membawa awalan yang dibina untuknya. Inilah urutan yang saya periksa, dan arahan yang menunjukkan sama ada setiap langkah benar.

Lalu lintas memerlukan tiga carian, bukan satu terowong

Setiap peranti membuat padanan awalan terpanjangnya sendiri dan melupakannya. Komputer riba mesti menghantar 10.20.0.50 ke dalam terowong dan bukan kepada penghala tempatannya. Hab mesti mengambil paket yang tiba pada antara muka capaian jauh dan menyerahkannya kepada antara muka tapak-ke-tapak. Ibu pejabat mesti menghantar balasan untuk alamat pengguna kembali melalui terowong. Jika mana-mana satu daripada tiga gagal, ia kelihatan sama dalam pelayar: kesunyian.

Sebab itulah menguji setiap terowong secara berasingan membuktikan begitu sedikit. Ping ke alamat LAN hab melatih keputusan pertama, dan ping ke hab dari ibu pejabat melatih keputusan ketiga. Paket yang gagal mempunyai kumpulan pengguna sebagai sumber dan tapak kedua sebagai destinasi, jadi tuliskan awalan itu dahulu. Di sini kumpulannya 10.80.0.0/24, LAN hab 10.10.0.0/24 dan ibu pejabat 10.20.0.0/24.

Tolak awalan jauh kepada klien jauh

Pada OpenVPN pelayan capaian jauh, klien mempelajari laluan semasa menyambung. Tanpa push, klien dengan terowong berpisah menghantar 10.20.0.50 ke gatewaynya sendiri dan paket tidak pernah masuk ke terowong.

push "route 10.20.0.0 255.255.255.0"

Laluan yang ditolak berkuat kuasa apabila klien menyambung, jadi pengguna yang kekal dalam talian tidak melihat apa-apa sehingga dia menyambung semula. Sahkan pada klien: ip route get 10.20.0.50 pada Linux, route print pada Windows. Outputnya harus menamakan antara muka terowong.

Push tidak membantu hab. Ia mesej kepada klien, bukan laluan pada pelayan dan bukan kebenaran untuk menghantar, jadi hab dengan baris push yang sempurna masih menggugurkan aliran satu hop kemudian. Itulah sebab biasa orang membuat kesimpulan bahawa push gagal.

Berikan hab laluan keluar yang sebenar

Hab memerlukan hop seterusnya sendiri untuk awalan ibu pejabat. Pada terowong berpenghalaan, itu laluan biasa melalui antara muka tapak-ke-tapak, dan satu arahan menunjukkan laluan yang dipilih dan sumber yang dipilih:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Apabila bahagian tapak-ke-tapak itu sendiri OpenVPN, laluan boleh tinggal dalam konfigurasi itu dengan alamat terowong rakan sebagai gateway: route 10.20.0.0 255.255.255.0 172.30.0.2. Gateway itu bukan pilihan. Biarkan ia keluar dan hop seterusnya jatuh kepada nilai lalai pelaksanaan, yang berbeza antara klien satu rakan dan hab berbilang rakan.

IPsec berasaskan dasar berbeza: kernel hab menghantar paket ke gateway LAN biasanya dan dasar menangkapnya pada jalan keluar, jadi laluan terowong sama ada tidak melakukan apa-apa atau mengarahkan trafik melepasi dasar. Perhatikan sumber dalam arahan di atas, kerana 10.10.0.1 dan bukan alamat kumpulan bermakna kernel memilih alamat yang akan ditolak oleh sebelah jauh. iroute juga bukan jawapannya; ia memberitahu pelayan klien mana yang memiliki subnet di belakang terowongnya sendiri, bukan ke mana menghantar trafik untuk tapak ketiga.

Luaskan sebelah jauh kepada kumpulan pengguna

Ibu pejabat sudah meliputi LAN hab, 10.10.0.0/24. Kumpulan pengguna ialah awalan kedua dan mesti ada juga dalam pemilih, jika tidak tiada dasar meliputi balasan yang dialamatkan kepada 10.80.0.25. Setiap rakan menamakan pasangan set awalan yang sama dari sisinya:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

local_ts satu peranti ialah remote_ts peranti yang lain. Salin blok hab ke ibu pejabat dan pasangan itu terbalik, jadi child SA tidak pernah naik.

Sintaks ipsec.conf yang lebih lama menggunakan leftsubnet yang dipisahkan koma. Persatuan keselamatan yang berjalan mengekalkan pemilih yang dirundingkannya, jadi bina semula terowong selepas suntingan. Pemilih yang diubah pada 10:00 dan diuji terhadap SA yang naik pada 09:40 masih gagal, sedangkan fail konfigurasi kelihatan betul sepanjang masa.

Kemudian periksa hop terakhir. ip route get 10.80.0.25 pada titik akhir jauh sepatutnya menunjuk ke dalam terowong. Jika perkhidmatan menggunakan penghala LAN sebagai gateway lalai, penghala itu juga memerlukan laluan balik, jika tidak balasan mati di situ. tcpdump -ni eth1 host 10.80.0.25 pada segmen itu menunjukkan sama ada balasan keluar dari titik akhir.

Benarkan aliran pada hab

Penghantaran mesti diaktifkan dan laluan dibenarkan. Hadkan peraturan kepada dua awalan dan bukan menerima segala-galanya antara antara muka.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Penapisan laluan balik ialah kegagalan senyap di sebelahnya: apabila kedua-dua kaki berada pada antara muka berbeza, rp_filter=1 boleh menggugurkan balasan sementara pembilang peraturan terima tidak pernah bergerak. Bandingkan iptables -vnL FORWARD sebelum dan selepas percubaan. Peraturan yang tidak pernah bertambah tidak dicapai, jadi lihat satu lapisan lebih rendah daripada menulisnya semula.

Jika hanya satu kumpulan memerlukan lalu lintas, letakkan laluan dalam fail per klien di bawah client-config-dir dan bukan meluaskan push global. NAT sumber pada hab juga menghapuskan keperluan laluan balik sebelah jauh, tetapi ia menyembunyikan alamat pengguna, jadi log tapak jauh dan peraturan berasaskan alamat berhenti membezakan pengguna.

Sahkan dari klien, kemudian gulung balik dalam urutan terbalik

Uji port TCP, bukan hanya ICMP, kerana ping boleh lulus sementara perkhidmatan kekal disekat. nc -vz 10.20.0.50 445 dan traceroute -n 10.20.0.50 dari klien menunjukkan sama ada hop kedua ialah alamat terowong hab. Pada hab, tcpdump -ni tun0 host 10.20.0.50 dan penapis yang sama pada antara muka tapak-ke-tapak: permintaan pada kedua-duanya tanpa balasan pada mana-mana satu memindahkan masalah ke sebelah jauh.

Kemudian uji sesuatu yang mesti kekal disekat. Jika hos yang tidak sepatutnya dicapai oleh kumpulan juga menjawab, anda telah membuka lebih daripada lalu lintas dan patut menyempitkan peraturan. Hab yang menghantar segala-galanya ke setiap cabang lulus ujian pertama dan gagal ujian kedua.

Simpan senarai gulung balik, kerana empat objek berubah dan tiga mudah dilupakan: laluan yang ditolak, laluan hab, pemilih dan peraturan firewall. Batalkan dalam urutan terbalik, bina semula SA, dan minta seorang pengguna menyambung semula. Gulung balik separa meninggalkan laluan yang menunjuk ke terowong yang tidak lagi sepadan, yang lebih sukar dibaca daripada kesunyian asal. manual OpenVPN 2.6 mendokumenkan push, route dan iroute untuk versi anda.