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 കുറഞ്ഞത് ഒരു ഹോൾഡ് ടൈമറിനെങ്കിലും പ്രവർത്തിക്കട്ടെ.
എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് ഈ അഞ്ച് കാര്യങ്ങൾ സ്ഥിരീകരിക്കുക: പ്രിഫിക്സ് സ്ഥിരമാണോ കിടയ്ക്കുന്നുണ്ടോ, രണ്ടറ്റത്തും അടുത്ത ഹോപ്പ് ഒരു ടണലിലേക്ക് ചൂണ്ടുന്നുണ്ടോ, ഹോപ്പ് എണ്ണം ആവർത്തിക്കുന്നുണ്ടോ, ഒരു സൈറ്റ് മാത്രമാണോ പ്രിഫിക്സിന്റെ ഉടമ, മാറ്റത്തെ അതിജീവിക്കുന്ന അഡ്മിൻ പാത നിങ്ങൾക്കുണ്ടോ. അഞ്ചിൽ ഏതെങ്കിലും അജ്ഞാതമാണെങ്കിൽ, ബാക്കി നാലെണ്ണം ഊഹങ്ങളാണ്.