Mengapa klien VPN di LAN kantor kehilangan setiap balasan

Sebuah laptop berada di /24 kantor lewat Ethernet dan juga bergabung ke server OpenVPN yang tinggal di /24 yang sama. Seorang rekan melakukan ping ke alamat terowongan; permintaan jelas tiba, dan tidak ada yang kembali. Log terowongan bersih dan penjelajahan masih berjalan, jadi terowongan adalah tersangka yang salah. Validasi sumber IPv4 di mesin penerima membuang paket sebelum apa pun membacanya.

Pembuangan terjadi sebelum apa pun membaca paket

Validasi sumber mengajukan satu pertanyaan tentang setiap paket masuk: jika host ini menjawab sumber itu, apakah jawabannya akan keluar lewat antarmuka tempat paket barusan tiba? Ketika jawabannya tidak, kernel membuang paket saat kedatangan. Tidak ada soket dan tidak ada jalur penerusan yang pernah melihatnya, karena itu tangkapan di terowongan tetap mencatat permintaan yang tidak pernah diterima aplikasi.

Klien di sini memegang 10.66.0.9 pada terowongannya, dan server OpenVPN menjawab di 192.168.80.10 di dalam prefiks kantor. Rekan di 192.168.80.25 melakukan ping ke alamat terowongan, jadi permintaan menyeberangi LAN, server merutekannya ke terowongan, dan ia tiba di antarmuka terowongan klien dengan membawa alamat sumber kantor. Dalam tabel perutean mesin itu, prefiks kantor milik perangkat Ethernet, bukan milik terowongan. Validasi membandingkan antarmuka kedatangan dengan rute, menemukan ketidakcocokan dan membuang paket, jadi rekan melihat kehilangan total sementara kedua ujung melaporkan terowongan yang sehat.

Arah cermin punya bentuk yang sama: ketika klien memulai ke arah kantor, balasan bisa dibuang di sisi kantor karena alasan yang sama. Perbaikan yang hanya diperiksa dalam satu arah biasanya kembali sebagai tiket kedua.

Buktikan mode yang berlaku sebelum menyentuh sysctl apa pun

Baca nilai efektif alih-alih mempercayai bawaan distribusi, karena pengaturan per antarmuka hanya separuh keputusan. Mode yang berlaku adalah yang lebih tinggi antara nilai antarmuka dan nilai all, jadi nol pada antarmuka terowongan tidak berarti apa-apa selama all bernilai satu. Keputusan mode ketat adalah keputusan perutean, jadi jalankan pencarian yang dijalankan kernel dan bandingkan jawabannya dengan antarmuka tempat paket benar-benar tiba.

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

Lalu ulangi ping sambil mengamati penghitung galat. Angka yang naik di samping permintaan yang sudah ditunjukkan tangkapan adalah tanda pembuangan ini, bukan tanda rute yang hilang. Nyalakan pencatatan paket Mars selama Anda di sana, agar kernel menyebut sumber dan antarmuka yang ditolaknya. Bersama-sama keduanya menyingkirkan sandi, tembok api, dan iroute yang hilang sebagai penjelasan.

Tulis garis dasar sebelum mengubah apa pun: kedua nilai, perangkat yang dipilih pencarian, dan penghitung yang Anda amati. Catatan itulah yang nanti memberi tahu Anda apakah perubahan melakukan yang Anda pikir.

Apa yang sebenarnya diterima setiap mode rp_filter

Kernel menampilkan tiga nilai per antarmuka, dan itu bukan tiga nuansa satu aturan. Nol mematikan pemeriksaan. Satu bersifat ketat dan menuntut sumber dirutekan kembali keluar lewat antarmuka kedatangan. Dua bersifat longgar dan hanya menuntut ada rute apa pun ke sumber di tabel, ke mana pun ia menunjuk.

Baris yang penting di sini adalah yang longgar, dan apa yang terus ia tolak. Sumber palsu yang bisa dirutekan di mana saja dalam tabel Anda lolos, sedangkan sumber tanpa rute sama sekali tetap ditolak. Di laptop itu konsesi sempit; di perute yang meneruskan lalu lintas orang lain, konsesi itu lebar. Mode itu milik host, jadi angka yang sama membawa bobot berbeda di dua tempat.

Baris mana yang dibutuhkan topologi ini mengikuti tabel, bukan kebiasaan. Paket itu sah dan sumbernya bisa dirutekan, jadi yang longgar menerimanya dan yang ketat tidak. Tidak ada dalam kasus ini yang menuntut nol, dan memilih nol akan menghapus pemeriksaan yang di sini tidak berbiaya apa pun.

Pilih perubahan terkecil yang menghapus ambiguitas

Mode longgar adalah perubahan terkecil yang cocok, dan itu pengurangan ketat yang nyata, bukan sakelar tak berbahaya. Ada pilihan yang lebih baik setiap kali topologi mengizinkan: hapus tumpang tindihnya, dan ambiguitasnya lenyap.

Di mana prefiks kantor hanya diperlukan lewat Ethernet, keluarkan dari rute yang ditarik profil dan alamatnya menjadi terjangkau lewat satu jalur. Ketika kedua jalur benar-benar harus hidup berdampingan, patok sumber dan perangkatnya dengan aturan kebijakan alih-alih melonggarkan validasi di setiap antarmuka. Itu mempertahankan penyaringan ketat untuk semua hal lain di mesin dan mendokumentasikan pengecualiannya di tempat insinyur berikutnya akan mencarinya.

Jalur mana pun yang Anda pilih, catat di drop-in sysctl, bukan di perintah hidup. Setel kunci all dan default bersama-sama, agar penyambungan ulang tidak bisa diam-diam mengembalikan mode ketat.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

Apa yang dilepas mode longgar, dan di mana

Mode longgar masih menolak sumber yang tidak bisa dicapai rute mana pun, dan berhenti menolak sumber palsu yang kebetulan bisa dirutekan. Di laptop itu konsesi sempit. Di perangkat yang meneruskan lalu lintas yang bukan miliknya, pilihan yang sama jauh lebih lebar. Karena itu setelan yang sama membawa dua makna yang sangat berbeda tergantung di mana ia berjalan.

Mematikan pemeriksaan sepenuhnya pada host yang meneruskan lalu lintas orang lain adalah satu-satunya perbaikan yang harus dihindari. Nol membuang validasi yang dengan hati-hati dijaga mode longgar. Jika host meneruskan untuk orang lain, belalah opsi aturan kebijakan dari bagian sebelumnya.

Tinggalkan catatan yang menyebut kedua antarmuka, prefiks yang tumpang tindih, dan uji tepat yang kini berhasil. Itu lebih berguna bagi insinyur berikutnya daripada satu baris yang mengatakan penyaringan telah disesuaikan.