Basis Pengetahuan ProxyCompass

Autentikasi Proksi: Daftar IP yang Diizinkan atau Nama Pengguna dan Kata Sandi?

Autentikasi proksi memeriksa apakah aplikasi Anda boleh menggunakan layanan proksi. Mengetahui alamat dan port proksi biasanya belum cukup: layanan juga perlu membedakan klien yang diizinkan dari sistem lain yang dapat menjangkaunya. Dengan demikian, penggunaan proksi yang dibeli dibatasi pada klien yang Anda izinkan.

Dua metode yang umum digunakan mengandalkan bukti berbeda. Pada autentikasi berdasarkan IP, proksi memeriksa asal koneksi. Pada autentikasi dengan nama pengguna dan kata sandi, aplikasi mengirimkan kredensial. Metode pertama mengikat akses pada alamat jaringan; metode kedua dapat mempertahankan akses aplikasi saat berpindah jaringan. Layanan juga dapat mewajibkan kedua syarat sekaligus.

Pilihan ini memengaruhi cara Anda terhubung, aplikasi yang dapat digunakan, dan apa yang terjadi saat lingkungan kerja berubah. Ini merupakan bagian tersendiri dari pemilihan konfigurasi proksi: autentikasi tidak menentukan apakah IP keluar berasal dari pusat data atau jaringan residensial, maupun apakah IP tersebut statis atau berotasi. Autentikasi menentukan siapa yang boleh menggunakan layanan yang menyediakan IP tersebut.

Cara kerja kedua metode autentikasi

Autentikasi berdasarkan IP: izin untuk sumber koneksi

Pada autentikasi berdasarkan IP, Anda menambahkan alamat klien ke daftar yang diizinkan oleh penyedia, yang sering disebut whitelist atau allowlist. Saat koneksi masuk, proksi membandingkan IP sumbernya dengan daftar tersebut. Jika cocok dan syarat akses lain dari layanan terpenuhi, aplikasi dapat menggunakan proksi tanpa mengirimkan nama pengguna dan kata sandi proksi secara terpisah.

Untuk proksi di internet, alamat yang dimaksud biasanya adalah IP publik keluar jaringan Anda. Inilah alamat yang digunakan aplikasi untuk menjangkau proksi, bukan IP keluar yang kemudian ditampilkan proksi kepada situs web. Membeli proksi statis tidak membuat koneksi rumah Anda menjadi statis: alamat-alamat tersebut berada pada bagian rute yang berbeda.

Karena itu, akses tetap praktis selama sumber yang diizinkan tidak berubah. Program dapat dimulai ulang atau perangkat lain yang diizinkan dapat terhubung melalui jaringan tersebut tanpa memerlukan kata sandi proksinya sendiri. Jika IP keluar berubah, izin lama tidak otomatis berlaku untuk alamat baru. Panduan autentikasi berdasarkan IP menjelaskan cara mengenali alamat sumber yang benar dan mengelola daftar yang diizinkan.

Nama pengguna dan kata sandi: izin yang dikirimkan aplikasi

Pada autentikasi dengan nama pengguna dan kata sandi, penyedia memberikan kredensial untuk menggunakan proksi. Aplikasi mengirimkannya sebagai bagian dari protokol proksi yang didukung. Browser mungkin meminta pengguna memasukkannya; skrip dapat mengambilnya dari konfigurasi tanpa menampilkan jendela login.

Jika kredensial merupakan satu-satunya syarat autentikasi, akses dapat mengikuti aplikasi saat berpindah jaringan. Konfigurasi yang sama dapat tetap terhubung dari IP sumber baru. Ini berguna saat lokasi pelaksanaan tugas lebih sering berubah daripada pengaturan proksinya.

Kredensial tersebut digunakan untuk koneksi ke proksi. Kredensial itu tidak otomatis sama dengan kata sandi dasbor penyedia dan tidak membuat Anda login ke situs web tujuan. Situs tersebut tetap menerapkan aturan login dan aksesnya sendiri. Panduan autentikasi dengan nama pengguna dan kata sandi membahas kolom koneksi, klien yang didukung, dan format kredensial.

Autentikasi berdasarkan IP dibandingkan nama pengguna dan kata sandi

Perbandingan di bawah membahas kedua metode secara terpisah. Akses dengan kata sandi di sini berarti akses tanpa pembatasan IP tambahan; akses gabungan dijelaskan lebih lanjut di bawah.

Kedua metode tidak menentukan jumlah IP keluar dalam layanan. Satu IP klien yang diizinkan atau satu pasangan kredensial dapat memberikan akses ke banyak proksi. Keduanya juga tidak memberi proksi tersebut koneksi tanpa batas atau menjadikan alamat keluarnya eksklusif untuk satu pelanggan.

Cara memilih berdasarkan aplikasi dan jaringan

Pertama, periksa apakah aplikasi dapat menggunakan metode yang ditawarkan

Program dapat mendukung suatu protokol proksi tanpa mendukung semua pilihan autentikasinya. Kolom alamat dan port saja tidak membuktikan bahwa program dapat mengirimkan nama pengguna dan kata sandi. Contohnya, dukungan SOCKS5 bawaan Chrome tidak mencakup autentikasi SOCKS5 dengan nama pengguna dan kata sandi. Kredensial yang benar tidak dapat mengatasi ketiadaan kemampuan tersebut pada klien.

Jika aplikasi yang diperlukan mendukung protokol yang ditawarkan tetapi tidak dapat mengirimkan kredensialnya, autentikasi berdasarkan IP dapat menjadi jalur akses yang dapat digunakan. Alamat sumber tetap harus diizinkan. Jika alamat itu sering berubah, beralih ke akses berdasarkan IP menyelesaikan masalah kredensial, tetapi pengelolaan alamat sumber tetap diperlukan. Sebagai alternatif, Anda mungkin memerlukan klien yang mendukung autentikasi tersebut atau jalur keluar jaringan yang stabil.

Karena itu, pemeriksaan sebelum membeli harus spesifik: dapatkah aplikasi ini menggunakan protokol proksi ini dengan metode autentikasi ini? Keberhasilan pada browser atau alat baris perintah lain belum menjawab pertanyaan tersebut.

Selanjutnya, pertimbangkan apa yang biasanya berubah dalam konfigurasi Anda

Autentikasi berdasarkan IP cocok untuk tugas yang jalur keluar jaringannya stabil dan terkendali. Setelah jalur keluar itu diizinkan, mengganti program di belakangnya tidak mengharuskan Anda membagikan kredensial proksi kepada setiap proses baru. Pengaturan akses layanan tetap melekat pada jaringan yang digunakan tugas.

Kredensial cocok untuk tugas yang lokasi pelaksanaannya berubah. Jika tugas dipindahkan ke server lain atau proses pekerja baru berjalan dari jaringan berbeda, akses tidak memerlukan perubahan daftar izin terpisah untuk setiap sumber, asalkan layanan menerima kredensial tanpa pengikatan IP. Konfigurasi proksi dapat berpindah bersama aplikasi.

Perbedaan yang perlu diperhatikan adalah seberapa sering alamat sumber keluar berubah, bukan apakah mesin disebut laptop, VPS, atau server cloud. Laptop dapat tetap berada di balik jalur keluar kantor yang tetap; penerapan server dapat berganti-ganti alamat publik. Pilih berdasarkan jalur koneksi sebenarnya dan perubahan yang Anda perkirakan selama pekerjaan normal.

Jika kedua metode dapat digunakan, pilih pengaturan yang lebih mudah dikelola

Pertimbangkan siapa yang akan mengelola pengaturan. Administrator jaringan yang mengendalikan jalur keluar tetap untuk beberapa aplikasi dapat mengatur akses melalui satu izin sumber. Pengembang yang memindahkan tugas antarlingkungan tetapi tidak dapat mengendalikan IP publiknya mungkin lebih mudah mengelola kredensial tanpa pengikatan IP.

Perhitungkan sumber daya tambahan yang diperlukan oleh pilihan tersebut. IP publik tetap, entri tambahan pada daftar izin, atau gateway terkelola mungkin menimbulkan biaya. Akses dengan kata sandi mungkin menghindari biaya itu, tetapi hanya jika dapat digunakan dari jaringan yang diperlukan. Bandingkan pilihan layanan yang sebenarnya; adanya kata sandi saja tidak membuat proksi lebih murah.

Autentikasi gabungan: IP dan kata sandi

Penyedia dapat menawarkan akses berdasarkan IP dan akses dengan kata sandi sebagai alternatif, atau mewajibkan keduanya sekaligus. Ini adalah pengaturan yang berbeda. Dalam mode gabungan, kredensial valid hanya diterima jika koneksi juga berasal dari alamat atau jaringan yang diizinkan. Kata sandi yang benar saja tidak cukup, dan sumber yang diizinkan saja juga tidak cukup.

Mode ini dapat cocok untuk aplikasi yang memerlukan kolom nama pengguna dan kata sandi sekaligus mempertahankan pembatasan asal akses. Mode ini juga dapat membatasi penggunaan kredensial yang disalin di luar jaringan yang diizinkan. Kebebasan berpindah antarjaringan tidak sama dengan akses menggunakan kata sandi tanpa pengikatan IP.

Pada paket statis ProxyCompass, mode gabungan menerima kredensial valid dari alamat IPv4 publik klien yang berada dalam subnet /24 yang sama dengan IP yang ditambahkan ke whitelist. Alamat-alamat tersebut memiliki tiga angka pertama yang sama. Karena itu, beberapa alamat klien dalam subnet tersebut dapat menggunakan kredensial melalui satu entri whitelist. Aturan ini berlaku untuk klien yang terhubung ke layanan, bukan untuk IP keluar yang dibeli. Panduan nama pengguna dan kata sandi yang ditautkan di atas menampilkan contoh koneksinya.

Metode mana yang memberi kendali akses lebih baik?

Autentikasi berdasarkan IP menempatkan keputusan akses pada jalur keluar jaringan. Orang yang hanya memperoleh alamat proksi tidak dapat menggunakannya dari sumber lain yang tidak disetujui. Namun, proksi tidak dapat mengenali orang secara individual hanya karena mereka berbagi IP yang diizinkan. Jika beberapa pengguna menjangkaunya melalui alamat publik yang sama, pemeriksaan IP melihat sumber yang sama untuk semuanya. Hal ini relevan pada jalur keluar kantor bersama dan alamat publik yang dipakai bersama oleh pelanggan internet.

Autentikasi dengan nama pengguna dan kata sandi menempatkan izin dalam kredensial yang dapat dikirim aplikasi tanpa bergantung pada lokasinya. Ini cocok untuk jaringan yang tidak saling terkait. Namun, konfigurasi yang disalin dan memuat kredensial valid mungkin tetap dapat digunakan di tempat lain. Jika penyedia menawarkan kredensial terpisah untuk pengguna atau tugas berbeda, kredensial tersebut dapat memberi pengelolaan akses yang lebih terperinci; satu kata sandi yang dipakai semua orang tidak menciptakan pemisahan tersebut.

Karena itu, pilihan bergantung pada hal yang lebih dapat Anda kendalikan: kelompok sistem di balik jalur keluar jaringan yang diizinkan atau kredensial yang diberikan kepada aplikasi. Akses gabungan mewajibkan kedua syarat, sehingga membatasi lokasi penggunaan bahkan untuk kredensial yang valid.

Kendali akses dan enkripsi merupakan dua hal terpisah. Autentikasi berdasarkan IP tidak mengenkripsi lalu lintas, dan kata sandi tidak otomatis menciptakan koneksi terenkripsi. Perlindungan kredensial selama pengiriman memerlukan perlindungan pada koneksi klien ke proksi itu sendiri. Membuka situs HTTPS melalui proksi tidak dengan sendirinya melindungi pertukaran login sebelumnya ke proksi tersebut jika pertukaran itu tidak terenkripsi.

Apakah autentikasi berdasarkan IP membuat proksi lebih cepat?

Akses berdasarkan IP dapat menghindari pertukaran kredensial, tetapi penyiapan koneksi berbeda antara HTTP dan SOCKS. Pada SOCKS5, autentikasi dengan nama pengguna dan kata sandi menambahkan permintaan dan respons saat penyiapan. Pada HTTP, klien dapat menunggu tantangan autentikasi lalu mengulangi permintaannya, atau mengirimkan kredensial yang sesuai sejak awal. Karena itu, akses dengan kata sandi tidak selalu menambahkan satu perjalanan bolak-balik jaringan.

Perbedaan ini paling terasa ketika tugas berulang kali membuat koneksi baru untuk sedikit pekerjaan. Dampaknya lebih kecil jika koneksi yang sudah terbentuk digunakan kembali. Contohnya, meminta halaman tambahan dari situs yang sama melalui terowongan HTTPS yang sudah ada tidak mengulangi login proksi yang digunakan saat membuat terowongan tersebut. Ini adalah biaya waktu penyiapan koneksi, bukan penurunan tetap pada kecepatan transfer data proksi.

Jika kedua metode sesuai dengan konfigurasi Anda, bandingkan dengan protokol yang sama, sumber daya proksi yang serupa, dan pola koneksi yang benar-benar digunakan. Pengujian yang membuka koneksi baru untuk setiap permintaan menjawab pertanyaan yang berbeda dari pengujian yang menggunakan kembali koneksi. Tanpa perbandingan seperti itu, klaim bahwa satu metode autentikasi selalu lebih cepat tidak banyak membantu dalam memilih layanan.

Dapatkah autentikasi mengungkap bahwa suatu alamat menjalankan proksi?

Ya. Kata sandi dapat mencegah penggunaan tanpa izin sekaligus tetap memungkinkan sistem luar mengenali layanan tersebut. Contohnya, alat pemeriksa dapat menghubungi alamat dan port proksi HTTP tanpa kredensial valid. Respons 407 Proxy Authentication Required, dengan header Proxy-Authenticate, secara jelas menunjukkan bahwa autentikasi proksi diperlukan. Alat pemeriksa tidak perlu mengetahui kata sandi untuk menerima bukti tersebut.

Layanan yang membatasi IP dapat mengungkap lebih sedikit informasi jika memblokir sumber yang tidak disetujui sebelum mengembalikan respons proksi yang dapat dikenali. Namun, daftar yang diizinkan saja tidak menjamin perilaku tersebut: server mungkin mengembalikan penolakan yang khas. Titik koneksi yang dilindungi kata sandi juga dapat menerapkan penyaringan jaringan. Perbedaan yang relevan adalah apa yang dapat dijangkau koneksi luar dan respons apa yang diterimanya.

Alamat yang diperiksa juga penting. Jika alamat masuk proksi dan IP keluarnya sama, respons yang dapat dikenali dapat mengidentifikasi alamat yang dilihat situs web. Jika gateway menggunakan IP keluar yang berbeda, mengenali gateway saja tidak otomatis mengenali setiap IP keluar dalam kumpulannya.

Situs web tujuan tidak otomatis menerima tantangan login proksi selama penjelajahan biasa: pertukaran tersebut berlangsung antara klien dan proksi. Situs atau layanan pendeteksiannya memerlukan bukti lain, yang mungkin mencakup pemeriksaan alamat secara terpisah. Karena itu, mengganti metode autentikasi saja tidak dapat menjamin IP tidak dikenali sebagai proksi atau menghapus informasi yang sudah diketahui tentangnya.