ICMP રીડાયરેક્ટ વિરુદ્ધ તમારા VPN રૂટ: ખરેખર શું બદલાય છે

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

રીડાયરેક્ટ એ રાઉટર તરફથી એક સૂચન છે

IPv4માં ICMP રીડાયરેક્ટનો પોતાનો સંદેશ-પ્રકાર અને સાંકડી શરતોનો સમૂહ છે: રાઉટર પેકેટને જે ઇન્ટરફેસ પરથી આવ્યું તેના દ્વારા જ આગળે મોકલે છે, અને તે જ લિંક પર લક્ષ્યની નજીકનો આગળનો હોપ જાણે છે. પછી તે પ્રેષકને સીધો તે આગળનો હોપ વાપરવા કહે છે. સંદેશ નવા ગેટવેનું નામ લે છે અને મૂળ પેકેટનો ભાગ સમાવે છે જેથી પ્રેષક તેને ફ્લો સાથે મેળવી શકે. તે સ્થાનિક ટોપોલોજી વિશેનો સૌજન્ય સંદેશ છે, અને તે ધારે છે કે પ્રેષક સૂચિત ગેટવે સાથે લિંક વહેંચે છે.

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

એ જ ભેદમાં મોટા ભાગની રીડાયરેક્ટ તપાસ ખોટી દિશામાં જાય છે.

IPv4 અને IPv6 તેને જુદી રીતે પહોંચાવે છે

IPv6માં સમાન રચના ICMPv4માં નહીં, પાડોશી-શોધની અંદર છે, જુદા સંદેશ-બંધારણ અને જુદા માન્યતા-નિયમો સાથે. વિભાવનાઓ મળે છે, પેકેટ મળતાં નથી. ICMP પ્રકાર 5 માટે લખાયેલું કેપ્ચર ફિલ્ટર IPv6 નેટવર્ક પર કંઈ બતાવશે નહીં, જેને ક્યારેક કોઈ રીડાયરેક્ટ ન બન્યાના પુરાવા તરીકે વાંચવામાં આવે છે.

નીતિના નોબ પણ અલગ છે, તેથી યજમાન IPv4 રીડાયરેક્ટ સ્વીકારી IPv6 અવગણી શકે, અથવા ઊલટું.

જો પ્રશ્નમાંનો ફ્લો બંનેમાંથી કોઈ પણ વાપરી શકે તો બંને કુટુંબ તપાસો.

સ્વીકાર એ યજમાનની નીતિ છે, નેટવર્કની હકીકત નહીં

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

સુરક્ષિત-રીડાયરેક્ટ સેટિંગ્સ વધુ મર્યાદિત કરે છે કે કયા ગેટવે પર વિશ્વાસ કરી શકાય.

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

રીડાયરેક્ટ શું સમજાવી શકતું નથી

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

જૂનાં કેપ્ચર બીજી જાળ છે, કારણ કે નેટવર્ક બદલનારા ક્લાયન્ટનો સ્થાનિક ગેટવે અલગ હોય છે.

અગાઉના જોડાણનું જૂનું રીડાયરેક્ટ વર્તમાન માર્ગ વિશે કંઈ સમજાવતું નથી, તેથી નોંધો કે હવે કયું ઇન્ટરફેસ નિયંત્રણ-ટ્રાફિક મેળે છે.

ટનલને દોષ આપતા પહેલાં રૂટ તપાસો

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

સુરક્ષિત માર્ગ ચૂપચાપ અસુરક્ષિત બનવાનું કારણ રીડાયરેક્ટ ક્યારેય ન હોવું જોઈએ, અને એટલે જ સ્વીકાર-નીતિ રચના-સમીક્ષામાં આવે છે. RFC 792ની વ્યાખ્યા IPv4 સંદેશ શું કહી શકે તે માટેનો સંદર્ભ રહે છે.

રૂટ શોધ અને કેપ્ચરનો સમય-છાપ સાથે લખો, પછીની વ્યક્તિ તમારા તારણને પુનઃઉત્પાદિત કરી શકશે.