એક જ સબનેટની વેબસાઇટ્સ ગેટવેની પારદર્શક પ્રોક્સીને બાયપાસ કરી શકે છે
ઇન્ટરનેટ વિનંતીઓ તેના લોગમાં દેખાય ત્યારે એક જ સબનેટનો ટ્રાફિક ગેટવેના અટકાવ નિયમને કેમ બાયપાસ કરી શકે છે તે સમજાવે છે.
ઇન્ટરનેટ બ્રાઉઝિંગ ગેટવે પ્રોક્સીના લોગમાં દેખાય છે. ઓફિસ LAN પરની વેબસાઇટ દેખાતી નથી. URL ફિલ્ટર બદલતા પહેલા નક્કી કરો કે LAN વિનંતી ગેટવે સુધી પહોંચી હતી કે નહીં.
સીધા જોડાયેલા IPv4 લક્ષ્ય માટે, ક્લાયન્ટ લક્ષ્યનું લિંક-લેયર સરનામું ઉકેલીને સ્થાનિક સેગમેન્ટ પર તેને મોકલી શકે છે. તેનું ડિફોલ્ટ ગેટવે આપમેળે તે માર્ગ પર હોતું નથી. ગેટવે પરનો પારદર્શક અટકાવ નિયમ એવા પેકેટને રીડાયરેક્ટ કરી શકતો નથી જે ગેટવેને ક્યારેય મળતા જ નથી.
ઉદાહરણ તરીકે, એક જ ઓન-લિંક સબનેટના બે હોસ્ટ સ્વિચ દ્વારા ટ્રાફિકની આપલે કરી શકે છે જ્યારે પ્રોક્સી મશીન બીજા સ્વિચ પોર્ટ સાથે જોડાયેલું હોય. ફક્ત તે LAN પર હોવાથી પ્રોક્સી ફોરવર્ડિંગ પોઈન્ટ બનતું નથી.
ઇચ્છિત માર્ગ પસંદ કરો
સ્પષ્ટ પ્રોક્સી સેટિંગ ભાગ લેતી એપ્લિકેશનની વિનંતી પ્રોક્સીને મોકલી શકે છે, ભલે લક્ષ્ય વેબસાઇટ સ્થાનિક હોય. બાયપાસ નિયમો અને PAC નિર્ણયો પણ તપાસો: તેઓ ખાનગી નામો કે સરનામાં માટે જાણી જોઈને DIRECT પસંદ કરી શકે છે.
જો અટકાવ જરૂરી હોય, તો નેટવર્કે અટકાવ બિંદુ ખરેખર માર્ગમાં મૂકવું પડે; Linux ગેટવે પર સ્થાનિક અને ફોરવર્ડ કરેલા પેકેટ માર્ગો અલગ કરો. રાઉટેડ સબનેટ વિભાજન અથવા ઇચ્છાથી ઇનલાઇન બ્રિજ યોગ્ય ડિઝાઇનમાં આ કરી શકે છે, પરંતુ દરેક ફોરવર્ડિંગ અને નિષ્ફળતાની વર્તણૂક બદલે છે. LAN પર બીજે ક્યાંયનો બ્રિજ આપમેળે ઇનલાઇન હોતો નથી.
એપ્લિકેશન પ્રોટોકોલની આવશ્યકતા અલગ રાખો. ટ્રાફિક બોક્સ પાર કર્યા પછી પણ શ્રોતાએ અટકાવ મોડને ટેકો આપવો પડે. પેકેટ ખસેડવા એ HTTPS ડિક્રિપ્ટ કરવાની પરવાનગી નથી અને સામાન્ય SOCKS પોર્ટ તેમને સ્વીકારી શકશે તેની ખાતરી પણ નથી.
ક્લાયન્ટે પસંદ કરેલો માર્ગ, સ્થાનિક સેગમેન્ટ અને વાસ્તવિક ફોરવર્ડિંગ ઉપકરણ નોંધો. પ્રોક્સી લોગ ગેરહાજર હોવું એ લોગિંગ નિષ્ફળતા નહીં પણ ટોપોલોજીનું સાચું વર્ણન હોઈ શકે છે.