VPN સાથી અન્ય ઇન્ટરફેસ પર પિંગ કરે છે કારણ કે તે સ્થાનિક છે

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

એક માર્ગ બીજા કોઈના માટે પેકેટ ફોરવર્ડ કરે છે; બીજો તેમને હોસ્ટને જ પહોંચાડે છે.

હોસ્ટને સંબોધિત પેકેટ હોસ્ટમાં જ રહે છે

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

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

શા માટે ip_forward લાગુ પડતું નથી

ફોરવર્ડિંગ તે પેકેટને નિયંત્રિત કરે છે જે જે ઇન્ટરફેસ પર આવ્યા તેના કરતાં અલગ ઇન્ટરફેસ દ્વારા બહાર જવા પડે. હોસ્ટને જ પિંગ ક્યારેય તે માર્ગ નથી લેતું: પેકેટ સ્થાનિક રીતે વપરાય છે અને જવાબ સ્થાનિક રીતે ઉત્પન્ન થાય છે. તેથી net.ipv4.ip_forward=0 સેટ કરવાથી અહીં કંઈ બદલાતું નથી, અને ફોરવર્ડ ચેઇનનો નિયમ ક્યારેય તે ટ્રાફિક જોતો નથી. યોગ્ય નિયંત્રણ ઇનપુટ માર્ગ પર છે, આવતી ઇન્ટરફેસ અથવા સ્રોત દ્વારા મર્યાદિત.

તેથી ફોરવર્ડિંગ બંધ કરવું અને હોસ્ટ અલગ છે એમ માનવું સુરક્ષાની ખોટી ભાવના ઉત્પન્ન કરે છે.

નિર્ણય લેનાર સ્થાનિક કોષ્ટક વાંચો

ip rule show સામાન્ય રીતે શૂન્ય પ્રાથમિકતાનો નિયમ જણાવે છે જે બધી શોધ પહેલાં સ્થાનિક કોષ્ટક પર મોકલે છે, અને ip route show table local હોસ્ટના પોતાના સરનામાં સ્થાનિક વ્યાપ સાથે સૂચિબદ્ધ કરે છે. તે કોષ્ટકમાં વહીવટી રીતે બંધ પણ હજી ગોઠવેલી ઇન્ટરફેસના સરનામાંનો સમાવેશ થાય છે. સ્થિર રીતે સોંપાયેલા IPv4 સરનામાં સામાન્ય રીતે લિંક તૂટવા પર પણ ટકી રહે છે, અને એટલે જ બંધ કરેલા બ્રિજને પિંગ હજી સફળ થઈ શકે છે અને ઓપરેટરને આશ્ચર્યમાં મૂકી શકે છે.

IPv6 બરાબર આ મુદ્દે અસહમત છે. લિંક તૂટે ત્યારે તેનાં સરનામાં સામાન્ય રીતે પાછળ લેવાય છે, સિવાય કે keep_addr_on_down સેટ હોય. એક નિયમ બંનેને આવરી લે છે એમ માનવાને બદલે કુટુંબોની સરખામણી કરો.

એક સાથી ખરેખર શું સુધી પહોંચે છે

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

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

તમે નિવૃત્ત કરવા માંગતા હતા તે સરનામાં પણ તપાસો. ઇન્ટરફેસ પરથી સરનામું દૂર કરવું જૂના સરનામા પર ફાયરવોલ નિયમો ચઢાવવા કરતાં વધુ વિશ્વસનીય છે.