Perutean sumber untuk dua kumpulan VPN: apa yang terlewat oleh aturan Anda

Dua kumpulan klien, satu gateway, dan rencananya tampak sepele: satu aturan mengirim kumpulan pertama lewat uplink cepat, aturan lain mengirim kumpulan kedua lewat terowongan mitra. Lalu aturannya terpasang dan kumpulan kedua tetap keluar lewat rute default. Aturannya tidak rusak. Sumber paket bukan yang diharapkan penulisnya pada saat pencarian terjadi, karena penerjemahan dan pencarian berlangsung di titik berbeda dalam perjalanan paket yang sama, dan urutannya kebalikan dari diagram mental yang digambar kebanyakan orang.

Pencarian terjadi sebelum sumber ditulis ulang

Untuk paket yang diteruskan dari klien VPN, kernel menjalankan urutan tetap. Paket tiba di antarmuka terowongan, melewati prerouting tempat conntrack dan DNAT berada, lalu keputusan perutean dibuat, lalu penerusan, lalu postrouting tempat SNAT diterapkan terakhir. Aturan berbentuk from diperiksa selama keputusan perutean itu, artinya ia melihat alamat asli klien, bukan alamat yang diterjemahkan.

Jadi menambahkan aturan masquerade tidak mengubah kebijakan mana yang cocok untuk aliran keluar. Yang berubah adalah apa yang dilihat ujung jauh, dan karena itu jalur balik mana yang ada. Ini dua akibat berbeda, dan tinjauan perubahan terus-menerus mencampuradukkannya. Pisahkan keduanya dan desainnya biasanya menjadi jelas dalam satu menit.

Alamat terjemahan muncul di aturan pada arah balasan. Paket yang kembali ke gateway dialamatkan ke alamat terjemahan, dan jika Anda punya aturan kebijakan berdasarkan tujuan atau antarmuka tempat paket itu masuk, itulah nilai yang Anda cocokkan. Koneksi yang sama, sumber kebenaran berbeda di setiap arah.

Jadi dua kumpulan dengan sumber berbeda memang memerlukan tabel berbeda, dan desainnya benar. Yang dikesampingkan tabel di atas adalah jalan pintas men-debug dengan melihat apa yang diterima situs jauh lalu menyimpulkan aturannya dari situ.

Uji dari gateway bukan uji kumpulan

Lalu lintas yang dibuat gateway sendiri tidak pernah melewati prerouting, karena tidak tiba di antarmuka mana pun. Ia dirutekan di jalur output, dengan alamat gateway sendiri sebagai sumber, dan aturan from yang didasarkan pada rentang klien tidak akan cocok. Setiap tiket di bidang ini yang mengatakan berhasil dari kotak tetapi tidak dari klien adalah pengulangan fakta itu.

Simulasikan klien alih-alih memperkirakannya. Pencarian perutean bisa ditanyakan langsung, dengan sumber dan antarmuka masuk diberikan:

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

Jalankan sekali per kumpulan. Jika kedua perintah mengembalikan antarmuka yang sama, aturan tidak memisahkan kumpulan itu, dan penyebabnya entah aturan yang hilang atau aturan berprioritas lebih tinggi yang cocok untuk keduanya. Jika keduanya mengembalikan antarmuka berbeda tetapi klien tetap gagal, kesalahannya ada setelah pencarian dan Anda bisa berhenti memeriksa aturan.

Prioritas, bukan posisi di berkas

Aturan dievaluasi dalam urutan prioritas menaik, dan angkanya yang penting, bukan urutan pengetikannya. Tabel local berada pada prioritas 0, tabel main pada 32766, dan aturan default pada 32767, karena itu aturan yang ditambahkan dengan prioritas default mendarat dekat ujung daftar dan kalah dari hampir semuanya.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

Prioritas eksplisit membuat urutan yang dimaksud terlihat di berkas dan saat tinjauan. Ia juga mencegah tambahan belakangan melompat diam-diam di depan aturan yang sudah ada, yang merupakan penyebab paling umum kebijakan yang berfungsi berhenti berfungsi setelah perubahan tak terkait.

Aturan yang cocok dan menunjuk ke tabel tidak lengkap adalah jebakan lainnya. Jika tabel 201 memuat rute default tetapi tidak ada rute ke tujuan, paket dibuang atau dikirim ke tempat yang salah, dan aturannya tampak sepenuhnya benar secara terpisah. Bacalah tabelnya, bukan hanya aturannya. Aturan adalah penunjuk, dan tabel kosong adalah penunjuk ke ketiadaan.

Jalur balik tetap harus ada

Kebijakan sumber memilih jalan keluar. Ia tidak menciptakan jalur balik. Jika kumpulan kedua keluar lewat terowongan mitra, mitra harus tahu cara mencapai 172.31.8.0/24, entah lewat rute balik ke gateway atau dengan menerima alamat terjemahan yang sudah dikenalnya.

Memilih di antara keduanya adalah keputusan desain dengan akibat yang terlihat. Merutekan rentang klien kembali mempertahankan identitas tiap klien di mitra dan menuntut mitra menerima prefiks Anda. Penerjemahan menyembunyikan kumpulan di balik satu alamat dan menuntut mitra hanya menerima alamat itu, dengan biaya log Anda dan log mereka tidak lagi sepakat tentang siapa yang terhubung.

Apa pun yang Anda pilih, tuliskan di samping definisi kumpulan. Rute balik yang hanya ada di ingatan seseorang adalah persis hal yang bertahan sampai mitra mengganti firewall, lalu memakan waktu sehari untuk dibangun ulang.

Jangan tangkap terowongan gateway sendiri di kebijakan

Aturan yang Anda tulis untuk klien juga berlaku bagi lalu lintas yang dibuat gateway, kecuali Anda mengecualikannya. Aturan luas yang didasarkan pada mark atau antarmuka keluar dapat menangkap koneksi gateway sendiri ke mitra, dan kemudian terowongan yang membawa kebijakan itu dirutekan oleh kebijakannya sendiri. Itu menghasilkan loop atau pemadaman yang tampak seperti gangguan penyedia.

Batasi setiap aturan sesempit yang diizinkan desain: prefiks sumber, antarmuka masuk, dan bila didukung mark yang hanya dibawa paket klien. Lalu uji konektivitas gateway sendiri setelah setiap perubahan aturan, karena kegagalannya merujuk dirinya sendiri dan tidak muncul dalam uji klien.

Halaman manual ip-rule mendokumentasikan semantik pemilih dan prioritas. Gabungkan dengan uji pencarian per kumpulan dan desainnya menjadi dapat diperiksa, yang merupakan perbedaan antara perutean kebijakan yang bertahan setahun dan yang semua orang takut menyentuhnya.