உங்கள் BGP அமர்வு VPC ரூட் அட்டவணையில் ஏன் தெரிவதில்லை

மீண்டும் மீண்டும் சொல்லப்படும் கதை என்னவென்றால், EC2 VPN சாதனத்தில் உள்ள ரூட்டிங் டீமன் BGP மேலே வந்ததும் VPC க்கு அதன் தொலை ப்ரிஃபிக்ஸ்களைக் கற்பிக்கும் என்பதே. அதில் பாதி உண்மை. அமர்வு மேலே வருகிறது, அதனால் VPC இன் ரூட் அட்டவணையில் எதுவும் மாறாது, எனவே முதல் அறிகுறி பொதுவாக டிராஃபிக்கை அமைதியாக ஒரு கருப்பு துளைக்குள் தள்ளும் சப்நெட் ஆகும்.

இங்கே இரண்டு வெவ்வேறு விஷயங்கள் கலக்கப்படுகின்றன: ஒரு ரூட் சர்வருடன் பியரிங், மற்றும் அட்டவணையில் ரூட்டுகளை நிறுவுவது.

கட்டுக்கதை: BGP ஐ மேலே ஏற்றுங்கள், VPC ப்ரிஃபிக்ஸ்களைக் கற்றுக்கொள்ளும்

BGP என்பது இரண்டு பேசுபவர்களுக்கு இடையிலான உரையாடல், இந்த வடிவமைப்பில் பேசுபவர்கள் உங்கள் சாதனத்தில் உள்ள ரூட்டிங் டீமனும், AWS உங்கள் சொந்த சப்நெட்டில் வைக்கும் VPC Route Server இன் முடிவுப் புள்ளியும் ஆவர். அந்த உரையாடல் ப்ரிஃபிக்ஸ்களைக் கொண்டு செல்கிறது. அது உங்கள் பணிச்சுமை சப்நெட்டுகளின் ரூட் அட்டவணையைத் தொடாது, ஏனெனில் அந்த அட்டவணைகள் ஒவ்வொன்றிலும் இயக்கப்பட வேண்டிய பரப்புதலின் மூலம் மட்டுமே கற்கின்றன. அது நடக்கும் வரை, VPC இன் துணி சாதனம் அறிந்ததைப் பற்றி எதுவும் அறியாது.

அமைப்பு படிகள் ஒரு காரணத்திற்காகப் பிரிக்கப்பட்டுள்ளன: இணைக்கவும், முடிவுப் புள்ளியை உருவாக்கவும், பியர் செய்யவும், பின்னர் பரப்புதலை இயக்கவும்.

Route Server ஒரு கட்டுப்பாட்டுத் தளம், சுரங்கப்பாதை அல்ல

Route Server ஒரு பாக்கெட்டைக்கூட என்க்ரிப்ட், ஃபார்வர்ட் அல்லது ஆய்வு செய்வதில்லை. இது சாதனத்துடன் BGP பரிமாறிக்கொண்டு, விளைந்த ப்ரிஃபிக்ஸ்களை அவற்றைப் பெற வடிவமைக்கப்பட்ட ரூட் அட்டவணைகளுக்கு வழங்குவதற்காக உள்ளது. தரவுத் தளம் மாறவில்லை: பாக்கெட்டுகள் இன்னும் சாதனத்தின் நெட்வொர்க் இடைமுகம் வழியாக வெளியேறி, அதன் VPN வழியாகப் பயணித்து அதே வழியில் திரும்புகின்றன.

இதன் பொருள் ஃபார்வர்டிங் இன்ஸ்டன்ஸில் மூலம் மற்றும் இலக்கு சரிபார்ப்பு இன்னும் முக்கியம், ஏனெனில் இன்ஸ்டன்ஸ் இப்போது வேறொருவருக்கு அனுப்பப்பட்ட டிராஃபிக்கை ஃபார்வர்ட் செய்கிறது.

பாதுகாப்புக் குழுக்கள் மற்றும் சப்நெட் கட்டுப்பாடுகள் ஃபார்வர்ட் செய்யப்பட்ட ஓட்டத்திற்கும் பொருந்தும். Route Server டிராஃபிக்கை வீசும் சாதனத்தை அதை ஃபார்வர்ட் செய்ய வலியுறுத்தாது, தொலைப் பக்கத்தில் காணாமல் போன திரும்பும் ரூட்டையும் சரிசெய்யாது.

பரப்புதல் ஒவ்வொரு ரூட் அட்டவணைக்கும், முழு VPC க்கும் அல்ல

ரூட் சர்வரை VPC உடன் இணைப்பதும் ஒரு ரூட் அட்டவணையில் பரப்புதலை இயக்குவதும் இரண்டு முடிவுகள், இரண்டாவது மட்டுமே ஒரு சப்நெட் என்ன செய்கிறது என்பதை மாற்றுகிறது. ஆறு ரூட் அட்டவணைகள் கொண்ட VPC ஒன்றில் பரப்பப்பட்ட ப்ரிஃபிக்ஸைப் பெறலாம், மற்ற ஐந்தில் பெறாமல் இருக்கலாம், இது ஹப் சப்நெட்டுக்கு சரியாகப் பொருந்தும், மேலும் «பாதி வேலை செய்கிறது» என்ற குழப்பமான முடிவை உருவாக்குவதும் இதுவே. பரப்புதல் இயக்கப்பட்டிருந்தாலும், போட்டி ரூட் வெல்லலாம், ஏனெனில் VPC இன் ரூட் தேர்வு நீளமான ப்ரிஃபிக்ஸை விரும்புகிறது, சம நீளத்தில் பரப்பப்பட்டதை விட நிலையான ரூட்டை விரும்புகிறது. அந்த முன்னுரிமை அமைதியாகப் பயன்படுத்தப்படுகிறது.

சாதனம் விளம்பரப்படுத்தும் ப்ரிஃபிக்ஸ் பட்டியலுக்குப் பதிலாக குறிப்பிட்ட சப்நெட்டின் பயனுள்ள அட்டவணையைச் சரிபார்க்கவும். API அந்தக் கேள்விக்கு நேரடியாகப் பதிலளிக்கிறது: aws ec2 associate-route-server மற்றும் aws ec2 enable-route-server-propagation --route-table-id <id> மக்கள் மறக்கும் இரண்டு படிகள், aws ec2 describe-route-tables --route-table-ids <id> ப்ரிஃபிக்ஸ் route server உள்ளீடாக வந்ததா என்பதைக் காட்டுகிறது.

சாதனம் இன்னும் ஒவ்வொரு பாக்கெட்டையும் சுமக்கிறது

அணுகலை விளம்பரப்படுத்துவது அதைக் கொண்டிருப்பதற்குச் சமமானது அல்ல. BGP அமர்வு சாதனத்தின் VPN செயலிழந்திருக்கும்போதும் நிறுவப்பட்டிருக்கலாம், ஒருபோதும் மாறாத நிலையான விளம்பரம் டிராஃபிக்கை இறந்த பாதைக்கு இழுத்துக்கொண்டே இருக்கும். Route Server BFD போன்ற தோல்வி கண்டறிதலை ஆதரிக்கிறது, ஆனால் அது பியரின் உயிர்ப்பைச் சோதிக்கிறது, பியருக்குப் பின்னால் உள்ள அனைத்தின் ஆரோக்கியத்தையல்ல.

விளம்பரத்தை உண்மையான தொலை ரூட்டுடன் இணைக்கவும்: சுரங்கப்பாதையும் தொலை நெட்வொர்க்கும் இயங்கும்போது ப்ரிஃபிக்ஸை அறிவிக்கவும், இல்லாதபோது திரும்பப் பெறவும்.

ஒரு ப்ரிஃபிக்ஸைத் திரும்பப் பெற்று என்ன நடக்கிறது என்று பாருங்கள்

கட்டங்களாகச் சோதிக்கவும், கடைசி கட்டத்தை அகற்றுதலாக்கவும். விளம்பரம் வந்து சேர்வதை, ப்ரிஃபிக்ஸ் ஒவ்வொரு நோக்கமான அட்டவணையிலும் தோன்றுவதை, சாதனம் அடுத்த ஹாப் என்பதை, ஃபார்வர்டிங் செயலில் உள்ள சுரங்கப்பாதையைக் கடப்பதை, தொலை முனை பதிலளிப்பதை உறுதிசெய்யவும். பின்னர் ஒரு சோதனை ப்ரிஃபிக்ஸைத் திரும்பப் பெறவும், அல்லது அங்கீகரிக்கப்பட்ட சுரங்கப்பாதையை மூடவும், டிராஃபிக் வடிவமைப்பு சொல்லும் இடத்திற்கு நகர்கிறதா என்று கவனிக்கவும். சோதனை திறந்திருக்கும்போதே முன் மற்றும் பின் அட்டவணைகளைப் பதிவு செய்யவும்.

ஒரு ரூட்டை இரண்டாவது சாதனத்திற்கு நகர்த்துவது அது சுமந்த அமர்வுகளை நகர்த்தாது, ஏனெனில் NAT மற்றும் ஃபயர்வால் நிலை முதல் சாதனத்திலேயே இருக்கும்.

ஒரு டஜன் ப்ரிஃபிக்ஸ்களின் நிலையான தொகுப்பிற்கு, VPC அட்டவணைகளில் உள்ள நிலையான ரூட்டுகளே மலிவான பதிலாக இருக்கும். ப்ரிஃபிக்ஸ் பட்டியல் உண்மையிலேயே மாறும்போதும், திரும்பப் பெறும் கொள்கையை ஆன்-கால் நபருக்கு விளக்க முடியும்போதும் Route Server அதன் இடத்தைப் பெறுகிறது.