Tabel Routing versus Pencarian Sebenarnya: Ke Mana Trafik VPN Pergi

Dump tabel routing adalah diagnostik paling tidak berguna dalam pemecahan masalah VPN dan yang paling sering ditempel. Empat puluh baris prefiks memberi tahu Anda apa yang bisa dilakukan mesin, bukan apa yang dilakukannya untuk permintaan yang gagal. Mekanisme yang sebenarnya Anda inginkan adalah pencarian: dengan sumber ini dan tujuan ini, aturan mana yang cocok, tabel mana yang dikonsultasikan, dan antarmuka serta hop berikutnya mana yang keluar. Mulailah dari satu tujuan dan satu sumber, lalu baca tabel dengan pertanyaan itu di tangan, dan keluaran yang sama menjadi bukti alih-alih kebisingan.

Tabel adalah kumpulan kandidat, bukan keputusan

Setiap entri menjelaskan prefiks dan apa yang harus dilakukan dengan trafik yang cocok dengannya: kirim ke antarmuka, serahkan ke hop berikutnya, atau buang. Tidak ada yang diurutkan berdasarkan maksud dalam daftar itu, dan entri yang tampak paling spesifik bagi manusia tidak selalu yang dipilih kernel, karena pemilihan mengikuti kecocokan prefiks terpanjang dan, di antara prefiks yang sama, metrik.

Jadi langkah pertama adalah bertanya kepada kernel alih-alih membaca daftar. Perintah pencarian menjawab untuk suatu tujuan, dan dengan argumen sumber ia menjawab untuk pasangan persis yang akan digunakan koneksi yang diteruskan atau diikat:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Setiap alamat di atas adalah contoh dokumentasi. Intinya adalah bentuk jawabannya: antarmuka, alamat sumber yang dipilih, gateway, dan tabel asal entri. Jika keluaran itu tidak cocok dengan antarmuka yang Anda harapkan, Anda telah melokalisasi masalahnya dengan satu perintah, dan sebanyak apa pun membaca tabel lengkap tidak akan memberi tahu Anda kandidat mana yang menang.

Pencarian menelusuri aturan, lalu tabel

Di Linux keputusan terjadi dalam dua tahap. Aturan kebijakan dievaluasi dalam urutan prioritas, dan aturan pertama yang cocok menyebutkan tabel untuk dikonsultasikan; tabel itu lalu melakukan kecocokan prefiks terpanjang. Aturan dapat cocok pada sumber, tujuan, tanda firewall, antarmuka, atau kombinasi, sehingga dump tabel utama bisa sepenuhnya akurat dan sepenuhnya tidak relevan untuk paket yang Anda selidiki.

ip rule show
ip route show table all | head -40
ip route show table 100

Jika suatu aturan mengirim trafik dari kumpulan VPN Anda ke tabel 100, maka tabel 100-lah yang penting, dan tabel utama adalah umpan. Ini juga mekanisme di balik routing berbasis sumber pada router: tujuan yang sama dapat memiliki dua jawaban berbeda tergantung dari mana paket datang, dan hanya pencarian dengan argumen sumber yang mengungkap mana yang berlaku.

IPv6 memiliki aturan dan tabelnya sendiri. Rancangan yang menjalankan kedua keluarga membutuhkan kedua pencarian, dan jawaban IPv4 yang berfungsi tidak mengatakan apa pun tentang jalur v6 yang mungkin lebih disukai klien dual-stack.

Apa yang dipasang klien VPN

Klien biasanya tidak mengganti rute default, karena itu akan merusak jalur luar tunnel itu sendiri. Mereka memasang sesuatu yang lebih spesifik yang menang berdasarkan panjang prefiks: sepasang setengah-default yang mencakup 0.0.0.0/1 dan 128.0.0.0/1 adalah trik klasik, karena keduanya prefiks lebih panjang daripada 0.0.0.0/0 dan bersama-sama mencakup seluruh ruang. Yang lain memasang prefiks privat tertentu plus aturan kebijakan, dan sebagian menambahkan tanda agar hanya trafik terpilih yang ditangkap.

Itulah sebabnya "VPN tidak mengubah rute default saya" bukan bukti kegagalan. Periksa apa yang sebenarnya ditambahkannya, dan apakah tujuan yang dimaksud berada di dalam prefiks tersebut:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Dua setengah-rute mudah terlewat dalam dump karena tidak terlihat seperti default. Konfigurasi split-tunnel yang lupa menyertakan prefiks menghasilkan persis gejala yang Anda kejar: aplikasi yang seharusnya menggunakan tunnel justru menyelesaikan dan terhubung secara lokal. Bandingkan prefiks yang terpasang dengan tujuan yang benar-benar dibutuhkan pengguna, bukan dengan alamat yang kebetulan Anda uji. Daftar split-tunnel yang mencakup server file tetapi bukan resolver-nya menghasilkan koneksi yang menyelesaikan ke alamat publik lalu gagal diautentikasi, yang terlihat seperti masalah kata sandi tetapi merupakan masalah rute.

Rute luar juga harus bertahan

Tunnel itu sendiri adalah trafik. Paket yang membawa muatan terenkapsulasi menuju alamat peer melalui antarmuka fisik, dan jalur itu tidak boleh dirutekan kembali ke dalam tunnel. Ketika itu terjadi, Anda mendapatkan kegagalan khas di mana tunnel terbentuk lalu berhenti meneruskan trafik, karena transport untuk tunnel sekarang berada di dalam tunnel.

Periksa alamat peer seperti Anda memeriksa tujuan dalam, dan pastikan alamat itu menyelesaikan ke antarmuka fisik, bukan ke tunnel:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Rute rekursif, aturan kebijakan yang menangkap peer, atau default yang digantikan oleh klien tunnel penuh adalah tiga penyebab umum. Ketiganya terlihat dalam pencarian luar, dan tidak satu pun terlihat dalam dump tabel utama yang diambil setelah kejadian.

Apa yang tidak bisa diberitahukan oleh keluaran routing

Pencarian yang benar berarti kernel akan mengirim paket ke tempat yang masuk akal. Itu tidak berarti firewall mengizinkannya, kebijakan IPsec mencakupnya, aturan NAT menerjemahkannya, atau sisi jauh memiliki rute balik. Masing-masing adalah tahap berikutnya, dan catatan penerusan strongSwan menjelaskan rantai yang harus dilalui paket di kedua ujung.

Ini juga tidak memperhitungkan pengikatan di tingkat aplikasi. Suatu proses dapat mengikat ke antarmuka, menyetel tanda, atau menggunakan resolver-nya sendiri dan terhubung dengan nama yang menyelesaikan berbeda dari yang Anda uji. Ketika pencarian benar tetapi koneksi tetap gagal, pertanyaan berikutnya adalah proses mana yang membuatnya dan apakah proses itu melihat tabel yang sama dengan Anda.

Jadi jaga diagnosis tetap teratur: sebutkan tujuan dan sumber, jalankan pencarian, baca hanya tabel dan aturan yang disebut pencarian, lalu uji tahap berikutnya. Urutan itu menjaga penyelidikan routing dalam hitungan menit dan meninggalkan catatan yang bisa diikuti orang lain, yang tidak pernah dilakukan tabel yang ditempel.