AWS-നെ Site-to-Site VPN ടണൽ ആരംഭിക്കാൻ എങ്ങനെ ചെയ്യാം
Startup action-ഉം DPD timeout action-ഉം വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു. AWS ആരംഭിക്കാൻ പ്രേരിപ്പിക്കുന്നത് സജ്ജമാക്കി, തുടർന്ന് പിയർ വിലാസവും ആപ്പിന്റെ റൂട്ടും പരിശോധിക്കുക.
സ്വതവേ, AWS Site-to-Site VPN customer gateway സംഭാഷണം ആരംഭിക്കുന്നതുവരെ കാത്തിരിക്കുന്നു. ആ സ്വതവം ഒരു ക്രമീകരണമാണ്, നിയമമല്ല, ക്രമീകരണത്തിന്റെ പേര് Startup action. അതിലേക്ക് നീങ്ങുന്നതിന് മുൻപ്, എപ്പോഴും കൂടിക്കലരുന്ന രണ്ട് ചോദ്യങ്ങൾ വേർതിരിക്കുക: ടണൽ ആരാണ് സ്ഥാപിക്കുന്നത്, നിങ്ങൾക്ക് പ്രധാനമായ പാക്കറ്റുകൾക്ക് അതിലൂടെ ഒരു റൂട്ട് ഉണ്ടോ. ആദ്യത്തേത് മാത്രമാണ് ടണൽ ഓപ്ഷനുകളിൽ ഉള്ളത്.
തുടക്ക പ്രവർത്തനത്തെ DPD ടൈംഔട്ട് പ്രവർത്തനത്തിൽ നിന്ന് വേർതിരിക്കുക
ഓരോ ടണലിനും രണ്ട് ഓപ്ഷനുകൾ രണ്ട് വ്യത്യസ്ത സംഭവങ്ങളെ നിയന്ത്രിക്കുന്നു, ഒന്ന് സജ്ജമാക്കുന്നത് മറ്റൊന്നിനെപ്പറ്റി ഒന്നും പറയുന്നില്ല.
| Event | Option | Useful values |
|---|---|---|
| A new or modified VPN connection needs a tunnel | Startup action | add waits for the peer; start asks AWS to initiate |
| Dead peer detection times out | DPD timeout action | clear ends the session, restart reinitiates, none does nothing |
AWS പുതിയതോ മാറ്റിയതോ ആയ ടണൽ ഉയർത്തേണ്ടതുണ്ടെങ്കിൽ, തിരഞ്ഞെടുക്കുക start. DPD ടൈംഔട്ടിന് ശേഷം AWS സംഭാഷണം പുനരാരംഭിക്കേണ്ടതുണ്ടെങ്കിൽ, ആ സംഭവത്തിനായി പ്രത്യേകം restart കോൺഫിഗർ ചെയ്യുക. രണ്ട് ഓപ്ഷനുകളിൽ ഒന്നും ആപ്പിന്റെ വീണ്ടും ശ്രമിക്കൽ നയമല്ല, ഒന്നും കീ മാറ്റത്തിന്റെ ഇടവേളയുമല്ല: DPD പിയർ ജീവനോടെയുണ്ടോ എന്ന് പരിശോധിക്കുന്നു, അതേസമയം കീ മാറ്റം സജീവമായ ടണലിലെ security associations മാറ്റിസ്ഥാപിക്കുന്നു.
ടണൽ ഇപ്പോഴും up എന്ന് റിപ്പോർട്ട് ചെയ്യുമ്പോൾ ടൈംഔട്ട് ആകുന്ന ആപ്പിന് ഡാറ്റാ-പാതയുടെ പ്രശ്നമുണ്ട്. DPD ടൈമർ ചുരുക്കുന്നത് അത് ശരിയാക്കില്ല, പിന്നീട് വിശദീകരിക്കേണ്ട ബഹളം കൂട്ടിയേക്കാം.
AWS-ന് സംഭാഷണം അയയ്ക്കാൻ ഒരിടമുണ്ടോ എന്ന് പരിശോധിക്കുക
AWS ഭാഗത്തുനിന്നുള്ള തുടക്കം IKEv2-യിൽ മാത്രമേ സാധ്യമാകൂ, നിർദ്ദേശം എവിടെ അയയ്ക്കണമെന്ന് അറിയാൻ AWS-ന് customer gateway-യുടെ പൊതു വിലാസം വേണം. ഏറ്റവും വേദനിപ്പിക്കുന്ന സാഹചര്യം വിലാസമില്ലാതെ സൃഷ്ടിച്ച സർട്ടിഫിക്കറ്റ്-പ്രാമാണീകരിച്ച customer gateway റിസോഴ്സാണ്: വിലാസത്തോടെ പുതിയ customer gateway റിസോഴ്സ് സൃഷ്ടിച്ച്, പിന്നീട് VPN കണക്ഷൻ അതിലേക്ക് തിരിക്കുന്നത് AWS ഡോക്യുമെന്റേഷൻ വിവരിക്കുന്നു.
സർട്ടിഫിക്കറ്റ് പിയർ ആരാണെന്ന് തെളിയിക്കുന്നു. പിയർ എവിടെയാണെന്ന് അത് AWS-നോട് പറയുന്നില്ല, ഇവ രണ്ട് വ്യത്യസ്ത ആവശ്യകതകളാണ്. അതുകൊണ്ട് പരിഹാരം പുതിയ സർട്ടിഫിക്കറ്റല്ല, പുതിയ customer gateway റിസോഴ്സാണ്. സർട്ടിഫിക്കറ്റ് മാറ്റിയാലും AWS-ന് അതേ നഷ്ടമായ ലക്ഷ്യം തന്നെ അവശേഷിക്കുന്നു.
customer gateway NAT-ന്റെ പിന്നിലാണെങ്കിൽ, AWS-ന് കോൺഫിഗർ ചെയ്ത responder identity-യും വേണം, IDr, പിയറിന്റെ ഐഡന്റിറ്റി ഉപകരണം പ്രതീക്ഷിക്കുന്നതുമായി ഒത്തുപോകാൻ. നിങ്ങൾ ഇപ്പോൾ മാറ്റിയ ഓപ്ഷനെ കുറ്റപ്പെടുത്തുന്നതിന് മുൻപ് ആ മൂല്യവും IKE ട്രാഫിക് കടത്തിവിടുന്ന ഫയർവാൾ പാതയും സ്ഥിരീകരിക്കുക. start തിരഞ്ഞെടുക്കുന്നത് എത്തിപ്പെടാനാകാത്തതോ തെറ്റായി തിരിച്ചറിഞ്ഞതോ ആയ പിയറിനെ നിർദ്ദേശം സ്വീകരിക്കാൻ നിർബന്ധിക്കാൻ കഴിയില്ല.
മാറ്റം ഒരു ടണലിൽ പ്രയോഗിച്ച് തടസ്സം പ്രതീക്ഷിക്കുക
VPN കണക്ഷനിൽ സ്വതന്ത്ര ഓപ്ഷനുകളുള്ള രണ്ട് ടണലുകളുണ്ട്, അതിനാൽ പുറത്തെ വിലാസം നോക്കി ഏതാണ് എഡിറ്റ് ചെയ്യുന്നതെന്ന് സ്ഥിരീകരിക്കുക. AWS ഒരു സമയത്ത് ഒരു ടണൽ മാത്രം മാറ്റാൻ അനുവദിക്കുന്നു, തിരഞ്ഞെടുത്ത ടണലിലൂടെയുള്ള കണക്ടിവിറ്റി കുറച്ച് മിനിറ്റ് തടസ്സപ്പെടാം.
- Site-to-Site VPN കണക്ഷൻ തിരഞ്ഞെടുത്ത് Modify VPN tunnel options തുറക്കുക.
- പുറത്തെ IP വിലാസം നോക്കി ടണൽ തിരഞ്ഞെടുത്ത് അതിന്റെ IKE പതിപ്പും customer gateway റിസോഴ്സും സ്ഥിരീകരിക്കുക.
- നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ വേണ്ട തുടക്ക, DPD പ്രവർത്തനങ്ങൾ സജ്ജമാക്കി, നിങ്ങൾ നിയന്ത്രിക്കുന്ന സമയത്ത് സേവ് ചെയ്യുക.
- മാറ്റിയ ടണൽ സ്ഥാപിക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുക, അടുത്ത മാറ്റത്തിന് മുൻപ് മറ്റേ ടണലും റൂട്ടിംഗും പരിശോധിക്കുക.
അറ്റകുറ്റപ്പണിക്ക് മുൻപ് ഒരു സ്വഭാവം ശ്രദ്ധ അർഹിക്കുന്നു. AWS തുടക്കം പ്രവർത്തനക്ഷമമാക്കിയാൽ ടൈംഔട്ട് ഇല്ല: ടണൽ ഉയരുന്നതുവരെ AWS ശ്രമിച്ചുകൊണ്ടിരിക്കും, customer gateway delete-SA സന്ദേശം അയച്ചാൽ വീണ്ടും ആരംഭിക്കും. പിയർ മനഃപൂർവം ഇറക്കിയാൽ, AWS മുട്ടിക്കൊണ്ടിരിക്കും, പിയറിന്റെ ലോഗുകൾ അത് കാണിക്കും.
ടണലിന്റെ അവസ്ഥ മാത്രമല്ല, ആപ്പിന്റെ പാതയും പരിശോധിക്കുക
up എന്ന് റിപ്പോർട്ട് ചെയ്യുന്ന ടണൽ പ്രവർത്തിക്കുന്ന അഭ്യർത്ഥനയ്ക്ക് തുല്യമല്ല. VPC-യിൽ ഘടിപ്പിച്ച Lambda ഫംഗ്ഷന് ഇപ്പോഴും ഉപഭോക്താവിന്റെ പ്രിഫിക്സിലേക്കുള്ള subnet റൂട്ട്, ട്രാഫിക് അനുവദിക്കുന്ന security group, network ACL നിയമങ്ങൾ, ശരിയായ വിലാസം തിരികെ നൽകുന്ന നാമനിർണ്ണയം, കൂടാതെ ഉപഭോക്താവിന്റെ ഭാഗത്ത് തിരികെയുള്ള പാതഎന്നിവ വേണം.
ആപ്പിന്റെ സന്ദർഭത്തിൽ നിന്ന് ഒരു യഥാർത്ഥ അഭ്യർത്ഥനയോടെ ഒരിക്കൽ പരീക്ഷിക്കുക, പരാജയപ്പെട്ടാൽ flow logs വായിക്കുക. AWS തുടക്കം ഓഫ് ആയിരിക്കുകയും നിഷ്ക്രിയ ടണലിന് നിൽക്കാൻ പാക്കറ്റുകൾ ആവശ്യമാകുകയും ചെയ്യുമ്പോൾ keepalive ട്രാഫിക് സാധുവായ ഓപ്ഷനാണ്, പക്ഷേ അത് നിങ്ങൾക്ക് പേരിടാവുന്ന നിരീക്ഷണ തീരുമാനമാകണം, ഫംഗ്ഷനിൽ ബോൾട്ട് ചെയ്ത അവിശദീകരിക്കാത്ത ping ലൂപ്പല്ല.
ആദ്യം ടണൽ ആരാണ് സ്ഥാപിക്കുന്നതെന്ന് തിരഞ്ഞെടുക്കുക, തുടർന്ന് ബാക്കിയുള്ള പരാജയം അതിന്റെ സ്വന്തം പാളിയിൽ രോഗനിർണ്ണയം ചെയ്യുക. AWS തുടക്കത്തെക്കുറിച്ചുള്ള ഡോക്യുമെന്റേഷൻ കൺസോളിലെ സൂചനകളേക്കാൾ വിലാസം, ഐഡന്റിറ്റി, വീണ്ടും ശ്രമിക്കൽ ആവശ്യകതകൾ വിശദമായി പരിഗണിക്കുന്നു.