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-ന് ശേഷമുള്ള നിയമങ്ങളും പ്രാമാണീകരണ കാഷും പരിശോധിക്കുക. പാസ്വേഡ് മാറ്റുന്നത് തെറ്റായ നയത്തിന് കീഴിൽ ആരംഭിച്ച സേവനം നന്നാക്കാൻ കഴിയില്ല. അതുപോലെ, ഡീമണിന്റെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം അക്കൗണ്ട് മാറ്റുന്നത് പ്രോക്സി ഉപയോക്താവിനെ സൃഷ്ടിക്കുന്നില്ല.