હોસ્ટ બિટ સાથે રૂટ નામંજૂર? ઇચ્છિત પ્રીફિક્સ શોધો

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

પાર્સર ખરેખર શું ફરિયાદ કરે છે

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

સાધનો આ અસંગતિને જુદી રીતે સંભાળે છે. કડક પાર્સર લાઇન નામંજૂર કરે છે અને હોસ્ટ બિટનું નામ આપે છે. નરમ પાર્સર સરનામાને માસ્ક કરે છે અને તમે ન માંગ્યું હોય એવું કંઈક સ્થાપિત કરે છે, જે વધુ ખરાબ છે, કારણ કે રૂપરેખાંકન હવે એવી શ્રેણીને રૂટ કરે છે જે તમે ક્યારેય ઇચ્છી ન હતી. પાયથનનું ipaddress મોડ્યુલ પસંદગી સીધી રજૂ કરે છે: કડક નેટવર્ક પાર્સિંગ ભૂલ ઉપજાવે છે, અને strict=False હોસ્ટ બિટને માસ્ક કરી નાખે છે. તમારો ક્લાયન્ટ આવૃત્તિઓ વચ્ચે કડક, નરમ કે અસંગત હોઈ શકે, તેથી ટેવ પર ભરોસો કરવાને બદલે સંદેશ વાંચો.

ઉદાહરણ જાતે કરી જુઓ

એવી ટનલ લો જેને /20 માસ્ક સાથે 172.20.130.0 સુધી પહોંચવું છે. /20 ત્રીજા ઓક્ટેટમાંથી ચાર બિટ ઉધાર લે છે, તેથી તે ઓક્ટેટ ફક્ત 16 ના પગલે ગણાય છે: 0, 16, 32 અને ત્યારબાદ 240 સુધી. 130 મૂલ્ય 128 અને 143 વચ્ચે આવે છે, એટલે ફરતું નેટવર્ક 172.20.128.0 થી શરૂ થાય છે, છેલ્લું ઓક્ટેટ શૂન્ય કરેલા 172.20.130.0 થી નહીં.

લખાયેલા સ્વરૂપમાં બ્લોક 172.20.128.0 થી 172.20.143.255 સુધી ચાલે છે અને 4,096 સરનામાં ધરાવે છે. એ જ મૂલ્યો બિન-કડક પાર્સરને આપવાથી તે તમારા વતી કરતો અવેજી દેખાય છે:

$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096

તમે ખરેખર કયું ગંતવ્ય ઇચ્છતા હતા તે નક્કી કરો

નામંજૂર લાઇન સામાન્ય રીતે ત્રણ ઇરાદાઓમાંથી એક છુપાવે છે, અને પસંદ ફક્ત તમે જ કરી શકો. ટનલને આખું બ્લોક જોઈએ તો 172.20.128.0/20 લખો, જે પ્રમાણભૂત નેટવર્ક સરનામું છે. ટનલને ફક્ત 130 સેગમેન્ટ જોઈએ તો માસ્ક ખોટું હતું અને 172.20.130.0/24 પ્રામાણિક સ્વરૂપ છે. જો એક જ મશીન લક્ષ્ય હોય, IPv4 હોસ્ટ રૂટ /32 છે અને તેમાં કોઈ માસ્ક-ગણિત સામેલ નથી.

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

ફોરવર્ડિંગ ક્યારેય ઉકેલ કેમ ન હતું

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

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

સ્થાપિત રૂટ અને તે જીતતો માર્ગ તપાસો

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

બ્લોકની અંદરનું એક સભ્ય સરનામું અને બહારનું એક પૂછો, જેથી સરખામણી એક જ આશ્વાસનકારક લાઇનને બદલે અર્થપૂર્ણ બને:

ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10

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