Pengguna jarak jauh tidak dapat menjangkau situs kedua melalui hub VPN

Seorang pengguna jarak jauh terhubung ke hub, mencapai server file di LAN hub itu sendiri, dan semuanya tampak sehat. Lalu ia membuka share di 10.20.0.50 di kantor pusat, yang dijangkau hub melalui tunnel site-to-site terpisah, dan koneksinya timeout. Kedua tunnel aktif dan kedua penghitung naik, jadi tidak ada tunnel yang rusak. Melintasi hub adalah tiga keputusan routing pada tiga perangkat, dan tunnel hanya membawa prefiks yang menjadi tujuan pembangunannya. Berikut urutan yang saya periksa, dan perintah yang menunjukkan apakah setiap langkah benar.

Transit memerlukan tiga pencarian, bukan satu tunnel

Setiap perangkat melakukan pencocokan prefiks terpanjangnya sendiri dan melupakannya. Laptop harus mengirim 10.20.0.50 ke dalam tunnel, bukan ke router lokalnya. Hub harus mengambil paket yang tiba di antarmuka akses jarak jauh dan menyerahkannya ke antarmuka site-to-site. Kantor pusat harus mengirim balasan untuk alamat pengguna kembali melalui tunnel. Jika salah satu dari ketiganya gagal, tampilannya sama di browser: keheningan.

Itulah sebabnya menguji setiap tunnel secara terpisah membuktikan begitu sedikit. Ping ke alamat LAN hub melatih keputusan pertama, dan ping ke hub dari kantor pusat melatih keputusan ketiga. Paket yang gagal memiliki kumpulan pengguna sebagai sumber dan situs kedua sebagai tujuan, jadi tuliskan prefiks itu lebih dulu. Di sini kumpulannya 10.80.0.0/24, LAN hub 10.10.0.0/24, dan kantor pusat 10.20.0.0/24.

Dorong prefiks jauh ke klien jarak jauh

Pada OpenVPN server akses jarak jauh, klien mempelajari rute saat terhubung. Tanpa push, klien dengan tunnel terpisah mengirim 10.20.0.50 ke gateway-nya sendiri dan paket tidak pernah masuk ke tunnel.

push "route 10.20.0.0 255.255.255.0"

Rute yang didorong berlaku saat klien terhubung, jadi pengguna yang tetap online tidak melihat apa pun sampai terhubung ulang. Verifikasi di klien: ip route get 10.20.0.50 di Linux, route print di Windows. Keluarannya harus menyebut antarmuka tunnel.

Push tidak membantu hub. Itu pesan ke klien, bukan rute di server dan bukan izin untuk meneruskan, jadi hub dengan baris push yang sempurna tetap menjatuhkan aliran satu hop kemudian. Itulah alasan biasa orang menyimpulkan push gagal.

Beri hub rute keluar yang nyata

Hub memerlukan hop berikutnya sendiri untuk prefiks kantor pusat. Pada tunnel yang dirutekan, itu rute biasa melalui antarmuka site-to-site, dan satu perintah menunjukkan rute yang dipilih serta 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

Ketika kaki site-to-site itu sendiri OpenVPN, rute dapat berada di konfigurasi itu dengan alamat tunnel peer sebagai gateway: route 10.20.0.0 255.255.255.0 172.30.0.2. Gateway tidak opsional. Biarkan kosong dan hop berikutnya jatuh ke nilai bawaan implementasi, yang berbeda antara klien peer tunggal dan hub multi-peer.

IPsec berbasis kebijakan berbeda: kernel hub mengirim paket ke gateway LAN normalnya dan kebijakan menangkapnya saat keluar, jadi rute tunnel entah tidak melakukan apa pun atau mengarahkan lalu lintas melewati kebijakan. Perhatikan sumber pada perintah di atas, karena 10.10.0.1 alih-alih alamat kumpulan berarti kernel memilih alamat yang akan ditolak sisi jauh. iroute juga bukan jawabannya; itu memberi tahu server klien mana yang memiliki subnet di belakang tunnel-nya sendiri, bukan ke mana mengirim lalu lintas untuk situs ketiga.

Perluas sisi jauh ke kumpulan pengguna

Kantor pusat sudah mencakup LAN hub, 10.10.0.0/24. Kumpulan pengguna adalah prefiks kedua dan harus ada juga di selektor, atau tidak ada kebijakan yang mencakup balasan yang dialamatkan ke 10.80.0.25. Setiap peer menyebut pasangan kumpulan prefiks 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 perangkat adalah remote_ts perangkat lain. Salin blok hub ke kantor pusat dan pasangannya terbalik, jadi child SA tidak pernah naik.

Sintaks ipsec.conf yang lebih lama memakai leftsubnet yang dipisahkan koma. Asosiasi keamanan yang berjalan mempertahankan selektor yang dinegosiasikannya, jadi bangun ulang tunnel setelah pengeditan. Selektor yang diubah pukul 10:00 dan diuji terhadap SA yang naik pukul 09:40 tetap gagal, sementara file konfigurasi tampak benar sepanjang waktu.

Lalu periksa hop terakhir. ip route get 10.80.0.25 di endpoint jauh harus menunjuk ke dalam tunnel. Jika layanan memakai router LAN sebagai gateway bawaan, router itu juga memerlukan rute balik, atau balasannya mati di sana. Menjalankan tcpdump -ni eth1 host 10.80.0.25 pada segmen itu menunjukkan apakah balasan keluar dari endpoint sama sekali.

Izinkan aliran di hub

Penerusan harus diaktifkan dan jalurnya diizinkan. Batasi aturan ke dua prefiks alih-alih menerima semuanya di antara antarmuka.

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

Pemfilteran jalur balik adalah kegagalan senyap di sebelahnya: dengan kedua kaki di antarmuka berbeda, rp_filter=1 dapat menjatuhkan balasan sementara penghitung aturan terima tidak pernah bergerak. Bandingkan iptables -vnL FORWARD sebelum dan sesudah percobaan. Aturan yang tidak pernah bertambah tidak tercapai, jadi lihat satu lapisan lebih bawah alih-alih menulisnya ulang.

Jika hanya satu grup memerlukan transit, letakkan rutenya di file per klien di bawah client-config-dir alih-alih memperlebar push global. NAT sumber di hub juga menghapus kebutuhan rute balik sisi jauh, tetapi menyembunyikan alamat pengguna, sehingga log situs jauh dan aturan berbasis alamat berhenti membedakan pengguna.

Verifikasi dari klien, lalu kembalikan dalam urutan terbalik

Uji port TCP, bukan hanya ICMP, karena ping bisa lolos sementara layanan tetap diblokir. nc -vz 10.20.0.50 445 dan traceroute -n 10.20.0.50 dari klien menunjukkan apakah hop kedua adalah alamat tunnel hub. Di hub, tcpdump -ni tun0 host 10.20.0.50 dan filter yang sama pada antarmuka site-to-site: permintaan di keduanya tanpa balasan di salah satunya memindahkan masalah ke sisi jauh.

Lalu uji sesuatu yang harus tetap terblokir. Jika host yang seharusnya tidak pernah dijangkau kumpulan juga menjawab, Anda membuka lebih dari transit dan sebaiknya mempersempit aturan. Hub yang meneruskan semua ke setiap spoke lolos uji pertama dan gagal uji kedua.

Simpan daftar pengembalian, karena empat objek berubah dan tiga mudah dilupakan: rute yang didorong, rute hub, selektor, dan aturan firewall. Batalkan dalam urutan terbalik, bangun ulang SA, dan minta satu pengguna terhubung ulang. Pengembalian sebagian meninggalkan rute yang menunjuk ke tunnel yang tidak lagi cocok, yang lebih sulit dibaca daripada keheningan semula. manual OpenVPN 2.6 mendokumentasikan push, route dan iroute untuk versi Anda.