3proxy ની HTTP અને SOCKS બંને સેવાઓ પર લોગિન જરૂરી બનાવો

વપરાશકર્તા વ્યાખ્યાયિત કરવો એ 3proxy નું આખું લોગિન રૂપરેખાંકન નથી. સેવાને પ્રમાણીકરણ પદ્ધતિ અને તેનો ઉપયોગ કરતો પ્રવેશ નિયમ પણ જોઈએ. ક્રમ મહત્વપૂર્ણ છે કારણ કે રૂપરેખાંકન પ્રક્રિયા દરમિયાન સેવા સેટિંગ્સ લાગુ થાય છે.

બે સેવાઓ માટે ફક્ત સ્થાનિક ઉદાહરણ:

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

રૂપરેખાંકન સંદર્ભ users, auth strong અને સેવા આદેશો સમજાવે છે. CL આ ઉદાહરણનો પાસવર્ડ સાદા લખાણ તરીકે સંગ્રહે છે. ફાઈલને સુરક્ષિત કરો અને ડિપ્લોયમેન્ટ માટે યોગ્ય, સમર્થિત ઓળખપત્ર સંગ્રહ સ્વરૂપ પસંદ કરો.

ક્લાયન્ટને યોગ્ય લોગિન વિનિમયની જરૂર છે

HTTP સેવા HTTP પ્રોક્સી પ્રમાણીકરણની અપેક્ષા રાખે છે. SOCKS સેવાને SOCKS5 વપરાશકર્તાનામ અને પાસવર્ડ પ્રમાણીકરણ સમર્થિત કરતો ક્લાયન્ટ જોઈએ. SOCKS4 ક્લાયન્ટ ફક્ત એટલા માટે કે તે એ જ સાંભળવાના પોર્ટ પર પહોંચે છે તે વિનિમય આપી શકતો નથી.

strong શબ્દ એ પ્રમાણીકરણ મોડનું નામ છે, એન્ક્રિપ્ટેડ પરિવહનની બાંયધરી નથી. જરૂર હોય ત્યારે ક્લાયન્ટથી પ્રોક્સી સુધીનો ભાગ સુરક્ષિત કરો. ગંતવ્ય સુધી HTTPS અને પ્રોક્સી સુધી એન્ક્રિપ્શન અલગ નિર્ણયો જ રહે છે.

લૂપબેક બાઈન્ડિંગ આ ઉદાહરણને સ્થાનિક પ્રવેશ સુધી મર્યાદિત કરે છે. દૂરસ્થ ક્લાયન્ટ માટે ઈચ્છિત શ્રોતા અને નેટવર્ક નીતિ સ્પષ્ટપણે પસંદ કરો. જાહેર વાઈલ્ડકાર્ડ શ્રોતા લોગિન વર્તન તપાસવાનો વિકલ્પ નથી.

જો એક સેવા ઓળખપત્ર માંગે અને બીજી ન માંગે, તો દરેક સેવા આદેશ પહેલાંની સેટિંગ્સ, કોઈપણ flush પછીના નિયમો અને પ્રમાણીકરણ કેશ તપાસો. પાસવર્ડ બદલવાથી ખોટી નીતિ હેઠળ શરૂ થયેલી સેવા સુધરતી નથી. એ જ રીતે ડેમનનું ઓપરેટિંગ સિસ્ટમ ખાતું બદલવાથી પ્રોક્સી વપરાશકર્તા બનતો નથી.