Dante SOCKS melalui VPN: tunnel penuh dan routing sumber

Anda ingin lalu lintas proxy SOCKS keluar lewat VPN sementara sisa host tetap memakai jalur normalnya. Ada dua rancangan untuk itu, dan keduanya berbeda dalam hal apa yang rusak ketika ada masalah. Satu rancangan mendorong rute default ke dalam tunnel lalu mencari akal untuk mengatasinya; rancangan lain membiarkan tabel utama apa adanya dan mengirim satu alamat sumber ke tabel kedua. Yang kedua lebih bersih, dan ia punya jebakan sendiri.

Dua rancangan, dua radius kerusakan berbeda

Rancangan tunnel penuh adalah yang dilakukan sebagian besar klien VPN secara default: ganti rute default supaya semuanya mengikuti tunnel, lalu kecualikan yang seharusnya tidak. Mudah dipahami dan sulit dijaga tetap sempit, karena setiap layanan lokal yang Anda tambahkan ikut mewarisi tunnel sampai Anda mengecualikannya. Pola kegagalannya luas, sebab satu rute yang salah ikut menyeret konektivitas host itu sendiri.

Rancangan berbasis sumber bergerak sebaliknya. Tabel utama tetap seperti semula, dan satu aturan kebijakan mengirim paket dari alamat lokal tertentu ke tabel yang punya default tunnel. Tidak ada yang lain berubah, yang berarti radius kerusakannya hanya satu alamat.

Sempitnya cakupan itu juga menjadi batasannya: rancangan ini hanya bekerja jika paket keluar dari proxy benar-benar membawa alamat tersebut.

Apa yang dilakukan pengaturan external di Dante

Pengaturan external memilih alamat yang dipakai proxy untuk koneksi keluar; ia tidak menyentuh kebijakan perutean kernel. Pemisahan itulah yang memungkinkan rancangan kedua, dan di situlah orang salah membaca dokumentasinya. Mengarahkan external ke alamat tunnel membuat proxy memakai alamat itu sebagai sumber koneksinya, lalu tabel rute yang menentukan ke mana paket tersebut pergi.

Listener adalah urusan terpisah. Batasi internal hanya pada klien yang seharusnya memakai proxy, wajibkan autentikasi, dan pasang firewall pada porta, karena listener terbuka bukanlah fitur dari egress VPN.

Pastikan alamat yang dikonfigurasi memang milik tunnel di dalam network namespace proxy.

Membangun tabel berbasis sumber

Untuk alamat TUN 10.90.0.2/24 dengan peer yang dapat dijangkau di 10.90.0.1, dan nomor tabel yang tidak dipakai hal lain, susunannya seperti ini:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

Rute unreachable adalah bagian yang sering dilewatkan orang. Tanpanya, tabel yang rute tunnel-nya hilang akan jatuh ke default biasa dan proxy diam-diam keluar lewat WAN. Dengan rute itu, pencarian gagal, yang merupakan kegagalan terlihat alih-alih kebocoran senyap. Prioritas aturan juga harus berada di depan apa pun yang cocok dengan sumber tersebut.

Nilai-nilai ini menggambarkan satu topologi. Peer point-to-point, pengalamatan net30, dan klien yang membagikan prefiks berbeda semuanya perlu rute sendiri, jadi salin bentuknya, bukan alamatnya.

Di mana aturan sumber bocor

Aturan yang mencocokkan alamat sumber memengaruhi setiap proses yang memakainya, bukan hanya proxy. Jika daemon lain mengikat alamat yang sama, lalu lintasnya juga masuk tunnel, dan kegagalannya akan terlihat seperti masalah layanan yang tidak berkaitan. Beri proxy alamat yang tidak dipakai hal lain, atau terima bahwa cakupannya adalah alamat, bukan proses.

DNS adalah kebocoran lainnya. Soket resolver belum tentu memakai sumber koneksi data eksternal proxy, sehingga pencarian nama masih bisa keluar lewat WAN. Uji resolusi secara terpisah dari pembentukan koneksi, dan putuskan apakah hasil itu dapat diterima.

IPv6 perlu aturan dan rute sendiri, karena pengaturan IPv4 tidak membuktikan apa pun tentangnya.

Pilih berdasarkan kegagalan yang bisa Anda tahan

Pilih tunnel penuh bila host harus dilindungi secara keseluruhan dan Anda sanggup memelihara daftar pengecualian. Pilih perutean berbasis sumber bila host harus mempertahankan jalurnya sendiri dan hanya satu layanan yang perlu dialihkan. Keduanya sah; kesalahannya adalah memilih salah satu lalu mengujinya seolah-olah itu yang lain.

Apa pun pilihannya, uji dari dua sisi: permintaan lewat proxy dan permintaan langsung dari host, dengan alamat keluar yang teramati dicatat untuk masing-masing.

Jika tunnel putus, putuskan lebih dulu apakah proxy harus gagal atau beralih cadangan, dan biarkan tabel rute yang menyatakan keputusan itu.