Proksi SOCKS5 dan SOCKS4

Proksi SOCKS memungkinkan aplikasi meminta server perantara terhubung ke tujuan untuknya. Proksi membuka koneksi yang diminta dan meneruskan data ke kedua arah. Aplikasi tetap menggunakan protokolnya sendiri, sehingga ini berfungsi untuk permintaan web, klien API, transfer berkas, dan perangkat lunak lain dengan dukungan SOCKS.

Untuk konfigurasi baru, SOCKS5 biasanya memberi pilihan paling berguna: lebih banyak format alamat, pilihan metode autentikasi, dan dukungan UDP. SOCKS4 tetap berguna untuk perangkat lunak yang memerlukan versi lama. Pilihan umum antara protokol ini dan proksi HTTP dibahas dalam Proksi SOCKS dan HTTP.

Cara aplikasi terhubung melalui SOCKS

Pertimbangkan aplikasi yang membuka https://example.com/ melalui proksi SOCKS5. Aplikasi terlebih dahulu mencapai proksi, memintanya membuka koneksi ke situs, dan baru kemudian bertukar data situs. Prosesnya memiliki empat tahap:

1. Aplikasi terhubung ke nama host atau IP dan port penerima proksi melalui TCP.
2. Aplikasi dan proksi memilih metode akses. Jika metode itu memerlukan kredensial, aplikasi memberikannya dan proksi memeriksanya.
3. Aplikasi mengirim permintaan SOCKS CONNECT dengan alamat dan port tujuan. Proksi memeriksa aturan aksesnya, mencoba koneksi selanjutnya, dan melaporkan hasilnya.
4. Setelah balasan berhasil, aplikasi berkomunikasi dengan tujuan melalui proksi. Untuk situs HTTPS, aplikasi membentuk TLS dengan situs dan memverifikasi sertifikatnya sebelum mengirim permintaan web.

Kedua nomor port dimiliki server berbeda. Contoh proksi dapat menerima koneksi di proxy.example:1080, sementara situs dicapai di example.com:443. Port 1080 lazim untuk SOCKS, tetapi layanan dapat menggunakan port lain. Gunakan port penerima yang diberikan untuk proksi Anda; port itu tidak menggantikan port tujuan.

Selama penerusan TCP biasa, SOCKS meneruskan aliran bita aplikasi tanpa perlu menafsirkan setiap permintaan HTTP atau perintah berkas. Aplikasi tetap berbicara dengan protokolnya sendiri kepada tujuan. Karena itu, mekanisme koneksi SOCKS yang sama dapat melayani klien web dan jenis perangkat lunak lain.

CONNECT adalah perintah dalam SOCKS dengan format pesannya sendiri; perintah itu berbeda dari metode HTTP CONNECT. SOCKS juga mendefinisikan BIND untuk aplikasi yang memerlukan server terhubung kembali melalui proksi, seperti yang dapat terjadi pada FTP aktif. BIND memerlukan dukungan terpisah dan tidak digunakan untuk permintaan situs atau API biasa.

Perubahan antara SOCKS4, SOCKS4a, dan SOCKS5

SOCKS4 membuka koneksi TCP ke alamat IPv4. SOCKS4a menambahkan pilihan mengirim nama host, sehingga proksi dapat mencari IP-nya melalui DNS. SOCKS5 menambahkan pilihan metode autentikasi, menerima alamat IPv4, alamat IPv6, dan nama host, serta mendefinisikan penerusan UDP.

Ini adalah kemampuan protokol. Klien dan layanan proksi harus menerapkan fitur tertentu yang ingin Anda gunakan. Misalnya, layanan SOCKS5 dapat menangani koneksi TCP tanpa menawarkan relai UDP yang dapat digunakan.

SOCKS5 dapat membawa tujuan IPv6 dalam permintaannya, tetapi proksi juga harus mampu mencapai server IPv6 itu. Kedua koneksi dapat menggunakan versi IP berbeda: aplikasi dapat mencapai proksi melalui IPv4, sementara proksi terhubung ke tujuan melalui IPv6.

SOCKS4a adalah ekstensi SOCKS4, bukan nama lain untuk setiap koneksi SOCKS4. Jika klien lama hanya mengirim alamat IPv4, memilih SOCKS4 tidak memberinya DNS jarak jauh. SOCKS4a memerlukan dukungan pada kedua ujung. SOCKS5 biasanya merupakan pilihan lebih sederhana ketika kedua ujung mendukungnya; memilih SOCKS4 tidak dengan sendirinya meningkatkan reputasi atau kecepatan IP keluar.

Siapa yang meresolusi nama tujuan

Sebelum koneksi dapat mencapai server bernama, namanya harus diterjemahkan menjadi alamat IP. SOCKS5 dapat menerima hasil pencarian itu atau nama itu sendiri. Pengaturan DNS klien menentukan mana yang dikirim.

Dengan DNS lokal, aplikasi menanyakan reports.example kepada resolver yang dikonfigurasi. Misalkan jawabannya 203.0.113.27: aplikasi kemudian meminta koneksi SOCKS ke 203.0.113.27:443. Pencarian sudah terjadi pada sisi klien, meskipun koneksi situs berikutnya melewati proksi.

Dengan DNS di sisi proksi, aplikasi mengirim reports.example:443 tanpa terlebih dahulu mencari tujuan itu secara lokal. Proksi memperoleh IP-nya melalui DNS dan membuka koneksi yang diminta. Nama host mencapai proksi sebagai bagian dari permintaan SOCKS.

Ini dapat membantu ketika klien tidak dapat meresolusi nama yang dapat diresolusi proksi. Beberapa layanan mengembalikan alamat berbeda tergantung resolver DNS, sehingga memindahkan pencarian dapat mengubah server yang menerima koneksi. Ini tidak mengatur negara keluar proksi atau menjamin situs menerima permintaan.

Dalam curl, dua perintah berikut memilih kedua mode DNS:

curl --proxy socks5://proxy.example:1080 https://example.com/
curl --proxy socks5h://proxy.example:1080 https://example.com/

socks5:// membuat curl meresolusi nama situs secara lokal; socks5h:// meneruskannya ke proksi. Keduanya menggunakan SOCKS5. h berarti resolusi nama host oleh proksi dalam sintaks URL klien ini. Huruf itu tidak mengubah SOCKS5 menjadi HTTPS atau menambahkan enkripsi. Aplikasi lain dapat menggunakan kotak centang atau memilih DNS jarak jauh otomatis. Ganti nama host dan port proksi contoh dengan detail layanan Anda serta berikan autentikasi yang diwajibkan.

Mengirim nama domain dalam permintaan TCP SOCKS5 tidak memerlukan dukungan relai UDP. Proksi melakukan pencarian menggunakan konfigurasi DNS-nya sendiri. Ini berbeda dari meminta SOCKS5 membawa paket UDP klien.

Jika klien dikonfigurasi untuk menyerahkan DNS tujuan kepada proksi tetapi melakukan pencarian itu secara lokal, klien mengekspos nama yang diminta di luar rute yang dimaksud. Ini adalah kebocoran DNS. DNS terenkripsi melindungi pertukaran dengan resolver, tetapi resolver tersebut tetap menerima namanya. Mencari nama host proksi itu sendiri merupakan tugas terpisah, dan aplikasi lain mempertahankan perilaku DNS sendiri. DNS jarak jauh dalam satu program tidak memindahkan setiap pencarian pada perangkat.

Autentikasi dan enkripsi

SOCKS5 memungkinkan klien menawarkan metode autentikasi yang didukung dan proksi memilih salah satunya. Nama pengguna dan kata sandi adalah salah satu pilihan. Pilihan lain adalah koneksi tanpa pertukaran login SOCKS, yang dapat diizinkan layanan setelah mencocokkan IP sumber klien dengan daftar IP yang diizinkan. Karena itu, titik koneksi tanpa kolom kata sandi tetap dapat membatasi akses.

Kegagalan menyepakati metode berbeda dari kata sandi yang ditolak: dalam kasus pertama, pertukaran kata sandi belum terjadi. Klien tanpa dukungan nama pengguna/kata sandi tidak dapat menggunakan titik koneksi SOCKS5 yang hanya menerima kata sandi hanya karena memiliki pengaturan SOCKS5. SOCKS4 memiliki kolom ID pengguna tetapi tidak memiliki pertukaran kata sandi standar yang setara; servernya tetap dapat menerapkan aturan akses.

Pertukaran nama pengguna/kata sandi SOCKS5 yang biasa tidak mengenkripsi kredensial. Pertukaran berlangsung sebelum aplikasi membentuk HTTPS dengan tujuan, sehingga koneksi HTTPS berikutnya tidak melindungi login proksi sebelumnya. Enkripsi jalur klien-ke-proksi memerlukan koneksi terlindungi terpisah atau mekanisme keamanan yang didukung secara eksplisit.

Selama penerusan SOCKS biasa, HTTPS melindungi pertukaran aplikasi dengan situs, dengan verifikasi sertifikat aktif dan tanpa intersepsi TLS. Protokol aplikasi tidak terenkripsi tetap tidak terenkripsi melalui relai. Dukungan SOCKS5 atau autentikasi kata sandi saja tidak menjanjikan trafik terenkripsi.

Proksi tetap mengetahui IP klien yang terhubung, tujuan yang diminta, dan waktu koneksi. Tujuan melihat IP keluar proksi dan menerima data aplikasi yang ditujukan kepadanya. Cookie, login akun, dan pengenal aplikasi lain masih dapat mengidentifikasi pengguna; mengubah versi SOCKS tidak menghapusnya.

Cara SOCKS5 membawa TCP dan UDP

TCP menyediakan aliran bita yang berurutan. Permintaan browser, panggilan API, atau sesi SSH dapat menggunakan koneksi TCP SOCKS ketika klien mendukung rute itu dan proksi mengizinkan tujuan. Keberhasilan pada port 443 situs tidak membuktikan port aplikasi lain tersedia.

UDP mengirim datagram terpisah. Klien SOCKS5 terlebih dahulu membuka koneksi kendali TCP dan meminta relai menggunakan UDP ASSOCIATE. Proksi mengembalikan alamat dan port UDP relai. Klien mengirim datagramnya ke sana dengan header SOCKS yang menjelaskan tujuannya. Menutup koneksi kendali TCP mengakhiri asosiasi UDP ini; datagram berjalan terpisah dari koneksi kendali, bukan di dalam aliran SOCKS CONNECT biasa.

Aplikasi dan layanan harus sama-sama mendukung mekanisme ini, dan jaringan harus mengizinkan jalur UDP. Program dapat menyelesaikan login TCP sementara fungsi suara, gim, atau UDP lainnya masih gagal. Permintaan HTTPS yang berhasil melalui SOCKS CONNECT membuktikan penerusan TCP, bukan UDP yang berfungsi. QUIC menggunakan UDP, tetapi QUIC yang dapat digunakan juga bergantung pada klien dan seluruh jalur; label SOCKS5 saja tidak membuktikannya.

Kegunaan SOCKS

SOCKS berguna ketika perangkat lunak memerlukan koneksi perantara sambil mempertahankan protokol aplikasinya sendiri. Skrip dapat meminta data API melalui IP keluar alokasi, klien transfer berkas dapat mencapai server jarak jauh melalui rute yang disetujui, dan aplikasi desktop yang sesuai dapat menggunakan proksi tanpa menjadi browser web. Setiap kasus bergantung pada dukungan SOCKS klien dan port tujuan yang diizinkan layanan.

Untuk pekerjaan berulang dengan akun atau server yang sama, jalur keluar tetap mungkin sesuai. Untuk tugas terpisah, layanan berotasi mungkin berguna. SOCKS4 dan SOCKS5 tidak menentukan perilaku ini: layanan menentukan IP keluar, jenis jaringannya, apakah pelanggan lain menggunakannya, dan kapan alamat berubah. Versi protokol juga tidak memberikan peringkat kecepatan; panjang rute, beban server, dan lebar pita tersedia memengaruhi hasil.

Dukungan klien dapat lebih sempit daripada protokol. Implementasi SOCKS5 bawaan Chrome meresolusi nama tujuan melalui proksi tetapi tidak melakukan autentikasi nama pengguna/kata sandi SOCKS5 atau merelai UDP. Karena itu, titik koneksi khusus kata sandi dapat berfungsi di curl dan gagal melalui pengaturan browser bawaan tersebut. Adaptor eksternal merupakan bagian koneksi terpisah dengan kemampuannya sendiri.

Proksi yang dikonfigurasi di dalam satu program berlaku untuk koneksi yang didukung program itu. Proksi tidak mengonfigurasi pengunduh atau skrip terpisah. Pengaturan proksi sistem juga memengaruhi perangkat lunak yang menggunakannya. Ketika adaptor mengalihkan koneksi dari aplikasi tanpa dukungan SOCKS bawaan, cakupan TCP, UDP, dan DNS-nya penting. SOCKS tidak menyediakan penerusan ICMP biasa, sehingga ping bukan pengujian jalur proksi ini.

Pengaturan koneksi dan pengujian yang berguna

Mulai dengan alamat proksi, port penerima, versi SOCKS, dan metode akses yang diberikan untuk titik koneksi. Nomor seperti 1080 tidak mengidentifikasi protokol dengan sendirinya. Pilih SOCKS dalam klien, bukan memasukkan alamat yang sama ke kolom proksi khusus HTTP.

Kredensial proksi mengotorisasi penggunaan perantara; login situs mengotorisasi penggunaan situs. Keduanya berada dalam pengaturan berbeda. Dalam curl, --proxy-user memberikan kredensial proksi, sementara --user memberikan kredensial tujuan. Untuk akses berbasis IP, daftar IP yang diizinkan harus cocok dengan IP sumber klien yang dilihat proksi, yang dapat berubah ketika klien berganti jaringan.

Pilih mode DNS yang dimaksud, lalu periksa aturan pengecualian. Proksi yang dikonfigurasi dapat dilewati untuk tujuan pada daftar pengecualian. Dalam curl, NO_PROXY dapat menyebabkan hal ini; --noproxy "" menghapus pengecualian itu untuk satu pemanggilan ketika Anda sengaja ingin menguji rute proksi.

Uji dari program sebenarnya yang akan melakukan pekerjaan. Titik koneksi pemeriksa IP atau log server tujuan yang Anda kendalikan dapat menunjukkan IP sumber permintaan. Bandingkan hasil itu dengan permintaan langsung. Alamat untuk mencapai proksi dan alamat keluar yang dilihat tujuan belum tentu sama.

Kemudian coba tugas sebenarnya. IP yang berubah menunjukkan rute permintaan yang diuji, tetapi tidak mengukur semua transport atau memastikan respons situs lain. Uji UDP atau IPv6 secara terpisah jika tugas memerlukannya, dan nilai waktu respons serta stabilitas koneksi pada beban kerja yang representatif.

Temukan kesalahan berdasarkan tahap koneksinya

Bedakan mencapai proksi, memperoleh akses, membuka koneksi tujuan, dan menerima respons aplikasi. Tahap-tahap ini memiliki penyebab kegagalan berbeda.

Jika koneksi HTTPS terverifikasi berhasil dan situs mengembalikan halaman login, CAPTCHA, atau penolakan akses, koneksi SOCKS sudah membawa pertukaran itu. Selidiki respons situs dan perilaku aplikasi. Jika permintaan justru menunjukkan IP publik biasa Anda, periksa proksi terpilih dan aturan pengecualian dalam program itu.