Mengapa satu subnet masih melewati rute default VPN Anda

Anda mengalihkan VPN ke tunnel penuh, sebagian besar lalu lintas patuh, lalu satu alamat menjawab langsung — printer, NAS, host lompat di 10.x. Bacaan yang jelas adalah tunnel bocor, jadi Anda menurunkan metrik pada rute default dan tidak ada yang berubah. Percobaan yang gagal itulah petunjuknya: rute default adalah cadangan, bukan putusan. Pencarian rute mengambil prefiks terpanjang yang cocok sebelum sempat membandingkan metrik, jadi /24 terus menang melawan /0 berapa pun angka yang Anda pasang pada salah satunya. Begitu urutan itu jelas, kebocoran biasanya berupa rute yang sengaja dipasang seseorang, atau prefiks yang tidak pernah dimaksudkan klien untuk ditutup.

Apa yang sebenarnya dijanjikan rute default

0.0.0.0/0 cocok dengan setiap tujuan IPv4 dengan nol bit kekhususan. Rute ini ada agar host dapat menjangkau apa pun yang tidak dijelaskan lebih baik oleh tabelnya. Rute ke 192.168.1.0/24 membawa 24 bit yang cocok, jadi untuk 192.168.1.40 rute itu menang sebelum siapa pun membandingkan metrik, jarak administratif, atau apa pun yang disebut klien sebagai field prioritas. Aturan yang sama berlaku di FIB Linux, tabel perutean Windows, dan tumpukan BSD di balik macOS.

Di LAN normal, perilaku itu adalah fitur. Subnet lokal terpasang langsung, printer tetap bekerja saat tunnel membawa penjelajahan Anda, dan tidak ada yang salah konfigurasi. Pertanyaan yang layak diajukan bukanlah mengapa satu alamat itu lewat langsung, melainkan prefiks mana di tabel mana yang cocok dengannya, dan siapa yang menaruhnya di sana.

Setengah-default, atau mengapa entri default bisa tampak tak tersentuh

Contoh paling bersih adalah redirect-gateway def1 di OpenVPN. Alih-alih menghapus rute default Anda dan menggantinya, ia menambahkan 0.0.0.0/1 dan 128.0.0.0/1. Bersama-sama pasangan itu menutupi seluruh IPv4, setiap prefiks lebih panjang dari /0, dan keduanya mengalahkan rute default router sambil membiarkannya di tempatnya. Jalankan daftar rute sesudahnya dan rute default asli masih ada, masih menunjuk ke gateway Anda; ia sekadar tidak pernah dipilih untuk tujuan internet.

wg-quick dari WireGuard mencapai hasil yang sama lewat perutean kebijakan. Saat AllowedIPs menutupi 0.0.0.0/0, ia membuat tabelnya sendiri, mengirim paket bertanda ke sana, dan menambahkan aturan yang mengabaikan prefiks panjang nol tabel utama. Tabel utama mempertahankan entri default-nya, dan aturan memutuskan bahwa tabel tunnel dikonsultasikan lebih dulu untuk lalu lintas yang dimiliki antarmuka.

Kedua desain membutuhkan tepat satu rute di luar tunnel: rute host ke alamat server VPN itu sendiri melalui gateway asli. Tanpanya, klien akan mencoba membawa paket yang membangun tunnel di dalam tunnel, dan koneksi tidak akan pernah selesai. Jadi rute non-tunnel di tabel Anda normal bahkan pada profil tunnel penuh yang ketat. Rute yang layak dipertanyakan adalah yang menutupi tujuan yang benar-benar Anda pedulikan.

Metrik memutuskan seri, prefiks memutuskan pemenang

Metrik hanya dibandingkan di antara kandidat yang cocok dengan tujuan sama baiknya. Di Linux, ip route get 10.20.5.9 mencetak pemenang beserta tabelnya, dan ip route show table all mencantumkan kandidat, termasuk setengah-default apa pun dan tabel mana pun yang ditunjuk aturan. Di Windows, Find-NetRoute -RemoteIPAddress 10.20.5.9 mengembalikan rute yang dipilih dan alamat sumber, sedangkan Get-NetRoute menampilkan tabel mentah — tetapi biaya efektifnya adalah metrik rute ditambah metrik antarmuka, jadi adaptor lambat bisa kalah dalam seri yang tampaknya dimenangkannya.

Tiga kasus mencakup sebagian besar dari apa yang akan Anda lihat:

• Tujuan sama, /24 melawan /0: /24 menang berdasarkan panjang prefiks, apa pun kata metrik.
• Tujuan sama, dua /24 dengan metrik berbeda: metrik efektif yang lebih rendah menang.
• Tujuan sama, dua tabel, satu dipilih oleh aturan kebijakan: aturan memilih tabel lebih dulu, dan perbandingan prefiks terjadi di dalamnya.

Kasus ketiga adalah tempat sebagian besar laporan ini berakhir. ip rule Linux atau filter lalu lintas VPN Windows dapat mengirim lalu lintas ke tabel yang tidak pernah memuat default tunnel, dan tabel utama tampak sempurna sepanjang waktu.

Siapa yang biasanya memiliki jalan pintas itu

Mulailah dari profil, bukan tabel. Konfigurasi split-tunnel dan pengaturan VPN per aplikasi sengaja meninggalkan prefiks bernama di luar tunnel; profil kerja yang melindungi satu subnet privat dan membiarkan penjelajahan umum lewat langsung berperilaku sebagaimana dirancang, dan mengabaikannya melanggar kebijakan yang seharusnya ditegakkannya. Panduan perutean VPN Microsoft menarik garis yang sama antara lalu lintas yang dipaksa masuk tunnel dan pengecualian eksplisit, yang membuatnya menjadi pemeriksaan silang yang berguna sebelum Anda mengubah apa pun.

Berikutnya, carilah sisa-sisa. Rute yang menunjuk ke antarmuka yang sudah tidak ada, atau ke alamat dari jaringan sebelumnya, muncul setelah stasiun dok, adaptor USB, dan jembatan kontainer datang dan pergi. Menghapusnya sekali bukanlah akhir: profil koneksi NetworkManager, file netplan, dan rute persisten Windows memasangnya kembali pada koneksi atau boot berikutnya, jadi temukan file atau profil yang memilikinya sebelum mengubah apa pun.

Lalu periksa IPv6 secara terpisah. ip -6 route dan Get-NetRoute -AddressFamily IPv6 menyimpan keadaan terpisah, default terpisah, dan perilaku klien terpisah. Audit hanya-IPv4 tidak mengatakan apa pun tentang host tumpukan ganda yang diam-diam lebih memilih jalur IPv6 asli, dan itu saja bisa membuat klien tampak split-tunnel.

Konfirmasikan dengan alur aplikasi itu sendiri

Catat tujuan yang sebenarnya digunakan aplikasi, lalu tanyakan kepada sistem jalur yang akan diambil dari alamat sumber yang diikat aplikasi itu. ip route get 10.20.5.9 from 192.168.1.40 menjawabnya di Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 ditambah alamat lokal melakukannya di Windows. Bandingkan hasilnya dengan apa yang diklaim profil. Halaman IP publik peramban menguji satu tujuan pada satu protokol dan tidak mengatakan apa pun tentang alamat privat yang memulai keluhan.

Perbaiki objek tersempit yang menjelaskan perbedaan itu. Jika pengecualian disetujui, catat prefiksnya dan biarkan; jika tidak, hapus rute atau tambahkan rute yang lebih sempit secara eksplisit melalui tunnel alih-alih menurunkan metrik default. Menurunkan metrik tidak bisa mengalahkan prefiks yang lebih panjang, dan mengubah default saat dua rute /1 memiliki jalur internet juga tidak mengubah apa pun.

Lalu sambungkan kembali tunnel dan ulangi kueri yang sama. Klien memasang ulang rute pada setiap koneksi, jadi perubahan yang hanya bertahan sampai handshake berikutnya belum diuji. Jika jalur masih menyimpang, tersangka yang tersisa adalah aturan kebijakan, tabel kedua, atau filter sisi klien — bukan rute default.

• Sebutkan tujuan dan alamat sumber yang benar-benar digunakan aplikasi.
• Cetak rute pemenang dengan ip route get atau Find-NetRoute.
• Periksa apakah pasangan /1 atau tabel kebijakan yang memiliki jalur internet.
• Daftar setiap prefiks yang lebih panjang dari /0 yang cocok dengan tujuan.
• Ulangi pemeriksaan IPv6 secara terpisah.
• Lacak rute yang bertahan kembali ke file, profil, atau filter yang memasangnya.
• Sambungkan kembali dan jalankan ulang kueri sebelum menyebutnya beres.

Jika ketujuh hal itu setuju dengan profil, tunnel melakukan tepat apa yang dikonfigurasikan, dan perbaikannya ada di profil, bukan di metrik.