የApache ፕሮክሲዎ በወደብ 3128 ላይ ያዳምጣል። አንድ ደንበኛ በተሳካ ሁኔታ ይደርሳል፣ ነገር ግን በወደብ 8443 ላይ ያለው የHTTPS አገልግሎት አይሳካም። የፕሮክሲውን የማዳመጫ ወደብ መቀየር ያንን ልዩነት ሊመልስ አይችልም።

ደንበኛው መጀመሪያ ከፕሮክሲው አድማጭ ጋር ይገናኛል። ከዚያም CONNECT ጥያቄው የተለየ የመድረሻ አስተናጋጅ እና ወደብ ይጠቅሳል። Apache የመጀመሪያውን ግንኙነት ተቀብሎ ሁለተኛውን ሥራ ሊከልክል ይችላል።

AllowCONNECTን እንደ መድረሻ መመሪያ አንብብ

ለApache 2.4 mod_proxy_connect የሚመጡ CONNECT ጥያቄዎችን ያስተዳድራል። የAllowCONNECT መመሪያው ለእነዚያ ጥያቄዎች የሚገኙትን የመድረሻ ወደቦች ይቆጣጠራል። በሰነዱ የተጠቀሰው ነባሪ 443 እና 563 ነው።

AllowCONNECT 443 8443

ይህ ምሳሌ እነዚያን ሁለት የመድረሻ ወደቦች ይመርጣል። ነባሪውን ምርጫ ይተካል፤ 8443ን ከመጨመር ጎን ለጎን ሁሉንም ነባሪ ወደቦች በምስጢር አይጠብቅም። መመሪያውን በሚመለከተው የአገልጋይ ወይም የምናባዊ አስተናጋጅ ውቅር ውስጥ ይጠቀሙ።

የፕሮክሲውን የደንበኛ ፈቃድ ደንቦች በቦታቸው ያቆዩ። የተፈቀደ የመድረሻ ወደብ ደንበኛው አገልግሎቱን ሊጠቀም እንደሚችል ምንም አይናገርም፣ እና የመድረሻ አስተናጋጅ ገደብ ሲያስፈልግ ምትክ አይደለም።

የተገላቢጦሽ ፕሮክሲ ምሳሌ ሌላ ጥያቄን ይመልሳል

ለApache እና HTTPS የፍለጋ ውጤቶች ብዙውን ጊዜ ይፋዊ ድረ-ገጽ ወደ ቋሚ የኋላ አገልጋይ ሲያስተላልፍ ያሳያሉ። ይህ ውቅር አሳሽ የፊት ፕሮክሲን የተመረጠ ድረ-ገጽ ላይ CONNECT ቱኔል እንዲከፍት የሚጠይቅበት መንገድ አይደለም። የማስተላለፊያ መመሪያዎቹን መቅዳት የመጀመሪያውን የፕሮክሲ ችግር ሳይነካ ሊያስቀር ይችላል።

ውድቀትን በሚመረምሩበት ጊዜ ደንበኛው የደረሰበትን አድማጭ፣ የጠየቀውን CONNECT ስልጣን እና የፕሮክሲውን መልስ ይመዝግቡ። CONNECT ከተሳካ እና ከዚያ በኋላ TLS ካልተሳካ፣ የመድረሻ ወደብ ፈቃዱ ድርሻውን አስቀድሞ አከናውኗል። AllowCONNECTን ደጋግመው ከማስፋት ይልቅ በየTLS ውድቀት ይቀጥሉ።

ተዛማጅ ጽሑፎች