client → local TCP relay → existing forward proxy → destination

આ ગોઠવણીમાં રિલે પાસે એક નિશ્ચિત અપસ્ટ્રીમ છે. તે ક્લાયન્ટની વિનંતી બદલ્યા વિના હાલની ફોરવર્ડ પ્રોક્સીને મોકલે છે. તે પ્રોક્સી સંપૂર્ણ URL અથવા CONNECT લક્ષ્ય વાંચે છે, નીતિ લાગુ કરે છે અને ગંતવ્ય કનેક્શન ખોલે છે.

રિલેને સીધા વેબસાઇટ તરફ નિર્દેશિત કરવાથી કરાર બદલાય છે. ફોરવર્ડ પ્રોક્સીએ ગંતવ્યો પસંદ કરવા અને HTTP ફ્રેમિંગ તથા કનેક્શન વર્તન સંભાળવું પડે; પ્રથમ લાઇનમાંથી હોસ્ટનામ કાઢવું પૂરતું નથી.

Nmap નું Ncat અલગથી HTTP-જાણકાર સાંભળવાનો મોડ આપે છે:

ncat --listen 127.0.0.1 3128 --proxy-type http

આ loopback ઉદાહરણ Ncat ના પ્રોક્સી અમલીકરણનો ઉપયોગ કરે છે, દરેક nc માં સામાન્ય લક્ષણ નહીં. તેની સાંભળવાની બાજુની પ્રોક્સી HTTP પદ્ધતિઓ અને CONNECT સંભાળે છે. તેના ક્લાયન્ટ-બાજુના SOCKS વિકલ્પો સાંભળવાના મોડમાં SOCKS સર્વર સ્થાપિત કરતા નથી. કાયમી વહેંચાયેલ સેવાને પણ વિચારપૂર્વક કનેક્શન સંભાળ, પ્રવેશ નિયંત્રણ અને લોગિંગની જરૂર છે.

નિરીક્ષણ માટે, એન્ક્રિપ્શનની સીમા શોધો. સાદા HTTP પ્રોક્સી કનેક્શન પરનો રિલે પ્રોક્સી વિનંતીઓ અને જવાબો જોઈ શકે છે. CONNECT પછી ગંતવ્યનું HTTPS TLS બાઇટ્સ છે, વાંચી શકાય તેવી પૃષ્ઠ સામગ્રી નહીં. પ્રોક્સી સુધીનું TLS તે કડી પરની પ્રારંભિક પ્રોક્સી આપલે પણ છુપાવે છે. અર્થઘટિત વ્યવહારો માટે ક્લાયન્ટ/પ્રોક્સી નિદાન વાપરો અને ઓળખપત્રો કે સંવેદનશીલ URL ધરાવી શકે તેવા લોગ સુરક્ષિત રાખો.

સંબંધિત લેખો