AWS-ൽ നിന്ന് Azure-ലേക്ക് സൈറ്റ് VPN: ആദ്യം മടക്കപ്പാത എഴുതുക
രണ്ട് ക്ലൗഡുകൾക്കിടയിലുള്ള ബന്ധിപ്പിച്ച ടണൽ, ഓരോ വർക്ക്ലോഡ് സബ്നെറ്റും ദൂരെയുള്ള പ്രിഫിക്സിലേക്ക് റൂട്ട് ചെയ്യുന്നതുവരെ ഒന്നും തെളിയിക്കുന്നില്ല. പ്ലാൻ ക്രമത്തിൽ ചെയ്ത്, പിന്നീട് സേവനം പരിശോധിക്കുക.
ടണൽ ഉയരും. സാധാരണ അങ്ങനെയാണ് സംഭവിക്കുന്നത്, കാരണം IKE-ക്ക് യോജിക്കുന്ന നിർദ്ദേശങ്ങളും എത്തിച്ചേരാവുന്ന പിയർ വിലാസവും മാത്രം മതി. അതിനുശേഷം പരാജയപ്പെടുന്നത് മടക്കപ്പാതയാണ്: AWS വർക്ക്ലോഡ് പാക്കറ്റുകൾ ടണലിലേക്ക് അയയ്ക്കുന്നു, പക്ഷേ Azure വശത്ത് 10.10.0.0/16-ന് എങ്ങനെ ഉത്തരം നൽകണമെന്ന് ആർക്കും അറിയില്ല, അല്ലെങ്കിൽ Azure റൂട്ട് വർക്ക്ലോഡ് സബ്നെറ്റ് ഉപയോഗിക്കാത്ത പട്ടികയിലാണ്. ഏതെങ്കിലും കൺസോൾ തൊടുന്നതിന് മുമ്പ് റൂട്ട് പ്ലാൻ എഴുതുക, ടണൽ ജോലിയിലെ ഏറ്റവും കുറഞ്ഞ താൽപ്പര്യമുള്ള ഭാഗമാകും.
ഘട്ടം 1: വിലാസ പ്ലാൻ ഉറപ്പിക്കുക
കൃത്യമായ മൂല്യങ്ങളോടെ പ്രവർത്തിക്കുക. AWS വർക്ക്ലോഡ് 10.10.0.0/16-നുള്ളിൽ 10.10.1.20-ൽ ആണ്, 10.20.0.0/16-നുള്ളിൽ 10.20.1.30-ൽ ഉള്ള Azure സേവനത്തിലേക്ക് TCP 443 വേണം. രണ്ട് ശ്രേണികളും ഒന്നിനുമേൽ ഒന്ന് വരരുത്, സ്വീകാര്യതാ പരീക്ഷ സേവന ജോടിയാണ്, ടണൽ അല്ല.
മറ്റെന്തിനേക്കാളും മുമ്പ് ആ നാല് വസ്തുതകൾ എഴുതുക, കാരണം തുടർന്നുള്ള ഓരോ ഘട്ടവും അവയ്ക്കെതിരെ പരിശോധിക്കപ്പെടുന്നു.
ഘട്ടം 2: ഓരോ അറ്റത്തിന്റെയും ഉടമയായ ഗേറ്റ്വേ പേരിടുക
AWS Site-to-Site VPN വിർച്വൽ പ്രൈവറ്റ് ഗേറ്റ്വേയിലോ ട്രാൻസിറ്റ് ഗേറ്റ്വേയിലോ അവസാനിക്കാം, ഇവ വ്യത്യസ്ത റൂട്ടിംഗ് ഉടമകളാണ്. Azure അതിന്റെ മാനേജ്ഡ് VPN Gateway-ഉം, വേറെയായി ഉപഭോക്താക്കൾ സ്വയം നടത്തുന്ന VM അടിസ്ഥാനമാക്കിയ ഉപകരണങ്ങളും നൽകുന്നു. നിങ്ങൾക്ക് ഏത് ജോടിയാണെന്ന് രേഖപ്പെടുത്തുക, കാരണം ഓരോ സംയോജനത്തിലും അടുത്ത ഹോപ്പ് വ്യത്യസ്തമാണ്.
മാനേജ്ഡ് ഗേറ്റ്വേയ്ക്ക്, ഊഹിച്ച സ്വകാര്യ ഉപകരണ വിലാസത്തിലേക്ക് ചൂണ്ടുന്ന റൂട്ട് പകർത്തരുത്. ഉപകരണത്തിന്, ക്ലൗഡ് റൂട്ട് പ്രചരണം ഗസ്റ്റ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ക്രമീകരിക്കുന്നു എന്ന് കരുതരുത്, കാരണം അത് അങ്ങനെ ചെയ്യുന്നില്ല.
ഇവിടെ തെറ്റ് വരുത്തിയാൽ പൂർണ്ണമായി തോന്നുന്ന ഒരു പ്ലാൻ ഉണ്ടാകും, ഒരിക്കലും ഉത്തരം നൽകാത്ത വിലാസത്തിലേക്ക് പാക്കറ്റുകൾ അയയ്ക്കും.
ഘട്ടം 3: ഓരോ വർക്ക്ലോഡും യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന റൂട്ട് എഴുതുക
താഴെയുള്ള ഓരോ അതിരും വെവ്വേറെ തിരച്ചിലാണ്, അവയിലൊന്നിലുള്ള റൂട്ട് പാക്കറ്റിനുള്ള റൂട്ടല്ല. ടണൽ പ്രവർത്തനക്ഷമമാകുന്നതിന് മുമ്പ് പട്ടിക നിങ്ങളുടെ മൂല്യങ്ങൾ കൊണ്ട് നിറയ്ക്കുക.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
AWS-ൽ, BGP അല്ലെങ്കിൽ ടണൽ ആരോഗ്യകരമായതിന് ശേഷവും വർക്ക്ലോഡ് സബ്നെറ്റിന്റെ റൂട്ട് പട്ടിക നിങ്ങൾ തന്നെ അപ്ഡേറ്റ് ചെയ്യണം; റൂട്ടിംഗ് അവലോകനം അതിനെ കണക്ഷന്റെ ഭാഗമായി കണക്കാക്കുന്നു. Azure-ൽ, ഉപയോക്താവ് നിർവചിച്ച റൂട്ട് പട്ടിക വിർച്വൽ നെറ്റ്വർക്കിനല്ല, സബ്നെറ്റിനോട് ബന്ധപ്പെടുന്നു, അതിനാൽ ഫലപ്രദമായ റൂട്ട് VNet ബ്ലേഡിൽ അല്ല, വർക്ക്ലോഡ് NIC-യിൽ പരിശോധിക്കുക.
മാനേജ്ഡ് Azure ഗേറ്റ്വേ ഗേറ്റ്വേ പ്രചരണത്തിലൂടെ ദൂരെയുള്ള പ്രിഫിക്സ് പഠിക്കാം, UDR ആ തീരുമാനം റദ്ദാക്കാം. കാരണമുണ്ടെങ്കിൽ UDR ചേർക്കുക, ശീലത്താൽ അല്ല. ചേർത്താൽ, ഉപകരണ വിലാസം കെട്ടിച്ചമയ്ക്കുന്നതിന് പകരം ഗേറ്റ്വേ VPN പാതയ്ക്കായി പ്രസിദ്ധീകരിക്കുന്ന അടുത്ത ഹോപ്പിലേക്ക് നയിക്കുക. പിന്നീട് NIC-യിലെ ഫലപ്രദമായ റൂട്ടുകൾ വീണ്ടും വായിക്കുക, കാരണം തീരുമാനം യഥാർത്ഥത്തിൽ അവിടെയാണ് എടുക്കുന്നത്.
ഘട്ടം 4: പരിധി ഒത്തുചേർക്കുക
BGP-യ്ക്ക്, ഓരോ വശവും പ്രഖ്യാപിക്കുന്നതിനെ മറുവശം യഥാർത്ഥത്തിൽ പഠിച്ചതുമായി പ്രിഫിക്സ് തോറും താരതമ്യം ചെയ്യുക. സ്റ്റാറ്റിക് റൂട്ടിംഗിന്, ക്രമീകരിച്ച ദൂരെയുള്ള ശ്രേണികളെ ഘട്ടം 3-ൽ എഴുതിയ വർക്ക്ലോഡ് റൂട്ടുകളുമായി താരതമ്യം ചെയ്യുക.
ക്രിപ്റ്റോഗ്രഫിയിൽ യോജിച്ച IKE ബന്ധം ഏതെങ്കിലും വശം 10.10.0.0/16 അല്ലെങ്കിൽ 10.20.0.0/16 പഠിച്ചു എന്നതിന് തെളിവല്ല. നിങ്ങൾ ആസൂത്രണം ചെയ്ത /16-ന് പകരം ഒരു /24 മാത്രം പ്രഖ്യാപിച്ചുകൊണ്ട് രണ്ട് ടണലുകൾ ഉയർന്നിരിക്കാം. പ്രിഫിക്സ് ടണൽ നിലയിൽ അല്ല, റൂട്ടിംഗ് പട്ടികയിൽ പരിശോധിക്കുക. പൊരുത്തക്കേട് പിന്നീട് പ്രവർത്തിക്കുന്ന ഒരു സബ്നെറ്റും ഒരിക്കലും ഉത്തരം നൽകാത്ത മറ്റൊന്നുമായി പ്രത്യക്ഷപ്പെടുന്നു.
ഘട്ടം 5: യഥാർത്ഥ ഉറവിടത്തിൽ നിന്ന് സേവനം പരിശോധിക്കുക
AWS സെക്യൂരിറ്റി ഗ്രൂപ്പുകളിലും നെറ്റ്വർക്ക് ACL-കളിലും, Azure NSG-കളിലും, പാതയിലെ ഏതെങ്കിലും ഉപകരണ ഫിൽട്ടറിലും ഉദ്ദേശിച്ച ഫ്ലോ അനുവദിക്കുക. തുടർന്ന് 10.10.1.20-ൽ നിന്ന് അംഗീകരിച്ച സേവന വിലാസത്തിലേക്കും പോർട്ടിലേക്കും ഒരു കണക്ഷൻ തുറന്ന്, മറുപടി അതേ ഉറവിടത്തിലേക്ക് തിരികെ വരുന്നുവെന്ന് ഉറപ്പാക്കുക.
ക്ലൗഡ് സെക്യൂരിറ്റി ഗ്രൂപ്പുകളും NSG-കളും stateful ആണ്, അതിനാൽ നിരസിക്കപ്പെട്ട മടക്ക പാക്കറ്റ് റൂട്ടിംഗിന്റെ ലക്ഷണമാണ്, എതിർദിശയിൽ എഴുതാൻ മറന്ന നിയമമല്ല.
ഏതെങ്കിലും ഗേറ്റ്വേയിൽ നിന്നുള്ള ping ഒന്നും തീരുമാനിക്കുന്നില്ല. ഗേറ്റ്വേ വിലാസത്തിലേക്കുള്ള ICMP കൺട്രോൾ പ്ലെയിൻ പാത പരിശീലിപ്പിക്കുന്നു, വർക്ക്ലോഡിന് വേണ്ട ഫോർവേഡ് ചെയ്ത TCP സേവനമല്ല.
റോൾബാക്കും രേഖകളും
ടണൽ ഐഡന്റിഫയറുകൾക്ക് അരികിൽ റൂട്ട് ഉടമകളെ രേഖപ്പെടുത്തി, മാറ്റത്തിന് മുമ്പുള്ള റൂട്ട് പട്ടികകൾ സൂക്ഷിക്കുക. മാറ്റം ഒഴിവാക്കേണ്ടി വന്നാൽ, ടണൽ പൊളിക്കുന്നതിന് മുമ്പ് വർക്ക്ലോഡ് റൂട്ടുകൾ നീക്കം ചെയ്യുക, ഇനി ഇല്ലാത്ത അടുത്ത ഹോപ്പിലേക്ക് ഏതെങ്കിലും സബ്നെറ്റ് ചൂണ്ടാതിരിക്കാൻ.
അപ്പോൾ പിന്നീടുള്ള സബ്നെറ്റ് മാറ്റത്തിനോ spoke ബന്ധിപ്പിക്കലിനോ അപ്ഡേറ്റ് ചെയ്യാൻ ഒരു നിശ്ചിത സ്ഥലമുണ്ടാകും, ഒരിക്കലും സ്വന്തമല്ലാത്ത ഒരു റൂട്ടിന്റെ കുറ്റം ചുമക്കുന്ന പ്രവർത്തിക്കുന്ന ടണലിന് പകരം.