Penghalaan dasar lwn SOCKS: lapisan mana yang sebenarnya memproksi trafik

Anda menambah laluan dasar yang menghantar trafik klien VPN ke hos yang menjalankan pendengar SOCKS pada port 1080. Paket tiba, pendengar tidak mencatat apa-apa, dan sambungan tergantung. Tiada apa-apa yang salah dengan laluan itu: hop seterusnya memilih ke mana paket pergi, dan SOCKS ialah perbualan yang klien mesti mulakan. Bandingkan tiga seni bina yang biasanya dimaksudkan orang apabila menghantar trafik melalui proksi, dan akan jelas bahagian mana yang hilang daripada persediaan anda.

Penghalaan, DNAT dan SOCKS mengubah perkara yang berbeza

Laluan dasar menulis semula keputusan lapisan 3. Dua baris cukup untuk menghantar trafik satu klien ke hop seterusnya yang dipilih:

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

Selepas itu, kernel menyerahkan paket kepada 10.50.0.2 dengan destinasi asal masih dalam pengepala IP. Jika 10.50.0.2 ialah penghala, ia memajukan paket. Jika ia hos dengan daemon SOCKS pada 1080, paket itu tidak dialamatkan kepada apa-apa yang boleh menerimanya, dan DNAT ke port 1080 juga tidak membantu, kerana paket yang diterjemah masih membawa muatan aplikasi asal dan bukannya sapaan SOCKS.

SOCKS5 bermula dengan bait versi, senarai kaedah, pertukaran pengesahan dan permintaan yang menamakan destinasi. Itu data aplikasi. Tiada entri penghalaan dan tiada sasaran netfilter menjananya, dan itulah perbandingan dalam satu baris: penghalaan memilih laluan, SOCKS meminta pelayan membuat sambungan kedua.

Kes satu: aplikasi boleh bercakap SOCKS sendiri

Apabila program mempunyai tetapan proksi, ini laluan terpendek dan ia tidak memerlukan perubahan kernel. Halakan ia ke pendengar, berikan kelayakan jika pelayan memintanya, dan tentukan sama ada nama diselesaikan secara tempatan atau dihantar kepada proksi. Dengan curl ini bendera yang berbeza, dan perbezaannya penting apabila destinasi hanya diselesaikan dari sebelah proksi:

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 pemboleh ubah persekitaran proksi, atau yang membuka soket mentah, tidak boleh dibantu dengan cara ini. Pelayar dan kebanyakan alat HTTP baik-baik saja; klien permainan, daemon mel atau binari vendor sewenang-wenangnya biasanya tidak. Sempadan itu mengikut aplikasi dan mengikut protokol, sebab itulah pilihan ini sangat baik untuk ujian dan lemah sebagai jawapan untuk seluruh VPN.

Kes dua: penyesuai yang menukar aliran IP kepada sesi proksi

Bagi program yang tidak boleh bercakap SOCKS, penukaran mesti berlaku dalam sesuatu yang menamatkan trafik IP dan membuka sesi proksi bagi pihak mereka. Komponen itu memiliki antara muka terowong, menerima aliran yang dipilih oleh penghalaan dasar, melakukan jabat tangan SOCKS untuk setiap satu dan membina semula balasan. Laluan mengarahkan trafik ke arahnya; penyesuai itulah yang mencipta sesi.

Baca dokumentasinya sebelum mempercayakannya dengan seluruh subrangkaian. Banyak penyesuai membawa TCP dengan baik dan hanya mengendalikan UDP melalui persatuan UDP SOCKS5, dan tiada satu pun daripadanya menukar ICMP kepada trafik proksi, jadi ping yang berjaya tidak memberitahu apa-apa tentang laluan proksi. DNS ialah perangkap yang lain: jika penyesuai menyelesaikan nama secara tempatan, rekod dalaman sahaja diselesaikan kepada jawapan yang salah, atau kepada tiada apa-apa.

Pencegahan gelung ialah perincian operasi yang menggigit. Sambungan penyesuai sendiri ke pelayan SOCKS tidak boleh dihalakan semula ke dalam penyesuai, jadi trafiknya memerlukan pengecualian dalam peraturan atau alamat sumber khusus. Lakukan dengan salah dan sesi proksi akan cuba memproksi dirinya sendiri.

Kes tiga: hos itu sebenarnya get laluan berpenghala

Kadangkala persediaan yang berfungsi tidak mengandungi SOCKS sama sekali. Hos jauh memajukan paket atau melakukan NAT ke atasnya, dan peraturan berasaskan sumber hanya memilihnya sebagai saluran keluar. Reka bentuk itu sah, dan ia menjelaskan mengapa konfigurasi yang disalin berfungsi pada satu rangkaian dan gagal pada rangkaian lain: peraturannya sama, bahagian yang hilang ialah perkhidmatan pemajuan di sebelah sana.

Ketiga-tiga kes berpisah dengan cepat. Periksa apa yang sebenarnya mendengar, kemudian lihat bait pertama yang sampai ke hos:

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

Bait muatan pertama klien SOCKS sebenar ialah 0x05, versi dalam sapaan. Jika tangkapan menunjukkan data aplikasi asal, tiada daemon SOCKS akan menjawab, kerana rundingan tidak pernah bermula. Jika tiada apa-apa yang mendengar pada 1080, hos itu ialah get laluan, dan persoalannya menjadi sama ada ia memajukan dan sama ada laluan balik wujud.

Pilih lapisan dengan empat soalan

Adakah program mempunyai tetapan proksi? Gunakannya dan berhenti di situ. Adakah trafik termasuk UDP atau ICMP yang mesti bertahan? Hanya get laluan berpenghala atau NAT membawa ICMP, dan UDP memerlukan persatuan SOCKS5 yang disokong kedua-dua hujung. Adakah setiap proses pada mesin mesti dilindungi, termasuk yang anda tidak boleh konfigurasi? Maka anda perlu penyesuai yang memiliki antara muka dan menamatkan aliran. Bolehkah anda juga mengambil alih penghalaan, DNS dan pengecualian pencegahan gelungnya? Jika tidak, get laluan biasa akan lebih murah untuk dikendalikan.

Satu perbezaan wajar dikekalkan lurus. Pilihan socks-proxy milik klien VPN menerangkan bagaimana sambungan terowong luar sampai ke pelayannya, dan tidak mengatakan apa-apa tentang menukar aliran klien dalaman. Kedua-duanya sentiasa dikelirukan dalam tiket yang sama. Tentukan hubungan mana yang anda perlukan sebelum menyentuh laluan.