Tabel VPN kosong tidak memblokir apa pun dengan sendirinya

Aturan kebijakan mengirim paket bertanda ke tabel khusus, dan harapan umumnya adalah hilangnya rute VPN memblokirnya. Mekanismenya melakukan hal lain. Saat tabel tidak berisi rute yang cocok, pencarian berlanjut ke aturan berikutnya alih-alih berhenti, dan tabel main tetap menyimpan rute default biasa untuk uplink. Hasilnya adalah konfigurasi yang terlihat fail-closed tetapi berperilaku fail-open.

Tidak ada yang rusak; begitulah cara perutean berbasis kebijakan ditentukan.

Pencarian berlanjut saat tabel tidak berisi apa pun

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

Ambil kumpulan aturan itu: pencarian bertanda menuju tabel 42, dan aturan berikutnya mengirim tanda yang sama ke tabel bernama default. Selama tabel 42 menyimpan rute default yang bisa dipakai, pencarian pertama menyediakan jalur. Saat rute itu hilang dan tidak ada hal lain di tabel 42 yang cocok, pencarian tidak menjadi pembuangan; pemrosesan berlanjut ke aturan berikutnya, dan saat aturan itu juga tidak menemukan apa pun, ia mencapai tabel main. Tidak ada yang dalam urutan itu melaporkan aturan mana yang menghasilkan jawaban akhir, jadi koneksi yang berfungsi tampak seperti kebijakan yang berfungsi.

Tabel 253, yang secara konvensional disebut default, adalah tabel perutean biasa dan biasanya kosong. Namanya bukan instruksi untuk membuang paket, dan itu bukan hal yang sama dengan rute tujuan default di dalam tabel.

Aksi terminal mengakhiri pencarian

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

Aturan terminal dapat menyusul pencarian VPN sebagai ganti pencarian tabel kosong. Dengan tanda yang sama, aksi prohibit yang ditempatkan setelah aturan tabel 42 mengakhiri pencarian saat tabel itu tidak menghasilkan apa pun, mengembalikan penolakan administratif alih-alih memberi tabel main kesempatan lain. Unreachable dan blackhole juga terminal, dengan perilaku galat berbeda bagi pengirim.

Rute bertipe throw berbeda: di dalam tabel itu ia berperilaku seolah tidak ada yang cocok, sehingga aturan berikutnya tetap mendapat giliran. Itu membuat throw berguna untuk fallback yang disengaja dan salah sebagai blok akhir.

Verifikasi dengan tanda dan antarmuka yang sebenarnya

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

Periksa aturan dan tabel yang sebenarnya, bukan diagram, lalu tanyakan aliran dengan konteks sumber, tanda, dan masuk yang benar-benar dimilikinya. Pencarian hanya-baca yang diarahkan ke tujuan, yang diberi alamat sumber, antarmuka, dan tanda, melaporkan rute yang akan dipilih kernel tanpa paket keluar. Memberikan tanda dalam kueri tidak membuktikan bahwa firewall menandai lalu lintas nyata; itu pemeriksaan terpisah atas aturan penandaan. Konfirmasikan nilainya dengan penghitung atau log sebelum menarik kesimpulan dari kueri.

Permintaan yang dihasilkan secara lokal memerlukan konteksnya sendiri, karena jalur penandaannya sering berbeda dari lalu lintas yang diteruskan. Periksa dengan antarmuka keluar yang benar-benar akan digunakan aplikasi.

Dua kondisi kegagalan, bukan satu

Satu kondisi kegagalan adalah hilangnya rute VPN dan lalu lintas jatuh ke uplink. Terowongan mati yang rutenya tetap terpasang adalah kondisi lain: paket tetap diarahkan ke jalur yang tidak bisa dipakai alih-alih jatuh, dan gejalanya adalah kehilangan senyap, bukan koneksi langsung yang terlihat. Uji keduanya, dan uji juga perilaku saat mulai, menyambung ulang, dan menghentikan layanan.

Aturan seperti itu hanya membantu selama aturan itu ada dan selama paket masih membawa tanda yang memilihnya. Skrip matikan yang menghapus aturan, atau jalur yang melepas tanda, mengembalikan perilaku terbuka. Transisi itu layak dilatih.

Terapkan kebijakan pada IPv6 secara terpisah, dan jaga pengecualian titik akhir yang disetujui tetap eksplisit, bukan tersirat.