രണ്ട് ശാഖകൾക്കിടയിലുള്ള ട്രാഫിക് Azure VPN ഗേറ്റ്വേ വഴി റൂട്ട് ചെയ്യുക
ഒരു Azure VPN ഗേറ്റ്വേയിലെ രണ്ട് സൈറ്റ്-ടു-സൈറ്റ് കണക്ഷനുകൾക്ക് ശാഖകളുടെ ട്രാഫിക് കടത്തിവിടാം, പക്ഷേ രണ്ട് അറ്റങ്ങളും പ്രിഫിക്സ് പഠിക്കുകയും LAN തിരിച്ചുവരവ് പാത നിലനിൽക്കുകയും ചെയ്താൽ മാത്രം.
രണ്ട് ശാഖകൾക്ക് തമ്മിൽ നേരിട്ടുള്ള ടണൽ ഇല്ലാതെ തന്നെ Azure VPN ഗേറ്റ്വേ വഴി ട്രാഫിക് കൈമാറാം. ഓരോ ശാഖയും അതേ ഗേറ്റ്വേയിലേക്ക് സൈറ്റ്-ടു-സൈറ്റ് കണക്ഷൻ തുറക്കുന്നു, ഗേറ്റ്വേ പഠിച്ച പ്രിഫിക്സുകൾ രണ്ട് കണക്ഷനുകൾക്കിടയിൽ കൈമാറുന്നു. ഇത് പ്രവർത്തിപ്പിക്കുന്നത് രണ്ടാമത്തെ ടണലല്ല, റൂട്ട് കൈമാറ്റമാണ്: ശാഖ A ശാഖ B യുടെ പ്രിഫിക്സ് പഠിക്കണം, B ശാഖ A യുടേതും. താഴെയുള്ള പരിശോധനകൾ ക്രമത്തിൽ ചെയ്ത് ആദ്യം പരാജയപ്പെടുന്നതിൽ നിർത്തുക, കാരണം തുടർന്നുള്ള ഓരോ ഘട്ടവും അതിനെ ആശ്രയിച്ചിരിക്കുന്നു.
എന്തെങ്കിലും കോൺഫിഗർ ചെയ്യുന്നതിന് മുമ്പുള്ള മുൻവ്യവസ്ഥകൾ
ഈ ഡിസൈനിന് ഒട്ടും പ്രവർത്തിക്കാനാകുമോ എന്ന് നാല് വ്യവസ്ഥകൾ തീരുമാനിക്കുന്നു. ഗേറ്റ്വേ റൂട്ട് അടിസ്ഥാനമാക്കിയതായിരിക്കണം, BGP പിന്തുണയ്ക്കുന്ന SKU-വിൽ ആയിരിക്കണം, രണ്ട് കണക്ഷനുകളിലും BGP സജീവമായിരിക്കണം, ശാഖകളുടെ വിലാസ ഇടങ്ങൾ ഒന്നിനുമേൽ ഒന്ന് വരരുത്, ഏതെങ്കിലും വശം അതിന്റെ യഥാർത്ഥ പ്രിഫിക്സ് മറയ്ക്കാൻ NAT-നെ ആശ്രയിക്കരുത്.
ASN-കൾ ബോധപൂർവ്വം ആസൂത്രണം ചെയ്യുക. Azure-ന്റെ ഡോക്യുമെന്റഡ് ഡിഫോൾട്ട് 65515 ആണ്, ഓരോ ശാഖാ റൗട്ടർക്കും ഗേറ്റ്വേയുമായോ മറ്റേ ശാഖയുമായോ കൂട്ടിമുട്ടാത്ത സ്വന്തം സ്വകാര്യ ASN വേണം. നിലവിലുള്ള ഗേറ്റ്വേ കോൺഫിഗറേഷൻ പരിശോധിക്കാതെ ഡിഫോൾട്ട് വീണ്ടും ഉപയോഗിക്കുന്നതാണ് പിന്നീട് AS പാത നിരസിക്കപ്പെടാനുള്ള വഴി.
VNet പിയറിംഗ് സ്വഭാവം നിങ്ങൾ പ്രതീക്ഷിക്കുന്നില്ലെന്നും ഉറപ്പാക്കുക. നിങ്ങൾ കോൺഫിഗർ ചെയ്ത രണ്ട് കണക്ഷനുകൾക്കിടയിൽ ഗേറ്റ്വേ റൂട്ടുകൾ കൈമാറുന്നു; അത് ഏകപക്ഷീയമായ പിയറിംഗുകളെ ട്രാൻസിറ്റീവ് ആക്കുന്നില്ല. മൂന്നാമതൊരു നെറ്റ്വർക്ക് രണ്ട് ശാഖകളിലും എത്തണമെങ്കിൽ അതിന് സ്വന്തം കണക്ഷനോ സ്വന്തം റൂട്ട് പാതയോ വേണം, ഗേറ്റ്വേ ട്രാഫിക് വിതരണം ചെയ്യുമെന്ന ഊഹമല്ല. ആദ്യ മാറ്റ വിൻഡോയ്ക്ക് മുമ്പ് ആ അതിർത്തി എഴുതിവയ്ക്കുക, കാരണം പിന്നീട് സൈറ്റ് ചേർക്കുമ്പോൾ ആളുകൾ തിരികെ വരുന്ന ഡിസൈൻ തീരുമാനം അതാണ്.
ഈ ക്രമത്തിൽ കോൺഫിഗർ ചെയ്യുക
ഓരോ ഘട്ടത്തിനും നിരീക്ഷിക്കാവുന്ന ഫലമുണ്ട്, അതിനാൽ അത് പ്രത്യക്ഷപ്പെടുന്നതുവരെ മുന്നോട്ട് പോകരുത്.
- വെർച്വൽ നെറ്റ്വർക്ക് ഗേറ്റ്വേയിൽ BGP സജീവമാക്കി അതിന്റെ ASN-ഉം പിയർ വിലാസവും രേഖപ്പെടുത്തുക.
- ഓരോ ശാഖയ്ക്കും ആ ശാഖയുടെ യഥാർത്ഥ വിലാസ ഇടം, അതിന്റെ ASN, അതിന്റെ BGP പിയർ വിലാസം എന്നിവയോടെ പ്രാദേശിക നെറ്റ്വർക്ക് ഗേറ്റ്വേ സൃഷ്ടിക്കുക.
- ഓരോ സൈറ്റ്-ടു-സൈറ്റ് കണക്ഷനും സൃഷ്ടിച്ച് കണക്ഷനിൽ തന്നെ BGP സജീവമാക്കുക.
- ശാഖാ റൗട്ടർ, ഊഹത്തിന്റെ അടിസ്ഥാനത്തിൽ ഗേറ്റ്വേയുടെ പൊതു IKE എൻഡ്പോയിന്റുമായല്ല, Azure അനുവദിച്ച ഗേറ്റ്വേ വിലാസവുമായി പിയർ ചെയ്യാൻ കോൺഫിഗർ ചെയ്യുക.
നാലാം ഘട്ടത്തിലാണ് മിക്ക ശ്രമങ്ങളും സ്തംഭിക്കുന്നത്. Azure റിപ്പോർട്ട് ചെയ്യുന്ന BGP പിയർ വിലാസമാണ് ശാഖാ റൗട്ടർ അയൽക്കാരനായി ഉപയോഗിക്കേണ്ടത്, അത് ആളുകൾ ടണൽ ഡയഗ്രാമിൽ നിന്ന് പ്രതീക്ഷിക്കുന്ന വിലാസമായിരിക്കണമെന്നില്ല.
ശാഖയുടെ പ്രിഫിക്സ് തന്നെ പ്രഖ്യാപിക്കുക, ഉദാഹരണത്തിന് A-യിൽ നിന്ന് 10.10.0.0/16, B-യിൽ നിന്ന് 10.20.0.0/16. കാണാത്ത ഒരു നിർദ്ദിഷ്ട നെറ്റ്വർക്ക് മൂടാൻ ഡിഫോൾട്ട് റൂട്ടോ വിശാലമായ അഗ്രിഗേറ്റോ പ്രഖ്യാപിക്കരുത്; വിടവ് പിന്നീട് നിശ്ശബ്ദ കറുത്ത കുഴിയായി തിരികെ വരുന്നു.
രണ്ട് അറ്റങ്ങളിലും റൂട്ട് കൈമാറ്റം പരിശോധിക്കുക
കണക്ഷൻ നിലയല്ല പരിശോധന. രണ്ട് കണക്ഷനുകളിലും IPsec പ്രവർത്തിക്കുന്നുണ്ടാകാം, പക്ഷേ അവയ്ക്കിടയിൽ ഒരു പ്രിഫിക്സും കടന്നുപോകുന്നില്ല. ഗേറ്റ്വേയുടെ BGP പിയറുകളും പഠിച്ച റൂട്ടുകളും വായിച്ച്, മറ്റേ ശാഖയിലേക്കുള്ള റൂട്ട് ഉപയോഗയോഗ്യമായ പാതയായി കാണുന്നുവെന്ന് ഉറപ്പാക്കുക.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
BGP പട്ടികയിലുള്ള ഒരു പ്രിഫിക്സിന് സ്റ്റാറ്റിക് റൂട്ടിനോടോ കൂടുതൽ നിർദ്ദിഷ്ട പ്രിഫിക്സിനോടോ ഫോർവേഡിംഗ് തീരുമാനം നഷ്ടപ്പെടാം. സ്വീകരിച്ച റൂട്ട് മാത്രമല്ല, തിരഞ്ഞെടുത്ത റൂട്ട് പരിശോധിക്കുക.
LAN വശത്ത് തിരിച്ചുവരവ് പാത പിന്തുടരുക
Azure-ൽ ശരിയായി തോന്നുകയും സൈറ്റിൽ പരാജയപ്പെടുകയും ചെയ്യുന്ന ഭാഗമാണിത്. ശാഖ A-യിലെ ഒരു ഹോസ്റ്റ് അതിന്റെ പാക്കറ്റ് A-യുടെ VPN റൗട്ടറിലേക്ക് അയക്കുന്നത് ആ റൗട്ടർ അതിന്റെ ഡിഫോൾട്ട് ഗേറ്റ്വേ ആണെങ്കിൽ, അല്ലെങ്കിൽ ഹോസ്റ്റിനോ അതിന്റെ ഗേറ്റ്വേയ്ക്കോ B-യുടെ പ്രിഫിക്സിന് റൂട്ട് ഉണ്ടെങ്കിൽ മാത്രമാണ്. വിപരീത ദിശയിലും ഇത് ശരിയായിരിക്കണം.
ഒരു വേറിട്ട കോർ സ്വിച്ച് LAN-ന്റെ ഡിഫോൾട്ട് ഗേറ്റ്വേ ആണെങ്കിൽ, VPN റൗട്ടറിലേക്ക് ചൂണ്ടുന്ന മറ്റേ ശാഖയിലേക്കുള്ള റൂട്ട് അതിന് വേണം. അതില്ലാതെ അഭ്യർത്ഥന എത്തുന്നു, മറുപടി ഇന്റർനെറ്റ് പാതയിലൂടെ പുറത്തുപോകുന്നു, ഉപയോക്താവിന് തുറന്ന് പിന്നീട് തൂങ്ങിക്കിടക്കുന്ന ഒരു കണക്ഷൻ കാണാം.
ഇത് പരിഹരിക്കാൻ ഗേറ്റ്വേ സബ്നെറ്റിലെ നെറ്റ്വർക്ക് സെക്യൂരിറ്റി ഗ്രൂപ്പിലേക്ക് പോകരുത്. ആ സബ്നെറ്റിന് സ്വന്തം ആവശ്യകതകളുണ്ട്, അവിടെയുള്ള NSG ശാഖാ വശത്തെ നയത്തിന്റെ പിന്തുണയുള്ള പകരമല്ല. ഫിൽട്ടറിംഗ് ശാഖകളുടെ ഫയർവാളുകളിലും ജോലിഭാരങ്ങളിലും തന്നെ ആയിരിക്കണം, അവിടെ ഉടമകൾക്ക് നിയമങ്ങൾ അവലോകനം ചെയ്യാം. ആ നിയമങ്ങൾ സബ്നെറ്റ് NSG-യിലേക്ക് മാറ്റുന്നത് അടുത്ത തകരാർ ഡീബഗ് ചെയ്യുന്ന ടീമിൽ നിന്നും അവ മറയ്ക്കുന്നു.
പ്രവർത്തനം അനുവദിക്കുക, പിന്നീട് നിരസിച്ച പരിശോധനയിലൂടെ തെളിയിക്കുക
പഠിച്ച റൂട്ട് അനുമതിയല്ല. നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ ആവശ്യമുള്ള ഉറവിടം, ലക്ഷ്യം, സേവനം എന്നിവ ശാഖകളുടെ ഫയർവാളുകളിലൂടെയും എൻഡ്പോയിന്റ് നയത്തിലൂടെയും അനുവദിക്കുക, ബാക്കി നിരസിച്ചതായി വയ്ക്കുക.
ശാഖ A-യിലെ സാധാരണ ജോലിഭാരത്തിൽ നിന്ന് ശാഖ B-യിലെ യഥാർത്ഥ സേവനത്തിലേക്ക് പരിശോധിക്കുക, മറുപടി ഉറപ്പാക്കുക, പിന്നീട് നിരോധിതമായി തുടരേണ്ട ഒരു പ്രവർത്തനം ശ്രമിക്കുക. VPN ഉപകരണം തന്നെ സൃഷ്ടിക്കുന്ന ട്രാഫിക് വേറെ ഉറവിട വിലാസം ഉപയോഗിച്ച് LAN റൂട്ടിംഗ് ഘട്ടം ഒഴിവാക്കാം, അതിനാൽ റൗട്ടറിൽ നിന്നുള്ള വിജയകരമായ ping കാണുന്നതിനേക്കാൾ കുറവ് തെളിയിക്കുന്നു.
നാല് വസ്തുതകൾ എഴുതി അവസാനിപ്പിക്കുക: കൈമാറിയ പ്രിഫിക്സുകൾ, ഉപയോഗിക്കുന്ന ASN-കൾ, ഓരോ വശത്തിന്റെയും LAN തിരിച്ചുവരവ് പാത, സേവനം അനുവദിക്കുന്ന നയം. ഇവയിൽ ഒന്ന് കാണാതായാൽ സജ്ജീകരണം ആദ്യ മാറ്റം വരെ പ്രവർത്തിക്കും, പിന്നീട് ആർക്കും കാരണം വിശദീകരിക്കാനാകില്ല.