Perutean kebijakan vs SOCKS: lapisan mana yang benar-benar mem-proxy lalu lintas

Anda menambahkan rute kebijakan yang mengirim lalu lintas klien VPN ke host yang menjalankan pendengar SOCKS pada port 1080. Paket tiba, pendengar tidak mencatat apa pun, dan koneksi menggantung. Tidak ada yang salah dengan rutenya: hop berikutnya memilih ke mana paket pergi, dan SOCKS adalah percakapan yang harus dimulai klien. Bandingkan tiga arsitektur yang biasanya dimaksud orang saat mengirim lalu lintas melalui proxy, dan akan jelas bagian mana yang hilang dari penyiapan Anda.

Perutean, DNAT, dan SOCKS mengubah hal yang berbeda

Rute kebijakan menulis ulang keputusan lapisan 3. Dua baris cukup untuk mengirim lalu lintas satu klien ke hop berikutnya yang dipilih:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

Setelah itu, kernel menyerahkan paket ke 10.50.0.2 dengan tujuan asli masih ada di header IP. Jika 10.50.0.2 adalah router, ia meneruskan paket. Jika itu host dengan daemon SOCKS di 1080, paket tidak dialamatkan ke sesuatu yang dapat menerimanya, dan DNAT ke port 1080 juga tidak membantu, karena paket yang diterjemahkan masih membawa muatan aplikasi asli alih-alih salam SOCKS.

SOCKS5 dimulai dengan byte versi, daftar metode, pertukaran autentikasi, dan permintaan yang menyebut tujuan. Itu data aplikasi. Tidak ada entri perutean dan tidak ada target netfilter yang menghasilkannya, dan itulah perbandingannya dalam satu baris: perutean memilih jalur, SOCKS meminta server membuat koneksi kedua.

Kasus satu: aplikasi dapat berbicara SOCKS sendiri

Ketika program memiliki pengaturan proxy, ini jalur terpendek dan tidak memerlukan perubahan kernel. Arahkan ke pendengar, berikan kredensial jika server memintanya, dan putuskan apakah nama diselesaikan secara lokal atau diteruskan ke proxy. Dengan curl itu flag yang berbeda, dan perbedaannya penting ketika tujuan hanya diselesaikan dari sisi proxy:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

Aplikasi yang mengabaikan variabel lingkungan proxy, atau yang membuka soket mentah, tidak dapat dibantu dengan cara ini. Peramban dan sebagian besar perkakas HTTP baik-baik saja; klien gim, daemon surat, atau biner vendor sembarang biasanya tidak. Batasnya per aplikasi dan per protokol, itulah sebabnya opsi ini sangat baik untuk pengujian dan lemah sebagai jawaban untuk seluruh VPN.

Kasus dua: adaptor yang mengubah aliran IP menjadi sesi proxy

Untuk program yang tidak dapat berbicara SOCKS, konversi harus terjadi pada sesuatu yang mengakhiri lalu lintas IP dan membuka sesi proxy atas nama mereka. Komponen itu memiliki antarmuka terowongan, menerima aliran yang dipilih perutean kebijakan, melakukan jabat tangan SOCKS untuk masing-masing, dan membangun ulang balasannya. Rute mengarahkan lalu lintas ke sana; adaptor adalah yang membuat sesinya.

Baca dokumentasinya sebelum mempercayakannya dengan seluruh subnet. Banyak adaptor membawa TCP dengan baik dan menangani UDP hanya melalui asosiasi UDP SOCKS5, dan tidak satu pun mengubah ICMP menjadi lalu lintas proxy, jadi ping yang berhasil tidak mengatakan apa pun tentang jalur proxy. DNS adalah jebakan lainnya: jika adaptor menyelesaikan nama secara lokal, catatan khusus internal diselesaikan ke jawaban yang salah, atau tidak sama sekali.

Pencegahan loop adalah detail operasional yang menggigit. Koneksi adaptor sendiri ke server SOCKS tidak boleh dirutekan kembali ke adaptor, jadi lalu lintasnya memerlukan pengecualian dalam aturan atau alamat sumber khusus. Salah melakukannya dan sesi proxy akan mencoba mem-proxy dirinya sendiri.

Kasus tiga: host sebenarnya adalah gateway ter-route

Kadang-kadang penyiapan yang berfungsi tidak berisi SOCKS sama sekali. Host jarak jauh meneruskan paket atau melakukan NAT, dan aturan berbasis sumber cukup memilihnya sebagai pintu keluar. Desain itu sah, dan menjelaskan mengapa konfigurasi yang disalin berfungsi di satu jaringan dan gagal di jaringan lain: aturannya identik, bagian yang hilang adalah layanan penerusan di sisi seberang.

Ketiga kasus terpisah dengan cepat. Periksa apa yang benar-benar mendengarkan, lalu lihat byte pertama yang mencapai host:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

Byte muatan pertama klien SOCKS asli adalah 0x05, versi dalam salam. Jika tangkapan menunjukkan data aplikasi asli, tidak ada daemon SOCKS yang akan menjawab, karena negosiasi tidak pernah dimulai. Jika tidak ada yang mendengarkan di 1080, host adalah gateway, dan pertanyaannya menjadi apakah ia meneruskan dan apakah ada jalur balik.

Pilih lapisannya dengan empat pertanyaan

Apakah program memiliki pengaturan proxy? Gunakan dan berhenti di situ. Apakah lalu lintas mencakup UDP atau ICMP yang harus bertahan? Hanya gateway ter-route atau NAT yang membawa ICMP, dan UDP memerlukan asosiasi SOCKS5 yang didukung kedua ujung. Apakah setiap proses di mesin harus tercakup, termasuk yang tidak dapat Anda konfigurasi? Maka Anda perlu adaptor yang memiliki antarmuka dan mengakhiri aliran. Dapatkah Anda juga mengambil alih perutean, DNS, dan pengecualian pencegahan loop-nya? Jika tidak, gateway biasa akan lebih murah dioperasikan.

Satu perbedaan layak dijaga lurus. Opsi socks-proxy milik klien VPN menjelaskan bagaimana koneksi terowongan luar mencapai servernya, dan tidak mengatakan apa pun tentang mengonversi aliran klien dalam. Keduanya terus tertukar di tiket yang sama. Putuskan hubungan mana yang Anda butuhkan sebelum menyentuh rute.