3proxy ning HTTP va SOCKS xizmatlarining ikkalasida ham kirishni talab qiling

Foydalanuvchini belgilash 3proxy kirish konfiguratsiyasining barchasi emas. Xizmatga autentifikatsiya usuli va uni ishlatadigan kirish qoidasi ham kerak. Tartib muhim, chunki konfiguratsiya qayta ishlanayotganda xizmat sozlamalari qo'llaniladi.

Ikki xizmat uchun faqat mahalliy kirish misoli:

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

Konfiguratsiya qo'llanmasi users, auth strong va xizmat buyruqlarini tushuntiradi. CL bu misol parolini ochiq matn sifatida saqlaydi. Faylni himoya qiling va joylashtirishga mos keladigan qo'llab-quvvatlanadigan hisob ma'lumotlarini saqlash shaklini tanlang.

Mijozga to'g'ri kirish almashinuvi kerak

HTTP xizmati HTTP proksi autentifikatsiyasini kutadi. SOCKS xizmatiga SOCKS5 foydalanuvchi nomi va parol autentifikatsiyasini qo'llab-quvvatlaydigan mijoz kerak. SOCKS4 mijozi faqat bir xil tinglash portiga yetib kelgani uchun bu almashinuvni bera olmaydi.

strong so'zi autentifikatsiya rejimining nomi, shifrlangan uzatish kafolati emas. Kerak bo'lsa mijozdan proksigacha bo'lgan qismni himoya qiling. Manzilga HTTPS va proksiga shifrlash alohida qarorlar bo'lib qoladi.

Loopback ulanishlari bu misolni mahalliy kirish bilan cheklaydi. Uzoq mijozlar uchun mo'ljallangan tinglovchi va tarmoq siyosatini aniq tanlang. Ommaviy joker belgili tinglovchi kirish xatti-harakatini tekshirishning o'rnini bosmaydi.

Agar bir xizmat hisob ma'lumotlarini so'rasa, boshqasi so'ramasa, har bir xizmat buyrug'idan oldingi sozlamalarni, har qanday flush dan keyingi qoidalarni va autentifikatsiya keshini tekshiring. Parolni o'zgartirish noto'g'ri siyosat ostida boshlangan xizmatni tuzata olmaydi. Xuddi shunday, demonning operatsion tizim hisobini o'zgartirish proksi foydalanuvchisini yaratmaydi.