Balasan VPN tapak-ke-tapak tidak melalui terowong

Saya menghabiskan sepanjang pagi dengan terowong yang timbul dengan bersih dan memindahkan trafik tepat dalam satu arah: cawangan dapat mencapai pelayan fail di ibu pejabat, dan setiap sambungan yang dibuka dari ibu pejabat ke cawangan mati pada SYN pertama. SA aktif, pembilang terowong meningkat, dan jabat tangan tidak pernah menjadi masalah. Balasan dihalakan ke tempat yang tidak diliputi terowong, dan pilihan itu milik sebelah jauh. VPN tapak-ke-tapak hanya membawa paket yang diserahkan hos kepada get laluan, dan setiap hos membuat pilihan itu secara berasingan, dalam setiap arah, daripada jadual penghalaannya sendiri.

Kedua-dua arah dihalakan secara berasingan

IP tidak menyimpan sebarang ingatan tentang arah perbualan. Setiap hos yang menghantar paket menjalankan carian awalan terpanjangnya sendiri, memilih satu hop seterusnya dan melupakan keputusan itu. Permintaan dan balasan ialah dua paket tidak berkaitan yang kebetulan tergolong dalam sambungan yang sama, dan terowong ialah satu hop yang boleh digunakan atau tidak oleh mana-mana daripadanya. Tiada apa dalam pertukaran IKE yang mengajar pelayan jauh cara mencapai subnet anda; rundingan hanya bersetuju awalan mana yang boleh disulitkan.

Persetujuan itu ialah pintu kedua. Pada strongSwan pemilih trafik ialah leftsubnet dan rightsubnet, dan paket yang sumber atau destinasinya jatuh di luar pasangan yang dirundingkan tidak disulitkan, apa pun kata jadual penghalaan. Awalan yang dihalakan ke dalam terowong tetapi tiada dalam pemilih ialah kegagalan sehala yang senyap: laluan kelihatan betul, paket masih keluar terbuka atau digugurkan, dan hanya log charon yang merungut.

Hos jauh tidak tahu apa-apa tentang terowong anda

Di dalam LAN jauh balasan itu paket biasa yang dialamatkan kepada klien anda. Hos destinasi tidak melihat sebarang pengepala IPsec dan tiada sebab untuk mengutamakan get laluan VPN; ia mencari awalan anda, tidak menemui apa-apa yang lebih khusus daripada laluan lalainya dan mengikutinya. Jika laluan lalai menunjuk ke tembok api teras, tembok api itu sama ada mempunyai laluan kembali ke dalam terowong atau tidak. Apabila tidak, anda mendapat guguran senyap, ICMP unreachable, atau balasan yang keluar melalui antara muka menghadap internet lalu mati.

Antara muka kedua sudah cukup untuk memecahkan ini walaupun laluan wujud. NAS dengan pautan pengurusan pada VLAN lain, pelayan dengan uplink sandaran, peraturan dasar yang menghantar satu julat sumber ke jadual kedua: mana-mana daripada ini boleh menangkap balasan itu. Pada Linux, ip rule show dan ip route show table all menunjukkan peraturan dan jadual yang disembunyikan senarai lalai.

Baca keputusan pada mesin yang menghantar balasan

Tanya kernel sebelum mengubah apa-apa, dan berikan alamat sumbernya, kerana peraturan yang bergantung pada sumber mengubah jawapannya.

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

Output menamakan antara muka keluar dan hop seterusnya. Jika antara muka itu bukan yang menghadap get laluan VPN, anda telah menemui kecacatan, dan kerja yang tinggal ialah memilih di mana laluan itu sepatutnya berada. Ping dari get laluan membuktikan sedikit di sini: ia menjawab dengan alamat yang hos jauh boleh letakkan, bukan alamat komputer riba anda.

Pada Windows yang setara ialah Find-NetRoute -RemoteIPAddress 10.10.5.10 untuk keputusan dan Get-NetRoute untuk jadual. Laluan yang ditambah dengan New-NetRoute dan membawa metrik lebih tinggi daripada lalai akan kalah secara senyap, jadi baca lajur metrik, bukan entri. Kemudian sahkan dengan paket: tcpdump -ni any "host 10.10.5.10 and tcp port 445" pada antara muka LAN jauh menunjukkan permintaan, dan penapis yang sama di sebelah terowong menunjukkan sama ada balasan kembali. Permintaan kelihatan tanpa balasan bermakna jawapannya dihalakan ke tempat lain atau digugurkan; balasan pada antara muka yang salah memberi anda pesalah sebelum anda menyentuh laluan.

Apabila get laluan pelayan bukan titik akhir VPN

Banyak tapak meletakkan tembok api antara pelayan dan penumpu. Tembok api itu memajukan balasan, jadi ia memerlukan laluan untuk awalan klien anda menuju get laluan VPN, dan dasar pemajuan dalam kedua-dua arah. Peranti berkeadaan memburukkannya: permintaan melintasi tembok api dari hos LAN yang dibenarkannya, balasan kini tiba dari arah lain, dan entri penjejakan sambungan tidak lagi sepadan, jadi paket itu digugurkan sebagai tidak sah dan bukan ditolak. Itulah sebabnya log dasar kelihatan kosong sementara trafik hilang.

Get laluan mempunyai penapis keduanya sendiri. Penapisan laluan songsang Linux menggugurkan paket yang sumbernya tidak dapat dicapai melalui antara muka tempat ia tiba, dan itulah tepat bentuk laluan pulang tak simetri yang sah. panduan pemajuan strongSwan meminta net.ipv4.ip_forward dan net.ipv4.conf.all.rp_filter yang dilonggarkan atas sebab itu. Nilai ketat 1 pada mana-mana get laluan memecahkan laluan yang betul secara senyap, dan nstat -az menunjukkan guguran jika anda tahu ke mana perlu dilihat.

Halakan atau terjemah, kemudian sahkan dalam kedua-dua arah

Kedua-dua pembaikan tidak setara. Menambah laluan mengekalkan alamat klien tanpa diusik, jadi peraturan berasaskan sumber, log audit dan aplikasi yang merekod pemanggil terus berfungsi; harganya ialah setiap hop yang membuat keputusan memerlukan laluan itu, iaitu lebih banyak tempat untuk tersilap. Penyamaran pada get laluan jauh memampatkan laluan pulang kepada satu hop, kerana balasan kini dialamatkan kepada get laluan itu sendiri, dan menyembunyikan klien mana yang melakukan apa.

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

Pilihnya dengan sedar: sebaik sahaja klien muncul sebagai alamat get laluan, ACL berasaskan sumber berhenti membezakannya, dan conntrack mesti memegang pemetaan supaya balasan ditulis semula ke dalam terowong. Jika pemilih masih mengecualikan awalan klien, NAT tidak mengubah apa-apa, kerana permintaan itu tidak pernah masuk ke dalam terowong.

Sebelum mengisytiharkannya selesai, sahkan empat perkara mengikut urutan: laluan pada hos yang menghantar balasan, laluan pada setiap hop yang memajukannya, pemilih yang meliputi kedua-dua awalan, dan tangkapan yang menunjukkan balasan masuk ke terowong dengan sumber yang anda jangkakan. Kemudian ulangi ujian dari tapak lain. Satu arah yang lulus ialah reka bentuk separa terbuka, dan arah kedua biasanya gagal atas sebab yang berbeza daripada yang baru anda baiki.