Mengapa Rute OpenVPN Kalah dari Kebijakan XFRM strongSwan

Paket dapat mengikuti rute OpenVPN dan tetap tertangkap oleh kebijakan IPsec, dan kombinasi itu terlihat seperti bug perutean dari semua sudut kecuali sudut yang tepat. Linux menyelesaikan rute lalu berkonsultasi dengan basis data kebijakan keamanan terpisah, sehingga rute tujuan yang lebih spesifik tidak menggusur kebijakan XFRM yang cocok. Gejala yang terlihat adalah lalu lintas yang meninggalkan host dan tidak pernah tiba, sementara kedua tunnel menyatakan dirinya sehat. Tiga opsi menyelesaikannya, dan mana yang Anda pilih bergantung pada jalur mana dari kedua jalur yang dimaksudkan membawa prefiks itu.

Dua keputusan, bukan satu

Pemilihan rute menjawab pertanyaan sempit: hop berikutnya dan alamat sumber mana yang harus membawa paket ini. Basis data kebijakan keamanan menjawab pertanyaan lain: apakah paket ini memerlukan perlindungan IPsec, dan di bawah selektor mana. Keduanya berjalan untuk paket yang sama, dan memenuhi yang pertama tidak mengatakan apa pun tentang yang kedua. Itulah sebabnya mengubah metrik atau menambahkan rute statis dapat membiarkan gejalanya utuh.

Selektor IPsec yang lebar adalah penyebab umum. Kebijakan yang melindungi 172.16.0.0/12 juga mencakup 172.20.8.0/24, yang mungkin ingin dijangkau administrator melalui tunnel OpenVPN. Niat itu hanya ada di tabel perutean, dan basis data kebijakan tidak pernah mengetahuinya.

Perlakukan itu sebagai konflik antara dua jalur perlindungan yang dikonfigurasi, bukan sebagai adu dua metrik. Perbaikannya ada pada komponen yang dikonfigurasi dengan cakupan yang salah.

Baca rute yang benar-benar dipilih kernel

Mulailah dengan pencarian yang dilakukan kernel, termasuk alamat sumber dan aturan kebijakan apa pun yang dapat mengalihkannya ke tabel lain. Rute di tabel utama mungkin tidak pernah dilihat jika aturan sebelumnya memilih tabel lain, dan pencocokan prefiks terpanjang hanya berlaku di dalam tabel yang dipilih suatu aturan.

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

Perintah terakhir adalah yang penting, karena mencetak rute terpilih bersama alamat sumber yang akan digunakan kernel. Bandingkan keluaran itu dengan selektor yang cocok dengan kebijakan IPsec. Ketika rute menunjuk ke antarmuka OpenVPN dan kebijakan masih cocok dengan pasangan yang sama, Anda telah mereproduksi konfliknya tanpa menebak.

Jaga dump tetap bebas dari alamat yang tidak terkait sebelum sampai ke tiket. Tabel perutean dari host produksi membawa topologi internal, dan hanya baris yang menjawab pertanyaan yang layak ditempel.

Baca kebijakan yang juga berlaku

Daftar kebijakan menunjukkan arah, selektor, dan templat yang menentukan apa yang terjadi pada paket yang cocok. Baca arah keluar lebih dulu, lalu sisi masuk untuk lalu lintas balasan, karena pengecualian satu arah menghasilkan koneksi yang dimulai dan tidak pernah selesai.

ip -s xfrm policy
swanctl --list-sas

Bandingkan selektor dalam daftar dengan prefiks yang dinegosiasikan koneksi. Menonaktifkan pemasangan rute strongSwan tidak menghapus kebijakan itu, dan mengubah metrik tidak mengubah pasangan sumber dan tujuan mana yang dilindungi kebijakan. Dua non-perbaikan itu layak disingkirkan lebih awal karena itulah yang orang coba pertama.

Jika daftar tidak memuat kebijakan untuk prefiks yang Anda harapkan, masalahnya ada di tempat lain dan tabel perutean mungkin mengatakan yang sebenarnya. Jika daftar memuat kebijakan yang lebih lebar yang mencakup prefiks itu, Anda telah menemukan penangkapannya.

Tiga opsi ketika kedua jalur sah

Mempersempit selektor IPsec adalah opsi paling bersih ketika prefiks lebar itu kenyamanan, bukan persyaratan. Mengurangi selektor lalu lintas jarak jauh ke subnet yang benar-benar berada di belakang IPsec menghapus konflik untuk setiap host sekaligus, dan biayanya adalah negosiasi ulang kunci, bukan komponen baru.

Pengecualian passthrough adalah opsi bedah ketika selektor lebar harus tetap ada. strongSwan mendukung koneksi terpisah yang child-nya memakai mode pass, yang memberi tahu kernel bahwa lalu lintas yang cocok tidak boleh diproses oleh IPsec. Alamat jarak jauh loopback mencegah koneksi itu dipilih untuk peer yang masuk, dan selektornya harus menjelaskan pasangan resmi yang sebenarnya, bukan semuanya.

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

Contoh konfigurasi strongSwan mendokumentasikan jenis kebijakan ini dan konvensi peer loopback. Opsi ketiga adalah desain berbasis rute dengan antarmuka XFRM, yang mengikat kebijakan pada lalu lintas yang dirutekan melalui antarmuka bernama alih-alih pada selektor global. Ini migrasi, bukan penyetelan, dan lalu lintasnya tetap harus memenuhi selektor yang dinegosiasikan.

Buktikan pengecualian itu tanpa melemahkan sisanya

Setelah memuat perubahan, uji pengecualian dan tujuan biasa yang harus tetap terlindungi. Periksa kedua arah, lalu jatuhkan tunnel OpenVPN dan pastikan apa yang terjadi pada lalu lintas yang dikecualikan. Pengecualian yang diam-diam mengirim prefiks itu secara terbuka saat tunnel mati adalah keputusan kebijakan yang seharusnya Anda ambil dengan sengaja, bukan temukan saat insiden.

Catat prefiks mana memakai jalur mana dan mengapa. Jika tidak, insinyur berikutnya yang melihat selektor lebar akan membuka kembali penyelidikan yang sama, dan jawabannya akan duduk di pesan commit yang tidak dibaca siapa pun.