በGnuTLS ወይም OpenSSL የተገነባ Squid 6.13 የወደፊት ፕሮክሲ ጥያቄዎችን በTLS ሊቀበል ይችላል። ይህ የHTTPS መድረሻውን የተለየ ክፍለ ጊዜ ሳይጠልፍ የደንበኛ–ፕሮክሲ ግንኙነትን ይጠብቃል።

  1. ደንበኞች Squidን ለማግኘት ለሚጠቀሙበት የአስተናጋጅ ስም ሰርተፊኬት ያግኙ። የግል ቁልፉን ለሚፈልጉት የአገልግሎት ማንነቶች ብቻ ይገድቡ።
  2. በተመደበልዎ አድራሻና በእውነተኛ የሰርተፊኬት መንገዶች TLS አዳማጭ ያክሉ፦
https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

የደንበኛ ፈቃድ ዝርዝሩንና የመድረሻ ገደቦችን እንዲሁም የማንነት ማረጋገጫ ፖሊሲውን ያቆዩ። አዳማጩ መዳረሻ አይሰጥም። ያለው http_port እንዲሠራም ይተዋል፤ ሁሉም የደንበኛ ግንኙነቶች TLS መጠቀም ካለባቸው የቀድሞውን አዳማጭ ያስወግዱ ወይም ይገድቡ። የማፋጠኛ፣ የጠለፋ ወይም የሰርተፊኬት ማመንጫ ሁነታ አያስፈልግም።

የታሰበውን አገልግሎት እንደገና ከመጫን በፊት ቅንብሩን ያስተንትኑ። የተንታኝ ፍተሻው መዋቅርና የሰርተፊኬት ጭነት ያረጋግጣል እንጂ የአውታረ መረብ ተደራሽነት አይደለም። የተሳካ ድጋሚ ጭነት በኋላ ከተፈቀደ ደንበኛ በTLS መገናኛ ነጥቡ በኩል ጥያቄ ይላኩ፦

curl --proxy https://proxy.example:3129 --proxy-cacert approved-proxy-ca.pem --connect-timeout 5 --max-time 15 https://example.com/

ትክክለኛውን የፕሮክሲ አስተናጋጅ ስምና የተፈቀደ CA ፋይል ይጠቀሙ። በይፋ የሚታመን የፕሮክሲ ሰርተፊኬት ብጁ ጥቅል ላይፈልግ ይችላል። --proxy-cacert የፕሮክሲ እምነትን ያዋቅራል፣ የመድረሻ ማረጋገጫንም ለይቶ ይተዋል፤ ሁለቱንም ፍተሻዎች ያቆዩ።

እውነተኛውን አዳማጭና የሰርተፊኬት ስም ይፈትሹ፣ ከዚያም መከልከል ያለበትን ቁጥጥርዎ ሥር ያለ ምንጭ ይሞክሩ። የተሳካ ትንተና ብቻ የደንበኛ እምነትን ወይም የመዳረሻ ወሰንን አያረጋግጥም።

ተዛማጅ ጽሑፎች