Autentikasi Proksi dengan Nama Pengguna dan Kata Sandi: Cara Terhubung dan Menghindari Kesalahan
Dengan autentikasi nama pengguna dan kata sandi, aplikasi mengirimkan kredensial yang diberikan penyedia kepada proksi. Proksi memeriksanya dan mengizinkan Anda menggunakan layanan. Metode ini berguna saat bekerja dari perangkat dan jaringan berbeda: jika layanan tidak juga mewajibkan otorisasi berdasarkan IP, memindahkan skrip ke server lain tidak memerlukan perubahan alamat IP yang diizinkan.
Koneksi yang berfungsi memerlukan lebih dari nama pengguna dan kata sandi. Anda juga memerlukan alamat, port, dan protokol proksi yang benar. Aplikasi harus mendukung metode autentikasi yang diperlukan. Karena itu, kesalahan autentikasi tidak selalu berarti kata sandinya salah.
Untuk membandingkan metode akses dan memilih salah satunya, lihat Autentikasi Proksi. Artikel ini membahas koneksi dengan nama pengguna dan kata sandi, mulai dari memasukkan pengaturan hingga mendiagnosis masalah pada skrip yang sedang digunakan.
Arti autentikasi dengan nama pengguna dan kata sandi
Nama pengguna mengidentifikasi akun atau akses ke layanan tertentu, sedangkan kata sandi mengonfirmasi hak Anda untuk menggunakannya. Setelah pemeriksaan berhasil, proksi menangani koneksi sesuai izin yang diberikan: daftar alamat yang tersedia, kuota yang dibeli, dan batas yang berlaku.
Kredensial proksi tidak boleh disamakan dengan kata sandi dasbor. Detail yang digunakan aplikasi mungkin berbeda dari detail untuk masuk ke situs penyedia. Kunci API digunakan untuk permintaan ke API layanan, sedangkan kata sandi situs tujuan digunakan untuk masuk ke situs tersebut. Gunakan salah satunya sebagai kata sandi proksi hanya jika penyedia secara jelas menetapkan metode koneksi itu.
Autentikasi proksi yang berhasil tidak membuat Anda login ke situs web tujuan. Jika situs memerlukan akun, cookie, atau tokennya sendiri, aplikasi tetap harus menyediakannya secara terpisah.
Kapan metode ini berguna
Akses dengan nama pengguna dan kata sandi dapat digunakan oleh aplikasi di beberapa lokasi, baik lokasi tersebut tetap maupun berubah. Tanpa pembatasan IP, setiap aplikasi memerlukan kredensial dan pengaturan koneksi proksi, tanpa entri daftar izin terpisah untuk jaringannya.
Contohnya, suatu tim bekerja dari dua kantor dan rumah, masing-masing dengan IP publik berbeda. Aplikasi dapat menggunakan kredensial proksi yang sama jika layanan mengizinkan aplikasi tersebut berbagi kredensial tanpa pengikatan IP. Setiap aplikasi menyimpan pengaturan koneksinya sendiri; proksi memeriksa kredensial yang dikirim masing-masing aplikasi.
Metode ini juga dapat digunakan untuk beberapa server tetap. Namun, jumlah perangkat, koneksi bersamaan, dan sumber daya yang tersedia bergantung pada paket. Satu kata sandi tidak memberikan akses tanpa batas.
Cara aplikasi mengirimkan kredensial proksi
Urutan umumnya sederhana: aplikasi menghubungi proksi, lolos pemeriksaan akses, lalu menggunakannya untuk menjangkau sumber daya yang diminta. Detailnya bergantung pada protokol.
Proksi HTTP dapat terlebih dahulu mengembalikan 407 Proxy Authentication Required dan menunjukkan metode autentikasi yang diterimanya. Aplikasi mengirimkan informasi autentikasi dalam header Proxy-Authorization. Beberapa klien langsung mengirimkannya, sehingga tantangan awal mungkin tidak muncul di log.
Saat membuka situs HTTPS melalui proksi HTTP biasa, autentikasi dapat berlangsung pada permintaan CONNECT yang membentuk terowongan. Setelah itu, aplikasi membentuk koneksi aman ke situs web. Permintaan situs berikutnya melalui terowongan yang sudah terbentuk tidak mengulangi login proksi yang digunakan saat membukanya.
Pada SOCKS5, nama pengguna dan kata sandi diperiksa di awal koneksi, sebelum permintaan koneksi ke tujuan. Jika pemeriksaan gagal, aplikasi tidak memperoleh koneksi yang diminta melalui proksi. Kegagalan autentikasi bawaan SOCKS5 bukan respons HTTP 407.
Pilih protokol dan metode autentikasi yang didukung layanan. SOCKS4 memiliki kolom ID pengguna, tetapi tidak menetapkan pertukaran nama pengguna dan kata sandi SOCKS5. Mengisi kolom tersebut tidak dapat membuat klien SOCKS4 menjalankan autentikasi kata sandi SOCKS5.
Pengaturan yang perlu dimasukkan ke aplikasi
Mulailah dengan detail koneksi untuk layanan Anda. Jika aplikasi menyediakan kolom terpisah, masukkan setiap nilai ke kolomnya masing-masing:
| Pengaturan | Yang perlu dimasukkan | Yang perlu diperiksa |
|---|---|---|
| Protokol | HTTP, HTTPS, atau SOCKS5, sesuai ketentuan layanan. | Protokol yang dipilih dalam aplikasi harus sesuai dengan koneksi ke proksi. |
| Alamat proksi | Alamat IP atau nama host proksi atau gateway yang diberikan. | Gunakan alamat proksi, bukan IP Anda sendiri atau alamat situs tujuan. |
| Port | Nomor port yang diberikan dalam detail koneksi. | Jangan menggantinya dengan nomor yang biasa Anda pakai: protokol atau mode akses berbeda dapat menggunakan port berbeda. |
| Nama pengguna | Nama pengguna untuk layanan ini. | Pertahankan huruf besar dan kecil, pemisah, serta parameter tambahan dalam string yang diberikan. |
| Kata sandi | Kata sandi akses proksi. | Salin secara lengkap tanpa menambahkan spasi, pergantian baris, atau tanda kutip. |
Beberapa aplikasi menerima satu string berformat protocol://username:password@host:port. Contohnya, dalam http://client01:River%[email protected]:8080, nama penggunanya adalah client01, kata sandinya River@2026, host-nya proxy.example, dan port-nya 8080. Karakter @ dalam kata sandi ditulis sebagai %40 agar tidak tertukar dengan pemisah sebelum host.
Contohnya, curl mendukung penafsiran URL proksi seperti ini. Kolom kata sandi terpisah umumnya mengharapkan kata sandi itu sendiri, tanpa pengodean URL. Jangan menyalin nilai terkode dari URL ke kolom terpisah tanpa memeriksa formatnya: aplikasi mungkin menganggapnya sebagai kata sandi berbeda. Untuk string yang berisi %, titik dua, atau karakter khusus lain, ikuti persyaratan format klien tersebut.
Kodekan karakter yang diperlukan dalam kredensial satu kali; mengodekan seluruh string akan merusak pemisahnya. Memberi tanda kutip pada argumen perintah tidak menggantikan pengodean URL. Metode autentikasi juga dapat memiliki pembatasannya sendiri: HTTP Basic, misalnya, mengizinkan titik dua dalam kata sandi tetapi tidak dalam nama pengguna.
Format impor juga berbeda. host:port:username:password dan username:password@host:port tidak dapat saling menggantikan. Nilai yang benar dengan urutan salah tidak akan berfungsi jika alat impor mengharapkan susunan lain.
Awalan http:// dalam URL proksi menjelaskan cara klien terhubung ke proksi itu sendiri. Awalan itu tidak menghalangi akses ke situs HTTPS: klien dapat membentuk terowongan untuknya. Sekadar mengganti awalan menjadi https:// tidak menambahkan dukungan koneksi proksi aman pada server.
Beberapa layanan menyertakan negara, kelompok IP keluar, atau parameter sesi dalam nama pengguna. Salin seluruh string. Parameter ini mengendalikan perutean sesuai aturan penyedia; jangan mengarang sintaksnya atau meminjamnya dari layanan lain.
Mengapa dukungan autentikasi aplikasi perlu diperiksa
Dukungan proksi dan dukungan autentikasi proksi merupakan kemampuan terpisah. Adanya kolom host dan port tidak selalu berarti klien dapat mengirimkan nama pengguna dan kata sandi.
Periksa kombinasi tepat antara protokol proksi, metode autentikasi, dan aplikasi. Contohnya, implementasi SOCKS5 bawaan Chrome tidak mendukung autentikasi proksi SOCKS5. Kredensial yang benar saja tidak dapat memperbaiki keterbatasan itu. Ekstensi pemilihan proksi juga belum tentu menambahkan metode autentikasi yang belum tersedia.
Dalam skrip, dukungan dapat bergantung pada pustaka, komponen opsionalnya, dan cara pengaturan diberikan. Aplikasi belum tentu menggunakan pengaturan proksi sistem atau pengaturan browser yang koneksinya sudah berfungsi.
Sebelum memulai tugas besar, uji satu permintaan pada aplikasi yang akan menjalankannya. Pastikan aplikasi menggunakan proksi yang ditentukan dan tidak melanjutkan dengan koneksi langsung setelah kegagalan. Halaman yang berhasil dimuat tidak dengan sendirinya memastikan pengaturan sudah benar.
Apa yang terjadi saat IP Anda berubah
Pada koneksi ADSL dengan IP dinamis, penyedia internet mungkin memberikan alamat baru setelah router dimulai ulang atau koneksi disambungkan kembali. Jika proksi hanya memeriksa nama pengguna dan kata sandi, aplikasi terhubung dengan kredensial yang sama: tidak ada IP baru yang perlu ditambahkan ke dasbor. Hal yang sama berlaku saat berpindah dari kantor ke jaringan rumah.
Namun, pergantian jaringan dapat memutus koneksi yang sudah ada. Klien perlu terhubung kembali, dan permintaan yang belum selesai mungkin perlu dicoba ulang. Kesalahan sesaat setelah beralih dari Wi-Fi ke internet seluler tidak boleh otomatis dianggap sebagai masalah kata sandi.
Beberapa layanan memeriksa kredensial sekaligus alamat sumber. Kata sandi yang benar tidak mengesampingkan pembatasan jaringan tersebut: IP baru harus sesuai dengan alamat atau rentang yang diizinkan. Sebelum memindahkan skrip, pastikan apakah layanan menerima koneksi dari semua jaringan atau menerapkan pemeriksaan gabungan.
Apakah kata sandi terlindungi selama pengiriman?
Autentikasi menentukan siapa yang boleh mengakses. Enkripsi menentukan apakah orang di sepanjang jalur dapat membaca data yang dikirim. Adanya kata sandi tidak dengan sendirinya membuat koneksi terenkripsi.
HTTP Basic mengodekan nama pengguna dan kata sandi dalam Base64. Ini merupakan bentuk penyajian yang dapat dibalik, bukan enkripsi. Tanpa perlindungan pada koneksi ke proksi, orang yang mengamati jalur jaringan itu dapat memperoleh kredensial. Autentikasi standar SOCKS5 dengan nama pengguna dan kata sandi juga tidak mengenkripsi pengirimannya.
HTTPS pada situs tujuan melindungi koneksi antara aplikasi dan situs tersebut. Pada proksi HTTP, autentikasi selama pembentukan terowongan terjadi lebih awal; TLS situs web tidak melindungi kredensial proksi yang sudah dikirim. Demikian pula, permintaan HTTPS melalui SOCKS5 tidak mengenkripsi pemeriksaan kata sandi proksi yang berlangsung sebelumnya.
Untuk melindungi bagian jalur tersebut, diperlukan perlindungan antara aplikasi dan proksi, misalnya proksi HTTPS yang menggunakan TLS, jika layanan dan klien sama-sama mendukungnya. Aplikasi harus memvalidasi sertifikat proksi. Dalam beberapa penawaran, istilah “proksi HTTPS” hanya berarti situs HTTPS dapat diakses, jadi periksa tempat TLS benar-benar diterapkan.
Jika string koneksi lengkap dengan kata sandi valid terungkap, orang lain mungkin dapat menggunakan layanan sesuai aturannya, menghabiskan kuota atau memakai jatah koneksi. Hal ini tidak sama dengan memperoleh kata sandi dasbor jika kredensialnya terpisah. Metode autentikasi juga tidak menjamin suatu alamat tidak dapat dikenali sebagai proksi: tantangan autentikasi yang dapat diakses dari luar dapat mengungkap layanan tersebut.
Dapatkah beberapa aplikasi menggunakan kredensial yang sama?
Secara teknis, beberapa klien dapat mengirimkan nama pengguna dan kata sandi yang sama. Penyedia menentukan apakah hal itu diperbolehkan dan menetapkan batasnya: ketentuan berbagi, batas koneksi aktif, kuota yang dibeli, serta pembatasan tambahan.
Contohnya, dua skrip dapat menggunakan satu akun sambil membuka jumlah koneksi berbeda. Satu kata sandi tidak berarti satu koneksi. Demikian pula, menjalankan sepuluh proses tidak melipatgandakan total jatah koneksi layanan menjadi sepuluh kali.
Jumlah pasangan kredensial juga berbeda dari jumlah IP keluar. Satu nama pengguna dan kata sandi dapat memberikan akses ke daftar proksi statis atau gateway yang didukung kumpulan alamat. IP yang dilihat situs web bergantung pada proksi yang dipilih dan aturan perutean layanan.
Jika layanan menawarkan kredensial terpisah untuk aplikasi atau anggota tim, satu pasangan dapat dinonaktifkan tanpa mengubah yang lain. Jika kata sandi dipakai bersama, menggantinya mengharuskan pembaruan setiap aplikasi yang menggunakannya. Kredensial terpisah tetap tidak berarti jatah koneksi atau lalu lintas yang terpisah: periksa batas mana yang digunakan bersama.
Mengapa proksi menolak nama pengguna dan kata sandi
Pertama, kenali siapa yang mengirim kesalahan. HTTP 407 terkait autentikasi proksi; 401 dari situs tujuan terkait akses ke situs tersebut. Pesan 403 atau koneksi yang kehabisan waktu tidak dapat memastikan benar tidaknya kata sandi proksi tanpa bukti tambahan.
| Yang terjadi | Kemungkinan penyebab | Yang perlu diperiksa |
|---|---|---|
| Aplikasi berulang kali meminta kata sandi | Kredensial salah, kata sandi lama tersimpan, atau metode autentikasi tidak didukung. | Kredensial untuk layanan ini, metode yang dipilih, dan pengaturan tersimpan pada klien. Satu HTTP 407 awal dapat merupakan tantangan autentikasi normal; hasil percobaan berikutnya yang menentukan. |
| Kolom terpisah berfungsi, tetapi impor string gagal | Urutan kolom berbeda, karakter khusus, atau spasi tambahan. | Format impor yang diharapkan dan cara format itu menangani karakter dalam nama pengguna serta kata sandi. |
| Satu aplikasi berfungsi dan aplikasi lain tidak | Klien kedua tidak memiliki dukungan protokol atau autentikasi yang diperlukan, atau tidak menggunakan pengaturan yang diberikan. | Dukungan untuk kombinasi tepat tersebut dan metode koneksi yang sebenarnya. Bandingkan pengujian dalam kondisi jaringan yang setara. |
| Akses berhenti setelah dipindahkan ke server | IP sumber berubah, pembatasan IP masih berlaku, atau pengaturan belum dipindahkan. | Pembatasan akses gabungan, alamat sumber baru, dan konfigurasi proses yang berjalan. |
| Koneksi gagal atau langsung ditutup | Host atau port tidak tersedia, protokol salah, koneksi diblokir, atau layanan menolaknya. | Host, port, protokol yang diberikan, dan pesan klien persisnya. Koneksi yang ditutup saja tidak menunjukkan apakah tahap autentikasi sempat dicapai. |
| Akses sebelumnya berfungsi, tetapi kini semua klien gagal | Kata sandi berubah, akses dinonaktifkan, layanan kedaluwarsa, atau kuota habis. | Status layanan dan perubahan terbaru. Penyedia belum tentu melaporkan semua kondisi ini sebagai kesalahan kata sandi. |
| Satu permintaan berfungsi, tetapi kegagalan muncul saat beban meningkat | Batas koneksi atau permintaan, atau beban berlebihan pada klien maupun layanan. | Jumlah koneksi bersamaan, batas yang berlaku, dan respons persisnya. Kurangi beban dan bandingkan hasil sebelum mengubah kredensial. |
Periksa status layanan dan sisa kuota, lalu uji satu permintaan dengan pengaturan yang diberikan pada aplikasi sebenarnya. Jika gagal, gunakan tabel untuk memeriksa dukungan klien, format kredensial, dan pembatasan IP sumber, sambil mengubah satu pengaturan setiap kali. Setelah permintaan berhasil secara konsisten, tingkatkan beban kerja dan amati batas yang baru muncul saat beban meningkat.
Cara menyimpan dan mengganti kredensial dalam skrip yang digunakan
Pisahkan kredensial dari kode, dalam konfigurasi dengan kendali akses atau penyimpanan rahasia lingkungan Anda. Aplikasi dapat menerimanya melalui variabel lingkungan, tetapi variabel tersebut bukan enkripsi dengan sendirinya. Jangan menyertakan kata sandi aktif dalam repositori dan templat yang dibagikan kepada orang lain.
Log umumnya memerlukan host dan port proksi, hasil koneksi, serta kode kesalahan. String koneksi lengkap memuat kata sandi; samarkan sebelum menulisnya ke log. Untuk alat baris perintah, pertimbangkan bahwa rahasia dapat tertinggal dalam riwayat perintah atau terlihat pada argumen proses, bergantung pada aplikasi dan sistem.
Sebelum mengganti kata sandi, temukan setiap penggunanya: aplikasi lokal, proses server, tugas terjadwal, dan sistem build. Setelah penggantian, perbarui pengaturannya dan buat koneksi baru untuk mengujinya. Pastikan proses yang berjalan lama juga telah mengambil nilai baru; beberapa proses perlu dimulai ulang.
Jika kata sandi lama seharusnya tidak lagi berfungsi, uji bahwa koneksi baru yang menggunakannya ditolak. Koneksi yang sudah ada mengikuti aturan layanan: mengganti kata sandi tidak selalu langsung menutupnya. Untuk pencabutan mendesak, gunakan metode penonaktifan akses yang didukung penyedia.
Autentikasi gabungan: IP dan kata sandi
Dengan autentikasi gabungan, proksi memeriksa dua syarat: kredensial dan alamat asal koneksi aplikasi. Keduanya harus lolos. Kata sandi yang benar saja tidak mengesampingkan pembatasan IP.
Untuk paket statis ProxyCompass, mode gabungan menggunakan subnet /24. Jika Anda memiliki beberapa alamat IPv4 publik dalam subnet yang sama, menambahkan salah satunya ke daftar yang diizinkan sudah cukup. Alamat lain dalam subnet itu dapat terhubung dengan nama pengguna dan kata sandi yang benar, tanpa entri terpisah untuk setiap alamat.
Dalam ilustrasi, IP publik aplikasi memiliki tiga angka pertama yang sama dengan alamat yang diizinkan. IP tersebut dapat terhubung dengan kredensial valid; alamat di luar subnet gagal dalam pemeriksaan jaringan, dan kata sandi salah tetap gagal meskipun alamat berada di dalam subnet. IP klien lain dalam subnet yang sama juga dapat menggunakan entri ini. Hal ini berguna bagi aplikasi yang memerlukan kolom nama pengguna dan kata sandi. Aturan ini berlaku untuk IP publik aplikasi Anda, bukan IP keluar proksi yang dibeli.