നിങ്ങളുടെ BGP സെഷൻ VPC റൂട്ട് ടേബിളിൽ കാണാത്തത് എന്തുകൊണ്ട്

ആവർത്തിക്കപ്പെടുന്ന കഥ ഇതാണ്: EC2 VPN അപ്ലയൻസിലെ റൂട്ടിംഗ് ഡീമൺ BGP ഉയർന്നാൽ VPC-യ്ക്ക് അതിന്റെ ദൂരസ്ഥ പ്രിഫിക്സുകൾ പഠിപ്പിക്കും. അതിന്റെ പകുതി ശരിയാണ്. സെഷൻ ഉയരുന്നു, അതുകൊണ്ട് VPC റൂട്ട് ടേബിളിൽ ഒന്നും മാറുന്നില്ല, അതിനാൽ ആദ്യ ലക്ഷണം സാധാരണയായി ട്രാഫിക് നിശബ്ദമായി ഒരു കറുത്ത കുഴിയിലേക്ക് ഇടുന്ന ഒരു സബ്നെറ്റ് ആണ്.

ഇവിടെ രണ്ട് വ്യത്യസ്ത കാര്യങ്ങൾ കൂട്ടിച്ചേർക്കുന്നു: ഒരു റൂട്ട് സെർവറുമായുള്ള പിയറിംഗ്, ടേബിളിലേക്ക് റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നത്.

കെട്ടുകഥ: BGP ഉയർത്തൂ, VPC പ്രിഫിക്സുകൾ പഠിക്കും

BGP രണ്ട് സംസാരിക്കുന്നവർ തമ്മിലുള്ള സംഭാഷണമാണ്, ഈ രൂപകൽപ്പനയിൽ സംസാരിക്കുന്നവർ നിങ്ങളുടെ അപ്ലയൻസിലെ റൂട്ടിംഗ് ഡീമണും AWS നിങ്ങളുടെ ഉടമസ്ഥതയിലുള്ള സബ്നെറ്റിൽ സ്ഥാപിക്കുന്ന VPC Route Server എൻഡ്പോയിന്റുമാണ്. ആ സംഭാഷണം പ്രിഫിക്സുകൾ വഹിക്കുന്നു. അത് നിങ്ങളുടെ വർക്ക്ലോഡ് സബ്നെറ്റുകളുടെ റൂട്ട് ടേബിളിൽ തൊടുന്നില്ല, കാരണം ആ ടേബിളുകൾ ഓരോന്നിലും പ്രവർത്തനക്ഷമമാക്കേണ്ട പ്രചരണത്തിലൂടെ മാത്രമേ പഠിക്കൂ. അത് സംഭവിക്കുന്നതുവരെ, VPCയുടെ വസ്ത്രം അപ്ലയൻസിന് അറിയാവുന്നതിനെക്കുറിച്ച് ഒന്നും അറിയില്ല.

സെറ്റപ്പ് ഘട്ടങ്ങൾ ഒരു കാരണത്താൽ വേർതിരിച്ചിരിക്കുന്നു: ബന്ധിപ്പിക്കുക, എൻഡ്പോയിന്റ് സൃഷ്ടിക്കുക, പിയർ ചെയ്യുക, പിന്നീട് പ്രചരണം പ്രവർത്തനക്ഷമമാക്കുക.

Route Server ഒരു കൺട്രോൾ പ്ലെയിൻ ആണ്, ടണൽ അല്ല

Route Server ഒരു പാക്കറ്റ് പോലും എൻക്രിപ്റ്റ് ചെയ്യുന്നില്ല, ഫോർവേഡ് ചെയ്യുന്നില്ല, പരിശോധിക്കുന്നില്ല. അപ്ലയൻസുമായി BGP കൈമാറാനും ലഭിച്ച പ്രിഫിക്സുകൾ അവ സ്വീകരിക്കാൻ കോൺഫിഗർ ചെയ്ത റൂട്ട് ടേബിളുകൾക്ക് നൽകാനും ഇത് നിലകൊള്ളുന്നു. ഡാറ്റാ പ്ലെയിൻ മാറിയിട്ടില്ല: പാക്കറ്റുകൾ ഇപ്പോഴും അപ്ലയൻസിന്റെ നെറ്റ്വർക്ക് ഇന്റർഫേസിലൂടെ പുറത്തുപോകുന്നു, അതിന്റെ VPN-ലൂടെ സഞ്ചരിക്കുന്നു, അതേ വഴിയിൽ തിരികെ വരുന്നു.

അതായത് ഫോർവേഡിംഗ് ഇൻസ്റ്റൻസിലെ ഉറവിട, ലക്ഷ്യ പരിശോധന ഇപ്പോഴും പ്രധാനമാണ്, കാരണം ഇൻസ്റ്റൻസ് ഇപ്പോൾ മറ്റൊരാൾക്ക് അയച്ച ട്രാഫിക് ഫോർവേഡ് ചെയ്യുന്നു.

സെക്യൂരിറ്റി ഗ്രൂപ്പുകളും സബ്നെറ്റ് നിയന്ത്രണങ്ങളും ഫോർവേഡ് ചെയ്യുന്ന ഫ്ലോയ്ക്കും ബാധകമാണ്. ട്രാഫിക് ഉപേക്ഷിക്കുന്ന അപ്ലയൻസിനെ Route Server അത് ഫോർവേഡ് ചെയ്യാൻ നിർബന്ധിക്കില്ല, ദൂരെയുള്ള വശത്ത് കാണാത്ത റിട്ടേൺ റൂട്ടും നന്നാക്കില്ല.

പ്രചരണം ഓരോ റൂട്ട് ടേബിളിനും ആണ്, മുഴുവൻ VPCയ്ക്കും അല്ല

റൂട്ട് സെർവറിനെ VPCയുമായി ബന്ധിപ്പിക്കുന്നതും ഒരു റൂട്ട് ടേബിളിൽ പ്രചരണം പ്രവർത്തനക്ഷമമാക്കുന്നതും രണ്ട് തീരുമാനങ്ങളാണ്, രണ്ടാമത്തേത് മാത്രമാണ് സബ്നെറ്റ് എന്ത് ചെയ്യുന്നു എന്നത് മാറ്റുന്നത്. ആറ് റൂട്ട് ടേബിളുകളുള്ള ഒരു VPCയ്ക്ക് ഒരു പ്രചരിത പ്രിഫിക്സ് ഒന്നിൽ സ്വീകരിക്കാം, ബാക്കി അഞ്ചിൽ സ്വീകരിക്കാനാകില്ല, ഇത് ഒരു ഹബ് സബ്നെറ്റിന് കൃത്യമായി ശരിയാണ്, കൃത്യമായി «പകുതി പ്രവർത്തിക്കുന്നു» എന്ന ആശയക്കുഴപ്പമുള്ള ഫലം ഉണ്ടാക്കുന്നതും ഇതാണ്. പ്രചരണം ഓണായിരിക്കുന്നിടത്തും ഒരു എതിർ റൂട്ട് ജയിക്കാം, കാരണം VPC റൂട്ട് തിരഞ്ഞെടുപ്പ് ഏറ്റവും നീളമുള്ള പ്രിഫിക്സിന് മുൻഗണന നൽകുന്നു, തുല്യ നീളത്തിൽ പ്രചരിതത്തിന് മേൽ സ്റ്റാറ്റിക് റൂട്ടിന് മുൻഗണന നൽകുന്നു. ഈ മുൻഗണന നിശബ്ദമായി പ്രയോഗിക്കുന്നു.

അപ്ലയൻസ് പ്രഖ്യാപിക്കുന്ന പ്രിഫിക്സുകളുടെ പട്ടികയ്ക്ക് പകരം നിർദ്ദിഷ്ട സബ്നെറ്റിന്റെ ഫലപ്രദമായ ടേബിൾ പരിശോധിക്കുക. API ആ ചോദ്യത്തിന് നേരിട്ട് ഉത്തരം നൽകുന്നു: aws ec2 associate-route-server ഉം aws ec2 enable-route-server-propagation --route-table-id <id> ഉം ആളുകൾ മറക്കുന്ന രണ്ട് ഘട്ടങ്ങളാണ്, aws ec2 describe-route-tables --route-table-ids <id> പ്രിഫിക്സ് route server എൻട്രിയായി വന്നോ എന്ന് കാണിക്കുന്നു.

അപ്ലയൻസ് ഇപ്പോഴും ഓരോ പാക്കറ്റും വഹിക്കുന്നു

എത്തിച്ചേരാനുള്ള കഴിവ് പ്രഖ്യാപിക്കുന്നത് അത് ഉണ്ടായിരിക്കുന്നതിന് തുല്യമല്ല. BGP സെഷൻ അപ്ലയൻസിന്റെ VPN പ്രവർത്തിക്കാതെയും സ്ഥാപിതമായി നിലനിൽക്കാം, ഒരിക്കലും മാറാത്ത സ്റ്റാറ്റിക് പ്രഖ്യാപനം ട്രാഫിക് മരിച്ച വഴിയിലേക്ക് വലിച്ചുകൊണ്ടിരിക്കുന്നു. Route Server BFD പോലുള്ള തകരാർ കണ്ടെത്തൽ പിന്തുണയ്ക്കുന്നു, പക്ഷേ അത് പിയറിന്റെ ജീവനക്ഷമത പരിശോധിക്കുന്നു, പിയറിന് പിന്നിലുള്ള എല്ലാറ്റിന്റെയും ആരോഗ്യമല്ല.

പ്രഖ്യാപനം യഥാർത്ഥ ദൂരസ്ഥ റൂട്ടുമായി ബന്ധിപ്പിക്കുക: ടണലും ദൂരസ്ഥ നെറ്റ്വർക്കും പ്രവർത്തിക്കുമ്പോൾ പ്രിഫിക്സ് പ്രഖ്യാപിക്കുക, ഇല്ലാത്തപ്പോൾ അത് പിൻവലിക്കുക.

ഒരു പ്രിഫിക്സ് പിൻവലിച്ച് എന്ത് സംഭവിക്കുന്നു എന്ന് നോക്കുക

ഘട്ടങ്ങളായി പരീക്ഷിക്കുക, അവസാന ഘട്ടം നീക്കം ചെയ്യലാക്കുക. പ്രഖ്യാപനം എത്തുന്നു, പ്രിഫിക്സ് ഓരോ ഉദ്ദേശിത ടേബിളിലും പ്രത്യക്ഷപ്പെടുന്നു, അപ്ലയൻസ് അടുത്ത ഹോപ്പ് ആണ്, ഫോർവേഡിംഗ് സജീവ ടണലിലൂടെ കടക്കുന്നു, ദൂരെയുള്ള അറ്റം മറുപടി നൽകുന്നു എന്ന് ഉറപ്പാക്കുക. തുടർന്ന് ഒരു പരീക്ഷണ പ്രിഫിക്സ് പിൻവലിക്കുക, അല്ലെങ്കിൽ അനുവദിച്ച ടണൽ അടയ്ക്കുക, ട്രാഫിക് രൂപകൽപ്പന പറയുന്നിടത്തേക്ക് നീങ്ങുന്നുണ്ടോ എന്ന് നിരീക്ഷിക്കുക. പരീക്ഷണം തുറന്നിരിക്കുമ്പോൾ മുൻപും ശേഷവുമുള്ള ടേബിളുകൾ രേഖപ്പെടുത്തുക.

ഒരു റൂട്ട് രണ്ടാമത്തെ അപ്ലയൻസിലേക്ക് നീക്കുന്നത് അത് വഹിച്ച സെഷനുകളെ നീക്കുന്നില്ല, കാരണം NAT, ഫയർവാൾ അവസ്ഥ ആദ്യ ഉപകരണത്തിൽ തന്നെ തുടരുന്നു.

ഒരു ഡസൻ പ്രിഫിക്സുകളുടെ സ്ഥിരമായ ഗണത്തിന്, VPC ടേബിളുകളിലെ സ്റ്റാറ്റിക് റൂട്ടുകൾ തന്നെ വിലകുറഞ്ഞ ഉത്തരമായി തുടരുന്നു. പ്രിഫിക്സ് പട്ടിക ശരിക്കും മാറുകയും പിൻവലിക്കൽ നയം ഓൺ-കോൾ ആളോട് വിശദീകരിക്കാൻ കഴിയുന്നതുമാകുമ്പോൾ Route Server അതിന്റെ സ്ഥാനം നേടുന്നു.