વર્કસ્ટેશનને મંજૂર યાદીમાં મૂકવાથી તેની વતી નવી ડાઉનસ્ટ્રીમ પ્રોક્સીને કનેક્ટ થવાની જરૂરી પરવાનગી મળે જ નહીં:

workstation → local proxy → corporate parent → website

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

પેરેન્ટ ખરેખર જે તાત્કાલિક સ્રોત મેળવે છે તે શોધો. ડાઉનસ્ટ્રીમ પ્રોક્સીને ફક્ત ઇચ્છિત સેવા માટે અધિકૃત કરો અને ડાઉનસ્ટ્રીમ ઇન્સ્ટન્સ પર ક્લાયન્ટ પ્રતિબંધો રાખો. નહીં તો મંજૂર મધ્યસ્થ તેને પહોંચી શકે તેવા દરેકને પ્રવેશ આપી શકે છે.

સાદા સોકેટ-પીઅર અર્થઘટનમાં એક જાણી જોઈને કરેલો અપવાદ છે. Squid 6 અને 7 સ્પષ્ટપણે વિશ્વસનીય પીઅરમાંથી X-Forwarded-For અનુસરી શકે છે અને પરિણામી પરોક્ષ ક્લાયન્ટ સરનામું પસંદ કરેલા કાર્યો માટે વાપરી શકે છે. સંબંધિત સેટિંગ્સ નક્કી કરે છે કે સ્રોત ACL તે વ્યુત્પન્ન ઓળખ વાપરે છે કે નહીં; આ સુવિધા સક્ષમ હોય ત્યારે src હંમેશા કાચું પીઅર હોતું નથી.

ફોરવર્ડ થયેલ ઓળખ પર ફક્ત એવા મધ્યસ્થ પર વિશ્વાસ કરો જે તેને યોગ્ય રીતે સાફ કરીને પૂરી પાડે છે. ક્લાયન્ટે આપેલું મનસ્વી X-Forwarded-For એ દાવો કરેલું મૂલ્ય છે, પ્રમાણિત સ્રોત નથી. જ્યાં નીતિ પરવાનગી આપે ત્યાં તાત્કાલિક પીઅર અને વિશ્વસનીય મૂળ ક્લાયન્ટ બંને લોગ કરો: પ્રથમ દર્શાવે છે કોણ પેરેન્ટ સાથે જોડાયું, બીજું દર્શાવે છે ડાઉનસ્ટ્રીમે કોને સેવા આપી.

સંબંધિત લેખો