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 இரண்டும் பாதையைக் காட்டுகின்றன, UDP ஆய்வுகளை உண்ணும் வடிகட்டலில் இருந்து ICMP பயன்முறை பெரும்பாலும் தப்பிக்கிறது. லூப் என்பது அதே இரு கேட்வே முகவரிகளின் குறுகிய மீளும் வரிசையாகத் தோன்றும், ஒவ்வொரு முறையும் TTL உயரும். வீழ்ச்சி என்பது கடைசியாகப் பதிலளித்த கேட்வேக்குப் பிறகு நட்சத்திரங்களாகத் தோன்றும், ஒரு அமைதியான அடி எதற்கும் சான்றாகாது.
பாதை தெளிவற்றதாக இருக்கும்போது, கம்பியில் TTL ஐப் படியுங்கள். இரு கேட்வேகளிலும் tcpdump -ni any -vv icmp ஒவ்வொரு பாக்கெட்டின் TTL ஐயும் நேரம் மீறிய ஒவ்வொரு பதிலின் மூல முகவரியையும் காட்டுகிறது. பாதையில் இருக்கக்கூடிய அடிகளின் எண்ணிக்கையை விடக் குறைவான TTL உடன் பாக்கெட் தொலை தளத்தை அடைந்தால், traceroute காட்டாத அடிகளை ஏதோ சேர்த்துக் கொண்டிருக்கிறது, ஒரு தளத்தின் ஃபயர்வால் மற்றொன்றின் சார்பாக ஆய்வுகளுக்குப் பதிலளிக்கும்போது இது நிகழ்கிறது.
முன்னொட்டின் உரிமையாளரைச் சரிசெய்து, பின்னர் இரு திசைகளையும் சரிபார்க்கவும்
எந்தத் தளம் இலக்கை உருவாக்குகிறது, எந்த நடுவழிப் பாதைகள் அனுமதிக்கப்படுகின்றன என்பதை முடிவு செய்து, அந்த உரிமையாளரிடம் அறிவிப்பையோ நிலையான ரூட்டையோ மாற்றுங்கள். பெறும் தளத்தைச் சரிசெய்வது கவர்ச்சிகரமானது, பொதுவாகத் தவறு: அது ஒரு முன்னொட்டுக்கு லூப்பை மறைத்து அடுத்ததற்கு மோசமான அறிவிப்பை இடத்திலேயே விட்டுவிடுகிறது. ரூட் குறிச்சொற்கள், பங்கீட்டுப் பட்டியல்கள், split-horizon விதிகள் இதை மூலத்திலேயே நிறுத்த உள்ளன, ஒரு முன்னொட்டுடன் பொருந்தும் வடிகட்டியை விட அவை மலிவானவை.
மாற்றத்திற்குப் பிறகு போகும் திசையையும் திரும்பும் திசையையும் தனித்தனியே சரிபார்க்கவும், ஏனெனில் அறிகுறியில் கண்கூடான முன்னேற்றம் இல்லாமலே லூப் ஒரு கருந்துளையால் மாற்றப்படலாம். இரு முனைகளிலிருந்தும் ip route get இயக்கவும், கேட்வே அல்லாத புரவலனிலிருந்து போக்குவரத்தை அனுப்பவும், ஃபிளாப்பிங்கைப் பழுதுநீக்கமாகத் தவறாகக் கருதாதிருக்க ip monitor route குறைந்தது ஒரு பிடிப்பு நேரங்காட்டி வரை இயங்க விடுங்கள்.
எதையும் மாற்றுவதற்கு முன் இந்த ஐந்து விஷயங்களை உறுதிப்படுத்துங்கள்: முன்னொட்டு நிலையானதா அல்லது கலங்குகிறதா, இரு முனைகளிலும் அடுத்த அடி ஒரு சுரங்கப்பாதையைச் சுட்டுகிறதா, அடிகளின் எண்ணிக்கை மீள்கிறதா, ஒரே தளம் முன்னொட்டை வைத்திருக்கிறதா, மாற்றத்தைத் தாங்கும் நிர்வாகப் பாதை உங்களிடம் உள்ளதா. ஐந்தில் ஒன்று தெரியவில்லை என்றால், மீதமுள்ள நான்கு ஊகங்கள்.