127.0.0.1 પર DNAT ને વિશેષ કાળજી કેમ જોઈએ

એક સેવા 127.0.0.1:1080 પર સાંભળે છે. DNAT નિયમ આવતા ટ્રાફિકને તે સરનામા તરફ મોકલે છે, તો પણ જોડાણ નિષ્ફળ જાય છે. સેવા સ્વસ્થ હોઈ શકે અને NAT નિયમ મેળ ખાઈ શકે: IPv4 લૂપબેક સરનામાંને રૂટિંગમાં વિશેષ વર્તન મળે છે.

લિનક્સનું route_localnet નક્કી કરે છે કે રૂટિંગ દરમિયાન 127/8 સરનામાંને મંગળ સરનામાં તરીકે ગણવામાં આવે કે નહીં. તેનું મૂળભૂત મૂલ્ય સામાન્ય લૂપબેક સીમા જાળવે છે. ચોક્કસ ઇન્ટરફેસ માટેનો અપવાદ ઇરાદાપૂર્વકના સ્થાનિક રીડાયરેક્શન ડિઝાઇન માટે સંબંધિત હોઈ શકે છે.

એ સમજાવે છે કે બીજા મશીનનો કામ કરતો નિયમ તમે કૉપિ ન કરેલા sysctl પર કેમ આધાર રાખી શકે. પરંતુ તે વિકલ્પને દરેક જગ્યાએ ચાલુ કરવાનું વાજબી ઠેરવતું નથી.

સુરક્ષા ધારણા માર્ગ સાથે બદલાય છે

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

સેવા ધરાવતી નેટવર્ક નામસ્થળની સમીક્ષા કરો. કન્ટેનરનું લૂપબેક હોસ્ટનું લૂપબેક નથી, અને હોસ્ટ ઇન્ટરફેસની સેટિંગ બદલવાથી કન્ટેનરમાં આપમેળે શ્રોતા બનતું નથી.

rp_filter સ્રોત-માર્ગ માન્યતા વિશે બીજા પ્રશ્નનો જવાબ આપે છે. તેને વૈશ્વિક રીતે બંધ કરવું લૂપબેક રૂટિંગ સમજવાનો સામાન્ય વિકલ્પ નથી. તે જ રીતે ip_nonlocal_bind સોકેટને બિન-સ્થાનિક સરનામાં સાથે બાંધવા વિશે છે, આ DNAT માર્ગને સાચો કરવા વિશે નહીં.

અંતે, રીડાયરેક્ટ થયેલ પ્રોટોકોલ શ્રોતા સાથે મેળ ખાવો જોઈએ. SOCKS પોર્ટ પર કાચો HTTP કે TLS ટ્રાફિક મોકલવા માટે હજી પણ અનુવાદક જોઈએ; રૂટિંગ અપવાદ ખૂટતી વાટાઘાટ પૂરી પાડી શકતો નથી.