એક નેટવર્ક કાર્ડ સ્પષ્ટ પ્રોક્સી માટે પૂરતું છે

ખાનગી ફોરવર્ડ પ્રોક્સીને લેપટોપ અને રાઉટર વચ્ચે ભૌતિક રીતે બેસવાની જરૂર નથી. તે એક નેટવર્ક ઇન્ટરફેસ વાપરીને એક જ LAN પરનું બીજું મશીન હોઈ શકે છે.

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

client → proxy listener
proxy → existing router → destination

જે એપ્લિકેશને પ્રોક્સી સ્પષ્ટ રીતે પસંદ કર્યું છે તેના માટે આ પૂરતું છે. લિનક્સ પર, આ સામાન્ય ગોઠવણને એપ્લિકેશનની વિનંતીઓ રિલે કરવા માટે માત્ર IP ફોરવર્ડિંગ સક્ષમ કરવાની જરૂર નથી.

ડિફોલ્ટ ગેટવે બીજા પ્રશ્નનો જવાબ આપે છે

ક્લાયન્ટનું ડિફોલ્ટ ગેટવે ક્લાયન્ટ અન્ય નેટવર્ક તરફ મોકલતા પેકેટ સંભાળે છે. તે સેટિંગ બદલવાથી બ્રાઉઝર HTTP પ્રોક્સી વિનંતીઓ અથવા SOCKS વાટાઘાટ કરતું નથી. એ જ રીતે, બ્રાઉઝરમાં પ્રોક્સી દાખલ કરવાથી બીજી દરેક એપ્લિકેશન તે મશીનમાંથી રૂટ થતી નથી.

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

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

જો જરૂરિયાત ફરજિયાત ઉપયોગ હોય, તો નક્કી કરો કે વૈકલ્પિક આઉટબાઉન્ડ ટ્રાફિક ક્યાં નિયંત્રિત કરી શકાય. એક ઇન્ટરફેસની સ્પષ્ટ પ્રોક્સી માન્ય સેવા હોઈ શકે છે જ્યારે અલગ ગેટવે નેટવર્ક નીતિ લાગુ કરે છે. અમલ પેકેટ ખરેખર જ્યાંથી પસાર થાય ત્યાં મૂકો.