Danteમાં વપરાશકર્તાનામથી પ્રમાણીકરણ ઉમેરો

Dante 1.4.4માં ક્લાયન્ટના નિયમો SOCKS વાટાઘાટ પહેલાં જોડાણ સ્વીકારે છે, જ્યારે SOCKS નિયમો નક્કી કરે છે કે કઈ પ્રમાણિત વિનંતીઓ આગળ વધી શકે. માન્ય સ્રોતના જોડાણને પણ બીજા તબક્કે વપરાશકર્તાનામની જરૂર પડી શકે છે.

ઓપરેટિંગ સિસ્ટમના વપરાશકર્તાનામથી પ્રમાણીકરણ માટે પદ્ધતિ સાથે સેવાની ઓળખો પણ તપાસો. ખાતાના ડેટાબેઝને વાંચવા વિશેષાધિકારવાળી ઓળખની જરૂર પડી શકે છે:

clientmethod: none
socksmethod: username
user.privileged: root
user.unprivileged: danteproxy

Dante માટે સ્થાપિત વાસ્તવિક ઓછા અધિકારવાળું સેવા ખાતું વાપરો. વપરાશકર્તાનામના બેકએન્ડ સાથે સુસંગત અધિકૃત ક્લાયન્ટ ખાતું બનાવો અથવા પસંદ કરો; સેવાની ઓળખ અને ક્લાયન્ટનું લૉગિન જુદી ભૂમિકાઓ છે.

વિનંતીની સીમાઓ જાળવો

હાલના મર્યાદિત ક્લાયન્ટ નિયમ પછી માન્ય SOCKS માર્ગ પર ખાતું ફરજિયાત કરો:

socks pass {
    from: 198.51.100.27/32 to: 203.0.113.20/32 port = 443
    command: connect
    socksmethod: username
    user: proxyuser
    log: connect error
}

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

વૈશ્વિક અને નિયમ માટેની પદ્ધતિ સેટિંગ એકબીજા સાથે મેળ ખાતી હોવી જોઈએ. માત્ર સ્રોત આધારિત ગોઠવણીમાંથી માત્ર none માન્ય રાખતો જૂનો નિયમ રહી ગયો છે કે નહીં તે તપાસો. ઇચ્છિત લિસનર અને ફાયરવૉલના નિયંત્રણો પણ જાળવો.

વાટાઘાટ અને પ્રવેશ અલગથી ચકાસો

ચાલુ કરતાં પહેલાં સ્થાપિત સર્વરના કન્ફિગરેશન તપાસ મોડથી ફાઇલ ચકાસો. પછી ખરેખર SOCKS5 વપરાશકર્તાનામ/પાસવર્ડ વાટાઘાટને ટેકો આપતો અધિકૃત ક્લાયન્ટ વાપરો. ઓળખ વિગતો ન હોવી, ખોટી વિગતો હોવી અને માન્ય ખાતું પ્રતિબંધિત ગંતવ્ય માગે તે પરિસ્થિતિઓ તપાસો.

RFC 1929માં નિર્ધારિત વપરાશકર્તાનામ/પાસવર્ડની ઉપવાટાઘાટ પાસવર્ડ એન્ક્રિપ્ટ કરતી નથી. ગંતવ્ય સાથેનું પછીનું HTTPS સત્ર અગાઉના પ્રોક્સી વિનિમયને સુરક્ષિત કરતું નથી. ક્લાયન્ટથી સર્વર સુધી યોગ્ય રીતે સુરક્ષિત માર્ગ વાપરો.

સફળ કન્ફિગરેશન તપાસ વાક્યરચના અને ઓળખોની ખાતરી કરે છે, ખાતાના ડેટાબેઝ કે નેટવર્ક માર્ગની નહીં. વાસ્તવિક કસોટી કયા તબક્કે નકારાઈ તે જાણવા સર્વરના લૉગ જુઓ.