Apa yang diubah policy routing pada lalu lintas VPN, dan apa yang tidak

Policy routing menjawab pertanyaan yang berbeda dari yang diajukan sebagian besar catatan pemecahan masalah. Tabel utama mengatakan ke mana suatu tujuan pergi; aturan kebijakan mengatakan tabel mana yang ditanyakan sama sekali, dan mereka dapat memutuskannya dari alamat sumber, tanda paket, atau antarmuka tempat sebuah paket tiba. Ketika sebuah terowongan berperilaku tidak konsisten, kumpulan aturan sering menjadi penyebabnya dan tabel routing sering bukan.

Aturan memilih tabel, lalu tabel memilih rute

Setiap aturan membawa prioritas, kondisi pencocokan, dan tabel tujuan. Kernel menelusuri aturan dalam urutan prioritas dan berhenti pada pencocokan pertama, lalu melakukan pencarian prefiks terpanjang biasa di tabel itu. Aturan yang menunjuk ke tabel kosong jatuh ke apa yang dipilih aturan berikutnya, dan begitulah aturan yang ditulis dengan cermat bisa tampak tidak melakukan apa pun.

Itulah sebabnya membuang tabel utama jarang menjelaskan klien VPN yang berfungsi. Klien biasanya menyisipkan aturan pada nomor prioritas rendah, jauh sebelum aturan default tabel utama, sehingga paket tidak pernah mencapai rute yang Anda tatap. Menurunkan metrik di tabel utama tidak mengubah apa pun bagi lalu lintas yang sudah dialihkan.

Aturan juga dapat dengan sengaja membuat prefiks menjadi lubang hitam atau tidak terjangkau. Sebagian klien menambahkan aturan seperti itu sebagai sakelar pengaman, dan kemudian penurunan itu tampak seperti terowongan rusak alih-alih terowongan yang dikonfigurasi.

Baca kumpulan aturan sebagai urutan, bukan sebagai daftar

Cetak aturan dengan prioritasnya dan tabel yang mereka rujuk, lalu cetak setiap tabel yang membawa rute default atau rute terowongan. Urutan adalah bagian yang penting, dan itulah bagian yang biasanya dihilangkan tangkapan layar:

ip rule show
ip route show table all | sed -n '1,60p'
ip route get 198.51.100.20 from 10.8.0.2
ip route get 198.51.100.20 from 10.8.0.2 mark 0x1

Dua perintah terakhir adalah yang mengubah teori menjadi pengamatan, karena keduanya menanyakan apa yang akan dilakukan kernel untuk sumber dan tanda itu. Jika jawabannya berubah ketika tandanya berubah, ada aturan berbasis tanda yang bekerja dan uji apa pun yang mengabaikan tanda sedang menguji paket yang berbeda. Koneksi luar layak mendapat aturannya sendiri. Terowongan yang merutekan seluruh lalu lintas melalui dirinya sendiri harus mengecualikan alamat titik akhir yang menjadi tujuannya terhubung, atau paket terenkripsi dikirim kembali ke terowongan yang baru saja mereka tinggalkan. Sebagian besar klien menyisipkan pengecualian itu secara otomatis, dan kumpulan aturan yang diedit tangan adalah tempat pengecualian itu hilang.

Tanda dan soket: dua cara klien membagi lalu lintas

Sebagian klien menandai paket di firewall dan menambahkan aturan yang cocok dengan tanda itu. Yang lain memakai routing tingkat soket, menaruh rute pada soket sebelum soket terhubung. Yang pertama terlihat di ip rule; yang kedua tidak, dan tidak akan muncul dalam pencarian umum.

Jika program uji berperilaku berbeda dari aplikasi yang seharusnya diwakilinya, periksa apakah aplikasi menaruh tanda atau mengikat ke perangkat. Perbedaan itu bukan misteri begitu mekanismenya dinamai, dan itu menjelaskan mengapa curl dari shell dan tab peramban dapat menempuh jalur berbeda di mesin yang sama. Kedua teknik adalah policy routing dalam arti luas: keduanya memilih jalur dengan sesuatu selain tujuan. Tidak satu pun memberi otorisasi pada lalu lintas, dan tidak satu pun menggantikan aturan firewall atau kredensial yang diharapkan mitra.

Lacak kepemilikan sebelum menambah aturan lain

Aturan dipasang oleh sesuatu. Klien VPN, manajer jaringan, dan skrip yang ditulis tangan masing-masing dapat menambah aturan saat mulai, dan logika penyambungan ulang dapat meninggalkan kumpulan sebelumnya. Dua aturan usang dari profil lama akan terus mengarahkan lalu lintas jauh setelah profil itu dihapus.

Temukan proses mana yang memiliki aturan itu dari prioritas dan bentuknya, dan periksa apakah pemilik itu menulis ulang kumpulan pada setiap koneksi. Jika ya, aturan manual yang ditambahkan hari ini hilang besok, dan perbaikannya ada pada konfigurasi klien, bukan pada berkas riwayat shell. Membersihkan seluruh kumpulan aturan untuk menguji adalah jalan pintas menggoda dengan biaya yang dapat diperkirakan: itu juga menghapus aturan yang dibutuhkan klien agar terowongannya sendiri tetap berfungsi. Hapus satu aturan setiap kali, atau uji pada mesin yang dapat Anda boot ulang.

Buktikan cakupannya dengan dua aliran, bukan satu

Sebuah koreksi hanya diverifikasi oleh aliran yang seharusnya terdampak dan aliran yang seharusnya tidak. Pilih tujuan yang dirutekan kebijakan ke dalam terowongan, dan satu yang harus dibiarkan di luar, lalu bandingkan pencarian dan tangkapan untuk keduanya:

ip route get 198.51.100.20 from 192.0.2.44
ip route get 198.51.100.21 from 192.0.2.44
tcpdump -ni any host 198.51.100.21 and port 443

Ketika kedua pencarian mengembalikan antarmuka berbeda, aturan itu melakukan sesuatu. Ketika keduanya mengembalikan antarmuka yang sama, aturan itu cocok lebih luas daripada yang dimaksud, dan itulah kegagalan yang diam-diam mengirim seluruh subnet melalui terowongan yang dimaksudkan untuk satu aplikasi.

Catat prioritas aturan dan layanan pemiliknya di tiket, bersama dua alamat uji. Orang berikutnya lalu memiliki pasangan yang dapat direproduksi alih-alih deskripsi gejala, dan dapat mengatakan dalam satu menit apakah policy routing masih bekerja.