Aplikasi yang Terikat ke Alamat VPN Tetap Memakai Rute yang Salah

Sebuah aplikasi mengikat ke alamat VPN, dan koneksinya tetap keluar melalui rute default biasa. Tidak ada yang gagal dalam bind; ia melakukan persis apa yang dilakukan bind. Mengikat socket ke alamat lokal memilih alamat sumber yang dipasang kernel di header. Ini tidak memasang rute, dan tidak membuat aturan kebijakan yang mengirim paket dengan sumber itu ke tunnel tertentu.

Sisa runbook ini adalah urutan pemeriksaan yang saya pakai, bersama perintah yang menghasilkan setiap pengamatan.

Apa yang sebenarnya diputuskan bind

Bind memberikan alamat lokal ke socket. Kernel lalu menjalankan pencarian rute yang sama seperti yang akan dijalankannya jika tidak, kecuali aturan kebijakan mengubah tabel mana yang dibaca pencarian itu.

Itulah sebabnya paket bisa keluar dengan alamat sumber VPN pada antarmuka fisik. Di sisi lain ia datang dari rentang privat yang tidak pernah diharapkan jaringan pada jalur itu, lalu lintas balik tidak punya rute kembali, dan koneksi menggantung atau direset.

Referensi socket IP Linux mendokumentasikan semantik bind. Bagian routing tinggal di ip-rule dan ip-route, dan keduanya halaman manual terpisah karena suatu alasan.

Pastikan alamat itu milik namespace ini

Alamat yang bisa Anda ikat harus ada pada antarmuka di dalam namespace jaringan tempat aplikasi berjalan. Alamat peer, alamat gateway, atau alamat yang hanya ada di namespace lain tidak dapat diikat, dan pemanggilan gagal dengan EADDRNOTAVAIL.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

Jalankan ketiganya dalam konteks yang sama dengan aplikasi: namespace yang sama, dan pengguna yang sama jika bisa diperoleh. Diagram net30 lama bukan bukti alamat mana yang diberikan topologi Anda saat ini ke klien. Baca antarmuka yang benar-benar aktif.

Baca pencarian untuk sumber dan tujuan itu

Satu perintah menjawab pertanyaan yang tidak dijawab bind:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

Baris pertama mencetak rute yang akan diambil paket dari sumber itu ke tujuan itu, termasuk antarmuka keluar dan sumber pilihan. Jika ia menyebut antarmuka fisik, bind dan rute tidak sepakat, dan paket akan keluar dengan sumber yang tidak bisa dituju kembali oleh jalur tersebut.

Lalu ip rule show memberi tahu apakah ada aturan yang akan memilih tabel lain. Prioritas penting di sini, karena aturan pertama yang cocok menang, dan aturan penangkap semua di atas aturan Anda membuat aturan Anda tak terlihat.

Pasang aturan kebijakan hanya jika memang itu desainnya

Routing berbasis sumber adalah desain yang disengaja, bukan perbaikan untuk satu aplikasi. Jika pemilik kebijakan ingin lalu lintas dari subnet tunnel memakai tunnel, aturan itu milik konfigurasi pemilik tersebut, bukan perintah sekali pakai di laptop Anda.

Bentuk yang bisa dipakai adalah tabel khusus dengan rute default melalui tunnel, ditambah aturan yang mengirim rentang sumber VPN ke tabel itu. Tambahkan pengecualian yang dibutuhkan desain, karena tabel yang hanya berisi default tunnel akan menangkap tujuan yang seharusnya tetap lokal atau dapat dijangkau lewat jalur fisik.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

Batalkan dengan ip rule del dan ip route flush table 100. Apa pun yang ditambahkan dengan cara ini hilang saat reboot kecuali ada manajer yang menulisnya, yang sekaligus menjadi sifat keamanan dan alasan untuk tidak menyimpan satu-satunya salinan di riwayat shell Anda.

Verifikasi dengan tiga pengamatan

Catat sumber yang diminta aplikasi, rute yang dipilih pencarian, dan sumber yang benar-benar dilihat server.

Ketiganya bisa tidak sepakat, dan setiap ketidaksepakatan menunjuk ke tempat berbeda. Tangkapan pada antarmuka tunnel membuktikan paket keluar dengan sumber yang benar. Tangkapan pada antarmuka fisik membuktikan paket keluar lewat jalur yang salah. Tampilan sisi server adalah satu-satunya yang membuktikan jalur dari ujung ke ujung.

Jika aplikasi menawarkan opsi ikat-ke-perangkat atau mode routing per aplikasi, perlakukan itu sebagai mekanisme berbeda dengan batasan berbeda. Setelan yang tampak serupa tidak semuanya berujung pada keputusan kernel yang sama.