Balasan VPN situs-ke-situs tidak melewati terowongan

Saya menghabiskan satu pagi pada terowongan yang naik dengan bersih dan memindahkan lalu lintas tepat satu arah: cabang bisa mencapai server file di kantor pusat, dan setiap koneksi yang dibuka dari kantor pusat ke cabang mati pada SYN pertama. SA-nya aktif, penghitung terowongan naik, dan jabat tangan tidak pernah menjadi masalah. Balasannya dirutekan ke suatu tempat yang tidak dicakup terowongan, dan pilihan itu milik sisi jauh. VPN situs-ke-situs hanya membawa paket yang diserahkan host ke gateway, dan setiap host membuat pilihan itu sendiri, di setiap arah, dari tabel peruteannya sendiri.

Kedua arah dirutekan secara terpisah

IP tidak menyimpan ingatan tentang arah percakapan. Setiap host yang mengirim paket menjalankan pencarian prefiks terpanjangnya sendiri, memilih satu hop berikutnya, dan melupakan keputusan itu. Permintaan dan balasan adalah dua paket tak berhubungan yang kebetulan milik koneksi yang sama, dan terowongan adalah satu hop yang bisa dipakai atau tidak dipakai oleh keduanya. Tidak ada apa pun dalam pertukaran IKE yang mengajari server jauh cara mencapai subnet Anda; negosiasi hanya menyetujui prefiks mana yang boleh dienkripsi.

Kesepakatan itu adalah gerbang kedua. Di strongSwan selektor lalu lintas adalah leftsubnet dan rightsubnet, dan paket yang sumber atau tujuannya jatuh di luar pasangan yang dinegosiasikan tidak dienkripsi, apa pun kata tabel perutean. Prefiks yang dirutekan ke dalam terowongan tetapi hilang dari selektor adalah kegagalan satu arah yang senyap: rutenya tampak benar, paketnya tetap keluar tanpa enkripsi atau dibuang, dan hanya log charon yang mengeluh.

Host jauh tidak tahu apa pun tentang terowongan Anda

Di dalam LAN jauh balasan itu paket biasa yang dialamatkan ke klien Anda. Host tujuan tidak melihat tajuk IPsec dan tidak punya alasan memilih gateway VPN; ia mencari prefiks Anda, tidak menemukan apa pun yang lebih spesifik dari rute bawaannya, dan mengikutinya. Jika rute bawaan menunjuk ke firewall inti, firewall itu punya rute kembali ke terowongan atau tidak. Bila tidak, Anda mendapat pembuangan senyap, ICMP unreachable, atau balasan yang keluar lewat antarmuka menghadap internet lalu mati.

Antarmuka kedua cukup untuk merusak ini bahkan ketika rute ada. NAS dengan tautan manajemen di VLAN lain, server dengan uplink cadangan, aturan kebijakan yang mengirim satu rentang sumber ke tabel kedua: salah satu dari ini bisa menangkap balasannya. Di Linux, ip rule show dan ip route show table all menampilkan aturan dan tabel yang disembunyikan daftar bawaan.

Bacalah keputusan di mesin yang mengirim balasan

Tanyakan ke kernel sebelum mengubah apa pun, dan berikan alamat sumbernya, karena aturan yang bergantung pada sumber mengubah jawabannya.

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

Keluarannya menyebut antarmuka keluar dan hop berikutnya. Jika antarmukanya bukan yang menghadap gateway VPN, Anda sudah menemukan cacatnya, dan pekerjaan sisanya adalah memilih di mana rute itu seharusnya berada. Ping dari gateway tidak banyak membuktikan di sini: ia menjawab dengan alamat yang bisa ditempatkan host jauh, bukan alamat laptop Anda.

Di Windows padanannya adalah Find-NetRoute -RemoteIPAddress 10.10.5.10 untuk keputusan dan Get-NetRoute untuk tabel. Rute yang ditambahkan dengan New-NetRoute dan membawa metrik lebih tinggi daripada rute bawaan akan kalah tanpa suara, jadi bacalah kolom metrik, bukan entrinya. Lalu pastikan dengan paket: tcpdump -ni any "host 10.10.5.10 and tcp port 445" di antarmuka LAN jauh menunjukkan permintaannya, dan filter yang sama di sisi terowongan menunjukkan apakah ada balasan yang kembali. Permintaan terlihat tanpa balasan berarti jawabannya dirutekan ke tempat lain atau dibuang; balasan di antarmuka yang salah memberi Anda pelakunya sebelum Anda menyentuh rute.

Ketika gateway server bukan titik akhir VPN

Banyak situs menaruh firewall di antara server dan konsentrator. Firewall itu meneruskan balasan, jadi ia perlu rute untuk prefiks klien Anda yang menunjuk ke gateway VPN, dan kebijakan penerusan di kedua arah. Perangkat stateful memperburuknya: permintaan melintasi firewall dari host LAN yang diizinkannya, balasan sekarang datang dari arah lain, dan entri pelacakan koneksi tidak lagi cocok, sehingga paketnya dibuang sebagai tidak valid alih-alih ditolak. Itulah sebabnya log kebijakan tampak kosong sementara lalu lintas menghilang.

Gateway punya filter keduanya sendiri. Penyaringan jalur balik di Linux membuang paket yang sumbernya tidak terjangkau melalui antarmuka tempat paket itu datang, dan itulah persis bentuk jalur balik asimetris yang sah. panduan penerusan strongSwan meminta net.ipv4.ip_forward dan net.ipv4.conf.all.rp_filter yang dilonggarkan karena alasan itu. Nilai ketat 1 pada salah satu gateway mematahkan rute yang benar secara senyap, dan nstat -az menunjukkan pembuangannya jika Anda tahu ke mana harus melihat.

Rutekan atau terjemahkan, lalu verifikasi di kedua arah

Kedua perbaikan tidak setara. Menambahkan rute menjaga alamat klien tetap utuh, jadi aturan berbasis sumber, log audit, dan aplikasi yang mencatat pemanggil tetap bekerja; harganya adalah setiap hop yang mengambil keputusan memerlukan rute itu, yaitu lebih banyak tempat untuk salah. Penyamaran di gateway jauh memampatkan jalur balik menjadi satu hop, karena balasan sekarang dialamatkan ke gateway itu sendiri, dan menyembunyikan klien mana yang melakukan apa.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Pilihlah dengan sadar: begitu klien tampil sebagai alamat gateway, ACL berbasis sumber berhenti membedakan mereka, dan conntrack harus memegang pemetaan agar balasannya ditulis kembali ke dalam terowongan. Jika selektor masih mengecualikan prefiks klien, NAT tidak mengubah apa pun, karena permintaannya tidak pernah masuk ke terowongan.

Sebelum menyebutnya beres, pastikan empat hal secara berurutan: rute di host yang mengirim balasan, rute di setiap hop yang meneruskannya, selektor yang mencakup kedua prefiks, dan tangkapan yang menunjukkan balasan masuk ke terowongan dengan sumber yang Anda harapkan. Lalu ulangi uji dari situs lain. Satu arah yang lolos adalah desain setengah terbuka, dan arah kedua biasanya gagal karena alasan yang berbeda dari yang baru saja Anda perbaiki.