VPN સાઇટ્સ પર રાઉટિંગ લૂપને રૂટ ફ્લેપિંગથી કેવી રીતે અલગ પાડવું
રાઉટિંગ લૂપ અને ફ્લેપિંગ રૂટ સમાન વિરામયુક્ત નુકસાન કરે છે. ગેટવે પરની ત્રણ તપાસ તમે કંઈપણ બદલો તે પહેલાં તેમને અલગ પાડે છે.
બે સાઇટ્સ, એક ટનલ અને એક દૂરનું પ્રીફિક્સ જે થોડા સમય માટે જવાબ આપે છે અને પછી શાંત થઈ જાય છે. પ્રતિક્રિયા એ છે કે તેને રાઉટિંગ લૂપ કહેવું, અને ક્યારેક તે બરાબર એવું જ હોય છે. પરંતુ લૂપ અને ફ્લેપિંગ રૂટ સમાન ફરિયાદ ઉત્પન્ન કરે છે, અને તેમને વિરોધી સમારકામની જરૂર છે: એક એ ફોરવર્ડિંગ નિર્ણય છે જે ક્યારેય પૂરો થતો નથી, બીજું એ પ્રીફિક્સ છે જે વારંવાર ટેબલ છોડે છે. ત્રણ અવલોકનો તેમને અલગ પાડે છે, અને ફિલ્ટરને સ્પર્શ કરો અથવા ટનલ ફરી શરૂ કરો તે પહેલાં તમે ત્રણેય ગેટવેની કમાન્ડ લાઇન પરથી એકત્રિત કરી શકો છો.
લૂપ હોપ દર હોપ નક્કી થાય છે. સાઇટ A ગંતવ્ય માટે B ને આગલા હોપ તરીકે પસંદ કરે છે, B તે જ ગંતવ્ય માટે A ને પસંદ કરે છે, અને પેકેટ બે આવા-જાવા પછી TTL પર સમાપ્ત થાય છે. ફ્લેપિંગનો નિર્ણય તેના બદલે રાઉટિંગ પ્રોટોકોલ કરે છે: પ્રીફિક્સ પાછું ખેંચાય છે, ફરી સ્થાપિત થાય છે અથવા વૈકલ્પિક આગલા હોપ દ્વારા બદલાય છે, તેથી કેટલાક પેકેટને કોઈ રૂટ જ હોતો નથી જ્યારે અન્ય સંપૂર્ણ સારા રૂટને અનુસરે છે.
પ્રશ્નનો ઉકેલ લાવતી ત્રણ તપાસ
પ્રથમ નિર્ણય લેવા માટે તમને પેકેટ કેપ્ચરની જરૂર નથી. તમને બંને છેડે પ્રીફિક્સની સ્થિતિ, દરેક બાજુ પસંદ કરે તે આગલો હોપ, અને એ હોપ ગણતરીની જરૂર છે જે કાં તો પુનરાવર્તન થાય કાં ન થાય. જો ટ્રાફિક નિષ્ફળ જતી વખતે પ્રીફિક્સ તે જ આગલા હોપ સાથે સ્થાપિત રહે, તો લૂપ ફોરવર્ડિંગ પાથમાં રહે છે. જો પ્રીફિક્સ અદૃશ્ય થઈને પાછું આવે, તો ખામી ફોરવર્ડિંગની ઉપર છે અને સમારકામ રાઉટિંગ પ્રોટોકોલનું છે, સ્થિર રૂટનું નહીં.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
શરૂ કરતા પહેલાં એક ચેતવણી. જો તમે આ લૂપ થઈ રહેલી ટનલ પરથી વાંચી રહ્યા છો, તો તમે રૂટ બદલશો તે ક્ષણે તમારું સત્ર મરી જશે. એવું કન્સોલ અથવા સંચાલન માર્ગ ખોલો જે તમે સમારવા જઈ રહ્યા છો તે પ્રીફિક્સ પર આધારિત ન હોય.
તપાસ એક: પ્રીફિક્સ સ્થિર છે કે થથરે છે
કર્નલને પૂછો કે તેણે શું સ્થાપિત કર્યું, કન્ફિગરેશન ફાઇલ શું વચન આપે છે તે નહીં. લિનક્સ ગેટવે પર, ip route get 10.20.30.40 ફોરવર્ડિંગ પાથ જે શોધ ચલાવે છે તે જ શોધ ચલાવે છે, નીતિ ટેબલ સહિત, જ્યારે ip route show 10.20.30.0/24 એન્ટ્રી પોતે બતાવે છે. ip monitor route દરેક ફેરફાર થતાં જ પ્રસારિત કરે છે, જે પ્રીફિક્સને આવતું અને જતું જોવાની સૌથી ઝડપી રીત છે.
FRR અથવા BIRD ચલાવતા રાઉટર પર, રસપ્રદ વસ્તુ ફોરવર્ડિંગ ટેબલ નથી. show ip bgp 10.20.30.0/24 પસંદ કરેલો પાથ અને તેનો અપટાઇમ પરત આપે છે; દર થોડી મિનિટે રીસેટ થતો અપટાઇમ એ ફ્લેપિંગ છે જેને તમે નામ આપી શકો, લૂપ નહીં. show ip bgp summary પડોશીની સ્થિતિ અને પ્રીફિક્સની ગણતરી બતાવે છે, તેથી વારંવાર પડતો પીઅર ફોરવર્ડિંગ પાથ પરથી દોષ લઈ લે છે.
કંઈપણ બદલો તે પહેલાં જવાબ લખી લો. પિંગ નિષ્ફળ જતી વખતે દસ મિનિટ સ્થિર રહેવું, અને દસ મિનિટમાં ચાર વખત અદૃશ્ય થવું, જુદા જુદા આગળના પગલાં તરફ દોરે છે. બીજું સ્થિર રૂટના દરેક સિદ્ધાંતને અપ્રસ્તુત કરી દે છે.
તપાસ બે: શું આગલો હોપ પાછો આગમન ટનલમાં ઇશારો કરે છે
લૂપ માટે બે ગેટવેની સંમતિ જરૂરી છે. પેકેટ સ્વીકારતી સાઇટ પર, પેકેટ બહાર જવા માટે જે રૂટ વાપરશે તે જુઓ: વાસ્તવિક સ્રોત સરનામા સાથે ip route get 10.20.30.40 from 10.10.5.20, કારણ કે નીતિ નિયમ મુખ્ય ટેબલ કરતાં જુદો જવાબ આપી શકે છે. પછી જે સાઇટે તેને મોકલ્યું તેના પર શોધનું પુનરાવર્તન કરો. જો દરેક બાજુ સમાન પ્રીફિક્સ માટે બીજી બાજુને આગલા હોપ તરીકે પસંદ કરે, તો લૂપ સાબિત થાય છે અને કોઈ કેપ્ચર કંઈ ઉમેરશે નહીં.
કારણ લગભગ હંમેશા એ જાહેરાત હોય છે જેને ટનલ પાર ન કરવી જોઈતી હતી. ટનલમાં પુનઃવિતરિત કરાયેલ ડિફોલ્ટ રૂટ, દૂરની સાઇટના પોતાના સબનેટને આવરી લેતું એગ્રીગેટ, અથવા સલામતી ખાતર પીઅર તરફ ઇશારો કરતો સ્થિર રૂટ — બધા એ જ પરસ્પર આગલો હોપ બનાવે છે. ટનલ સંપૂર્ણપણે સ્થપાયેલી હોવા છતાં ટ્રાફિક વર્તુળમાં લઈ શકે છે; strongSwan ની ફોરવર્ડિંગ નોંધો તે જરૂરિયાતની રાઉટિંગ બાજુ વર્ણવે છે.
WireGuard પોતાની નોંધને પાત્ર છે, કારણ કે દોષ આપવા માટે કોઈ જાહેરાત નથી. wg show દરેક પીઅર માટે AllowedIPs સૂચિબદ્ધ કરે છે, અને કર્નલ પીઅર માટે ગંતવ્ય ત્યારે જ સ્વીકારે છે જ્યારે તે તે શ્રેણીમાં આવે. ત્યાંનું લૂપ એક ઓવરલેપ થતી AllowedIPs શ્રેણી અથવા ઇન્ટરફેસ પાર પાછળ ઇશારો કરતો સ્થિર રૂટ છે, તેથી સમારકામ ફક્ત એ બે જગ્યાએ જ રહે છે.
તપાસ ત્રણ: હોપ ગણતરી વાંચો, તારા નહીં
traceroute -n -I 10.20.30.40 અને mtr -n -r -c 20 10.20.30.40 બંને પાથ બતાવે છે, અને ICMP મોડ ઘણી વાર એવા ફિલ્ટરિંગમાંથી બચી જાય છે જે UDP પ્રોબ ખાઈ જાય છે. લૂપ એ જ બે ગેટવે સરનામાંનો ટૂંકો પુનરાવર્તિત ક્રમ જેવો દેખાય છે, જેમાં દર વખતે TTL વધે છે. પડવું એ છેલ્લા જવાબ આપનાર ગેટવે પછીના તારા જેવું દેખાય છે, અને એક જ શાંત હોપ કંઈપણનો પુરાવો નથી.
જ્યારે પાથ અસ્પષ્ટ હોય, ત્યારે વાયર પર TTL વાંચો. બંને ગેટવે પર tcpdump -ni any -vv icmp દરેક પેકેટનું TTL અને દરેક સમય-વીતી ગયાના જવાબનું સ્રોત સરનામું બતાવે છે. જો પેકેટ દૂરની સાઇટ પર પાથમાં હોઈ શકે તે હોપની સંખ્યા કરતાં ઓછા TTL સાથે પહોંચે, તો કંઈક એવા હોપ ઉમેરી રહ્યું છે જે traceroute તમને બતાવતું નથી, અને તે ત્યારે થાય છે જ્યારે એક સાઇટનો ફાયરવોલ બીજાના વતી પ્રોબનો જવાબ આપે છે.
પ્રીફિક્સના માલિકનું સમારકામ કરો, પછી બંને દિશાઓ ચકાસો
નક્કી કરો કે કઈ સાઇટ ગંતવ્ય ઉત્પન્ન કરે છે અને કયા ટ્રાન્ઝિટ પાથ માન્ય છે, પછી તે માલિક પાસે જાહેરાત અથવા સ્થિર રૂટ બદલો. પ્રાપ્ત કરતી સાઇટને સુધારવી લલચાવનારી અને સામાન્ય રીતે ખોટી છે: તે એક પ્રીફિક્સ માટે લૂપ છુપાવે છે અને આગલા માટે ખરાબ જાહેરાત જગ્યાએ રહેવા દે છે. રૂટ ટેગ, વિતરણ સૂચિ અને સ્પ્લિટ-હોરાઇઝન નિયમો આને સ્રોત પર રોકવા માટે છે, અને તે એક જ પ્રીફિક્સ સાથે મેળ ખાતા ફિલ્ટર કરતાં સસ્તા છે.
ફેરફાર પછી જવાની અને પાછા આવવાની બંને દિશા અલગથી ચકાસો, કારણ કે લક્ષણમાં કોઈ દૃશ્યમાન સુધારો વગર લૂપને બ્લેક હોલ દ્વારા બદલી શકાય છે. બંને છેડેથી ip route get ચલાવો, ગેટવે ન હોય તેવા હોસ્ટ પરથી ટ્રાફિક મોકલો, અને ઓછામાં ઓછા એક હોલ્ડ ટાઇમર માટે ip monitor route ચાલુ રાખો જેથી ફ્લેપિંગને સમારકામ ગણવામાં ન આવે.
કંઈપણ બદલો તે પહેલાં આ પાંચ મુદ્દા પુષ્ટિ કરો: પ્રીફિક્સ સ્થિર છે કે થથરે છે, બંને છેડે આગલો હોપ ટનલ તરફ ઇશારો કરે છે, હોપ ગણતરી પુનરાવર્તન થાય છે કે નહીં, એક સાઇટ પ્રીફિક્સની માલિક છે, અને તમારી પાસે એવો સંચાલન માર્ગ છે જે ફેરફારમાંથી બચી જાય છે. જો પાંચમાંથી કોઈ એક અજ્ઞાત હોય, તો બાકીના ચાર અનુમાન છે.