peered VPC ஐ அடைய AWS Client VPN அல்லது bastion
இரு பாதைகளும் செயல்படும், ஆனால் வெவ்வேறு இடங்களில் உடையும். endpoint பாதைகள், திரும்பு வழிமாற்றம் மற்றும் bastion நேர்மையான எல்லையாகும் மூன்று நிலைகளை ஒப்பிடுங்கள்.
ஒரு Client VPN endpoint அதன் இணைக்கப்பட்ட VPC உடன் peered ஆக உள்ள VPC ஐ அடைய முடியும், அதை சட்டபூர்வமாக்க bastion தேவையில்லை. செய்யத் தகுந்த தேர்வு போக்குவரத்து எங்கு கை மாறுகிறது என்பதுதான்: association சப்னெட்டில் இறங்கி peering இணைப்பைக் கடக்கும் endpoint பாதை, அல்லது peered VPC இல் அமர்வை முடிக்கும் host. இரு பாதைகளும் செயல்படும், வெவ்வேறு இடங்களில் தோல்வியடையும், எனவே முடிவு உரிமை மற்றும் தணிக்கை பற்றியது, AWS எதை அனுமதிக்கிறது என்பது பற்றியது அல்ல. அவற்றுக்கிடையே நான் எப்படித் தேர்வு செய்கிறேன், routed பாதையை செயல்படுத்தும் நான்கு உள்ளீடுகள் இங்கே.
இரு பாதை, ஒரு endpoint, வெவ்வேறு உரிமையாளர்கள்
routed பாதையில் வாடிக்கையாளர் போக்குவரத்து endpoint ஐ அடைகிறது, association சப்னெட்டில் உள்ள Client VPN நெட்வொர்க் இடைமுகத்தின் முகவரியாக மாற்றப்படுகிறது, A முதல் B வரையிலான peering இணைப்பின் வழியாக அந்த சப்னெட்டை விட்டு வெளியேறுகிறது. VPC B எந்த VPN அமர்வையும் முடிக்கவில்லை; VPC A இலிருந்து சாதாரண போக்குவரத்தைப் பார்க்கிறது, அதனால் அதன் திரும்பு பாதை வாடிக்கையாளர் குளத்திற்கு அல்ல, VPC A க்கு சுட்டுகிறது.
bastion பாதையில் வாடிக்கையாளர் முதலில் host ஐ அடைகிறார். A வில் உள்ள bastion கடைசி தாவலை இன்னும் peering இணைப்பின் வழியாக கடக்க அனுமதிக்கிறது, எனவே peering வேலை தங்கி ஒரு அமர்வு சேர்கிறது. B வில் உள்ள bastion க்கும் வாடிக்கையாளரிடமிருந்து பாதை தேவை, அந்த பாதை அதே endpoint பாதையாக இருந்தால், routed வடிவமைப்புடன் ஒரு தாவல் கூடுகிறது. bastion வேலையைக் குறைப்பது அது ஏற்கனவே இருந்தால், ஏற்கனவே அனுமதிக்கப்பட்டிருந்தால், அதன் பின்னால் உள்ளவைக்கு நெட்வொர்க் எல்லைக்குப் பதிலாக அமர்வு எல்லை தேவைப்பட்டால் மட்டுமே.
நான்கு உள்ளீடுகள் routed பாதையை செயல்படுத்துகின்றன
AWS இந்த சூழ்நிலையை Client VPN how-it-works பக்கத்தில் ஆவணப்படுத்துகிறது, நடைமுறையில் இரண்டு அல்லது மூன்று குழுக்களுக்குச் சொந்தமான நான்கு உள்ளீடுகளாக வருகிறது. வரம்புகள் எடுத்துக்காட்டுக்கானவை; peered வரம்பு தனித்துவமாக இருக்க வேண்டும், திரும்பு வரம்பு உங்கள் திட்டத்துடன் பொருந்த வேண்டும்.
| Control | What it must say |
|---|---|
| Endpoint route | 10.70.0.0/16 targets the association subnet |
| Authorization rule | The approved group may reach 10.70.0.0/16 |
| VPC A association-subnet table | 10.70.0.0/16 targets the peering connection |
| VPC B resource-subnet table | VPC A's range targets the same peering connection |
பாதையும் அனுமதியும் தனித்தனி கட்டுப்பாடுகள். பொருந்தும் அங்கீகார விதி இல்லாத சரியான endpoint பாதை வாடிக்கையாளருக்கு எதையும் தராது; endpoint வழிமாற்ற முடியாத இலக்குக்கான அங்கீகார விதி அவருக்கு கருந்துளை தருகிறது. இரண்டும் ஒரே வரம்பைக் குறிப்பிட வேண்டும்.
endpoint பாதை endpoint இன் சொந்த VPC இல் உள்ள சப்னெட்டைச் சுட்டுகிறது, ஒருபோதும் peering இணைப்பை அல்ல. VPC பாதை அட்டவணைகள் peering இணைப்பைச் சுட்டுகின்றன, ஒருபோதும் instance அல்லது இடைமுகத்தை அல்ல. இரண்டிற்கும் இடையே மதிப்பை நகலெடுப்பது புகார் இல்லாமல் சேமிக்கப்படும், எதையும் வழிமாற்றாது.
association சப்னெட் வாடிக்கையாளர் மூலத்தை மொழிபெயர்ப்பதால், B வாடிக்கையாளர் குளத்திற்கு அல்ல, VPC A க்குத் திரும்பி வழிமாற்ற வேண்டும். peering இணைப்பின் மேல் வாடிக்கையாளர் வரம்பை அனுப்புவது சமச்சீராகத் தெரிகிறது, மதிப்பாய்வைக் கடக்கிறது, வாடிக்கையாளர் மூலத்துடன் கூடிய பாக்கெட்டை B ஒருபோதும் பார்ப்பதில்லை என்பதால் அமைதியாகத் தோல்வியடைகிறது.
பாதுகாப்புக் குழுக்கள் மற்றும் அனுமதியின் கடைசி மீட்டர்
வழிமாற்றம் பாக்கெட்டுகளை B க்கு கொண்டு வருகிறது; முடிவை B இன்னும் எடுக்கிறது. ஒரே பிராந்தியத்தில் செயலில் உள்ள peering இணைப்புக்கு, B இல் உள்ள பாதுகாப்புக் குழு Client VPN association இல் பயன்படுத்தப்பட்ட குழுவைக் குறிப்பிடலாம், இது விதியைக் குறுகலாக வைத்து முகவரி மாற்றங்களைத் தாங்குகிறது. குழு குறிப்பு சாத்தியமில்லாத இடத்தில், 0.0.0.0/0 வரை விரிவாக்குவதற்குப் பதிலாக association சப்னெட் வரம்பை வெளிப்படையாக அனுமதிக்கவும், ஏனெனில் அது வழிமாற்றப் பிழையை விளக்கமற்ற டைம்அவுட்டாக மாற்றுகிறது.
பின்னர் வழிமாற்றம் ஒருபோதும் தொடாததைச் சரிபார்க்கவும்: இரு சப்னெட்டுகளிலும் நெட்வொர்க் ACL, பயன்பாட்டின் allow-list அல்லது டோக்கன் பார்வையாளர்கள், மற்றும் DNS. peering தனிப்பட்ட ஹோஸ்ட் செய்யப்பட்ட மண்டலங்களை நகலெடுப்பதில்லை, எனவே மடிக்கணினி தீர்க்க முடியாத முகவரிக்கு வேலை செய்யும் பாதையை வைத்திருக்கலாம், peering இணைப்பு சான்றிதழுக்கு நம்பிக்கையைச் சேர்ப்பதில்லை. endpoint ஐ B க்கு பதிலளிக்கும் resolver க்கு சுட்டி, பின்னர் தனிப்பட்ட பெயரும் சான்றிதழும் பொருந்துகின்றன என்பதை உறுதிப்படுத்தவும்.
bastion நேர்மையான பதிலாகும் போது
வேண்டுமென்றே bastion தேர்ந்தெடுக்க மூன்று தூண்டுதல்களை வைத்திருக்கிறேன். peered VPC உங்கள் வரம்பிற்கு திரும்பு பாதையைச் சேர்க்காத அல்லது குழு குறிப்பை ஏற்காத குழுவின் உடைமை. அணுகல் ஒவ்வொரு அமர்விற்கும் அனுமதிக்கப்பட வேண்டும் அல்லது பதிவு செய்யப்பட வேண்டும், பயன்பாடு அதைத் தானே சுமக்க முடியாது. அல்லது கடைசி தாவல் B க்குள்ளேயே இருக்க வேண்டும், ஏனெனில் சேவை அங்கு மட்டுமே தீர்க்கப்படுகிறது, அதன் TLS அடையாளம் உள் பெயரில் பின் செய்யப்பட்டுள்ளது.
இவை எதுவும் peering டிரான்சிட்டிவ் அல்ல என்பதைச் சுற்றிவளைப்பதல்ல. டிரான்சிட்டிவ் அல்லாத தன்மை B இல் உள்ள வளங்கள் என்ன செய்யலாம் என்பதைக் கட்டுப்படுத்துகிறது: A உடன் peered ஆக உள்ள மூன்றாவது VPC க்கு A வை டிரான்சிட்டாகப் பயன்படுத்த முடியாது. VPN பயனர் நேரடியாக peered VPC ஐ அடைய முடியாது என்று அது ஒருபோதும் பொருள் கொள்ளவில்லை, அந்தத் தவறான வாசிப்பைத் தவிர்க்கக் கட்டப்பட்ட bastion காரணமின்றி patch செய்யப்படும் host ஆகும்.
எதிர் தவறு காலப்போக்கில் அதிக விலை கொடுக்கிறது: ஒவ்வொரு குழுவையும் ஏற்கனவே உள்ள ஒரே bastion வழியாகச் செலுத்தி, பின்னர் அதன் பாதுகாப்புக் குழு, பாதை அட்டவணை மற்றும் patch சாளரம் உற்பத்தி சார்பு என்பதைக் கண்டறியவும். host எந்தத் தூண்டுதலுக்கு சேவை செய்கிறது என்பதை எழுதி, தூண்டுதல் போனதும் அதை ஓய்வு பெறச் செய்யவும்.
Transit Gateway மற்றும் பல association கணக்கை மாற்றுகின்றன
endpoint சப்னெட்டிற்குப் பதிலாக நேரடியாக Transit Gateway உடன் இணைக்கப்பட்டிருந்தால், மாதிரி மாறுகிறது: வாடிக்கையாளர்கள் இனி association சப்னெட்டில் இடைமுக முகவரியாக மாற்றப்படுவதில்லை, gateway பாதை அட்டவணைகள் வாடிக்கையாளர் வரம்பையும் peered VPC க்கு இட்டுச் செல்லும் இணைப்பையும் சுமக்க வேண்டும். இது அளவில் சுத்தமானது, ஆனால் வேலை நான்கு உள்ளீடுகளிலிருந்து gateway பாதை அட்டவணைகளுக்கு நகர்கிறது.
பல association சரிபார்ப்புகளைப் பெருக்குகின்றன. endpoint பாதை endpoint இன் உடைமை, இருப்பினும் ஒவ்வொரு association சப்னெட்டிற்கும் உண்மையான peering அடுத்த தாவலுடன் பாதை அட்டவணை தேவை. ஒரு association வழியாக அமர்வு வெற்றி பெறலாம், மற்றொன்றுக்கு திரும்பு பாதை இல்லாமல் இருக்கலாம், எனவே ஒவ்வொன்றையும் சோதிக்கவும்.
உடைவை விரைவாகக் கண்டறியும் சரிபார்ப்பு வரிசை
இவற்றை வரிசையாக இயக்கவும்; ஒவ்வொரு படியும் அடுத்தது தோல்வியடையும்போது கூட கடக்கலாம், வாடிக்கையாளர் டைம்அவுட் எது உடைந்தது என்பதைக் கிட்டத்தட்ட ஒருபோதும் சொல்வதில்லை.
- வாடிக்கையாளரிடமிருந்து பயன்பாட்டின் பெயரைத் தீர்த்து, முகவரி peered வரம்பிற்குள் உள்ளதா எனச் சரிபார்க்கவும்.
- இணைக்கவும், பின்னர் அமர்வை முடித்த association க்கான endpoint இணைப்பு பதிவைப் படிக்கவும்.
- அந்த association சப்னெட்டில், பாதை அட்டவணை peered வரம்பை செயலில் உள்ள peering இணைப்புக்குச் சுட்டுகிறது என்பதை உறுதிப்படுத்தவும்.
- B இல் உள்ள வள சப்னெட்டில், இடைமுக வரம்பிற்கான திரும்பு உள்ளீடு மற்றும் பொருந்தும் குழு விதிகளை உறுதிப்படுத்தவும்.
- அனுமதிக்கப்பட்ட ஒரு செயல்பாட்டையும் அடைய முடியாததாக இருக்க வேண்டிய ஒரு வளத்தையும் சோதிக்கவும்; இரண்டாவது பிழைத்திருத்த எச்சங்களைப் பிடிக்கிறது.
- split-tunnel பாதை மாற்றத்திற்குப் பிறகு மீண்டும் இணைக்கவும், ஏனெனில் இயங்கும் சுரங்கப்பாதை புதிய பாதை தொகுப்பை எடுக்காது.
நினைவில் வைக்கத் தகுந்த இரண்டு அறிகுறிகள் உள்ளன. பதிலின்றி B ஐ அடையும் SYN கிட்டத்தட்ட எப்போதும் காணாமல் போன திரும்பு பாதை. முடிந்து பின்னர் மீட்டமைக்கப்படும் இணைப்பு பொதுவாக குழு, ACL அல்லது பயன்பாடு. இரண்டும் endpoint பதிவில் காரணமாகத் தெரிவதில்லை, எனவே நான்கு உள்ளீடுகளையும் ஒவ்வொன்றின் அருகிலும் உரிமையாளருடன் வைத்திருங்கள்.
மூன்று தூண்டுதல்களில் எதுவும் பொருந்தவில்லை என்றால், routed பாதையை முடித்து அந்த நான்கு உள்ளீடுகளைப் பதிவு செய்யவும். ஒன்று பொருந்தினால், bastion ஐ அந்த எல்லைக்கு மட்டும் வைத்து, முன்னால் அமர்வு தேவைப்படாத சேவைகளுக்கு endpoint பாதையை விட்டுவிடவும்.