Squid SO_ORIGINAL_DST ભૂલ વાંચવી

NF getsockopt(SO_ORIGINAL_DST) મૂળ ગંતવ્યની શોધ તરફ સંકેત કરે છે. ઇન્ટરસેપ્શન ગોઠવણીમાં Squid એ પુનઃનિર્દેશિત કનેક્શન મૂળે ક્યાં જઈ રહ્યું હતું તે ફરી શોધવું પડે છે.

સ્પષ્ટ રીતે રૂપરેખાંકિત બ્રાઉઝર જાણી જોઈને પોતાની વિનંતીઓ પ્રોક્સીને મોકલે છે. ફક્ત Squid શ્રોતાના પોર્ટ પાસે intercept લખેલું હોવાથી તે કનેક્શનને NAT ઇન્ટરસેપ્શનનો ઇતિહાસ મળતો નથી.

તેથી આ અસંગતિ ગંતવ્યનું પ્રમાણપત્ર સંબંધિત બનતા પહેલાં જ નિષ્ફળ જઈ શકે છે.

કનેક્શન કેવી રીતે આવ્યું તેનાથી શરૂ કરો

• એપ્લિકેશનમાં પ્રોક્સી સરનામું રૂપરેખાંકિત હોય તો, તેણે વાપરવાનો સામાન્ય ફોરવર્ડ-પ્રોક્સી શ્રોતા નક્કી કરો.
• ગેટવે બીજી રીતે સીધું ટ્રાફિક પુનઃનિર્દેશિત કરે તો, તે ઇચ્છિત ઇન્ટરસેપ્શન શ્રોતા સુધી પહોંચે છે કે નહીં અને સમર્થિત NAT રચના જરૂરી ગંતવ્ય માહિતી જાળવે છે કે નહીં તે તપાસો.
• બંને મોડ હોય તો, નિષ્ફળ થતા ક્લાયન્ટે ખરેખર કયું સરનામું અને પોર્ટ સંપર્ક્યું તે તપાસો.

Squid નું http_port દસ્તાવેજીકરણ ભેદ સ્પષ્ટ કરે છે: મોડ ફ્લેગ છોડવાથી ફોરવર્ડ-પ્રોક્સી મોડ પસંદ થાય છે; intercept IP સ્તરે NAT ઇન્ટરસેપ્શનની અપેક્ષા રાખે છે.

પછી પરિવહન સુરક્ષા અલગથી સંભાળો. HTTP પ્રોક્સી CONNECT દ્વારા HTTPS વહન કરી શકે છે. પ્રોક્સી તરફ TLS કનેક્શન માટે સુસંગત શ્રોતા અને ક્લાયન્ટ રૂપરેખાંકન જરૂરી છે. ગંતવ્ય ટ્રાફિક ડિક્રિપ્ટ કરવું એ બીજી વૈકલ્પિક ક્ષમતા છે.

ગંતવ્ય URL HTTPS થી શરૂ થાય છે એટલા માટે પ્રમાણપત્ર ઉત્પાદન ચાલુ કરતું જૂનું “HTTPS ઉપાય” નકલ ન કરો. પહેલા ક્લાયન્ટ અને શ્રોતા વચ્ચેની સંમતિ સુધારો. પછી ખરેખરી TLS ભૂલ રહે તો તે તપાસ માટે વધુ ઉપયોગી ભૂલ હશે.