በ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 መድረሻ ጋር የሚደረግ ክፍለ ግንኙነት ያን ቀደም ያለ የፕሮክሲ ልውውጥ አይጠብቅም። በደንበኛና በአገልጋይ መካከል በተገቢው የተጠበቀ መንገድ ይጠቀሙ።

የተሳካ የቅንብር ማረጋገጫ አገባብንና ማንነቶችን ያረጋግጣል እንጂ የመለያ ውሂብ ጎታውን ወይም የአውታረ መረብ መንገዱን አያረጋግጥም። እውነተኛው ፈተና በየትኛው ደረጃ እንደተከለከለ ለማየት የአገልጋዩን ምዝግብ ይመልከቱ።

ተዛማጅ ጽሑፎች