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 தொடக்கம் பற்றிய ஆவணங்கள் கன்சோல் குறிப்புகளை விட முகவரி, அடையாளம் மற்றும் மறுமுயற்சி தேவைகளை விரிவாக உள்ளடக்குகின்றன.