ટનલ હજી છે, રૂટ ગયો: બે VPN નિષ્ફળતાઓને અલગ પાડવી

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

એક જ ઘટના જેવા દેખાતા ત્રણ તબક્કા

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

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

પહેલા સ્થાપિત રૂટ વાંચો

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

ip route get 10.20.5.10
ip route show 10.20.0.0/16

«unreachable» જવાબનો અર્થ છે કે કોઈ સ્થાપિત રૂટ જ નથી, જે પાછું ખેંચવા અથવા ખૂટતી સ્થાપના તરફ ઇશારો કરે છે. ભૌતિક ઇન્ટરફેસનું નામ લેતો જવાબ એટલે કે ટ્રાફિક કોઈએ નક્કી કર્યા વિના ટનલમાંથી નીકળી ગયો, અને આગલી તપાસ એ જીતેલી પ્રાથમિકતા છે. જ્યારે પેકેટો હજી ગાયબ થતા હોય ત્યારે ટનલનું નામ લેતો જવાબ માર્ગમાં વધુ નીચે, ફિલ્ટરિંગ અથવા સામેની બાજુ તરફ ઇશારો કરે છે.

પછી પ્રોટોકોલના પોતાના દૃશ્યને જુઓ

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

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

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

જ્યારે ઘડિયાળો સંમત ન થાય

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

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

લૂપ વગર પુનઃપ્રાપ્તિ

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

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