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 സെഷൻ നേരത്തെയുള്ള പ്രോക്സി കൈമാറ്റത്തെ സംരക്ഷിക്കുന്നില്ല. ക്ലയന്റിൽനിന്ന് സർവറിലേക്കുള്ള യോജിച്ച സംരക്ഷിത പാത ഉപയോഗിക്കുക.

വിജയകരമായ കോൺഫിഗറേഷൻ പരിശോധന സിന്റാക്സും ഐഡന്റിറ്റികളും ഉറപ്പാക്കുന്നു, അക്കൗണ്ട് ഡാറ്റാബേസോ നെറ്റ്‌വർക്ക് പാതയോ അല്ല. യഥാർഥ പരീക്ഷണം ഏത് ഘട്ടത്തിലാണ് നിരസിച്ചതെന്ന് സർവർ ലോഗുകളിൽ നോക്കുക.