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 மட்டும் அனுமதிக்கும் விதி எஞ்சியுள்ளதா பாருங்கள். எதிர்பார்த்த listener மற்றும் firewall கட்டுப்பாடுகளையும் தக்கவைக்கவும்.

பேச்சுவார்த்தையையும் அணுகலையும் தனித்தனியாகச் சோதிக்கவும்

தொடங்குவதற்கு முன் நிறுவப்பட்ட சேவையகத்தின் உள்ளமைவுச் சோதனை முறையில் கோப்பைச் சரிபார்க்கவும். பின்னர் SOCKS5 பயனர்பெயர்/கடவுச்சொல் பேச்சுவார்த்தையை உண்மையில் ஆதரிக்கும் அனுமதிக்கப்பட்ட கிளையன்டைப் பயன்படுத்தவும். சான்றுகள் இல்லாமை, தவறான சான்றுகள் மற்றும் அனுமதிக்கப்பட்ட கணக்கு தடைசெய்யப்பட்ட இலக்கைக் கோருதல் ஆகியவற்றைச் சோதிக்கவும்.

RFC 1929 வரையறுக்கும் பயனர்பெயர்/கடவுச்சொல் துணைப் பேச்சுவார்த்தை கடவுச்சொல்லை மறையாக்காது. இலக்குடன் பின்னர் ஏற்படும் HTTPS அமர்வு முந்தைய அந்தப் proxy பரிமாற்றத்தைப் பாதுகாக்காது. கிளையன்டிலிருந்து சேவையகம் வரை உரிய பாதுகாப்புள்ள பாதையைப் பயன்படுத்தவும்.

வெற்றிகரமான உள்ளமைவுச் சோதனை தொடரமைப்பையும் அடையாளங்களையும் உறுதிசெய்கிறது; கணக்குத் தரவுத்தளத்தையோ வலைப்பின்னல் பாதையையோ அல்ல. உண்மையான சோதனை எந்தக் கட்டத்தில் மறுக்கப்பட்டது என்று சேவையகப் பதிவுகளில் பாருங்கள்.

தொடர்புடைய கட்டுரைகள்