VPN மீது BGP உங்கள் அடுக்கு பாதையை ஏன் கட்டுப்படுத்தவில்லை
VPN மீது BGP அணுகல் திறனை பரிமாற்றி பாதைக் கொள்கையை பயன்படுத்துகிறது, ஆனால் அடுக்கு இன்னும் வெளிப்பாதையைத் தேர்ந்தெடுக்கிறது. அமர்வு உண்மையில் கட்டுப்படுத்துவது என்ன.
இரு தளங்கள் IPsec சுரங்கப்பாதை வழியாக BGP சக-இணைப்பு செய்கின்றன, ஒன்றின் முன்னொட்டுகளை மற்றொன்று கற்கின்றன, வரைபடம் பாதைக் கட்டுப்பாடு என மறுபெயரிடப்படுகிறது. அந்த அடையாளமே குழப்பத்தின் தொடக்கம். அமர்வு அணுகல் திறனை பரிமாற்றுகிறது, கொள்கையையும் பயன்படுத்துகிறது, ஆனால் எந்த வழங்குநர், கம்பி அல்லது திசைவி மறையாக்கப்பட்ட பொதிகளை எடுத்துச் செல்கிறது என்பதில் அதற்குச் சொல்ல எதுவும் இல்லை. வேலை செய்யும் சுரங்கப்பாதையை ஒரு குழு மீண்டும் கட்டியதை நான் பார்த்திருக்கிறேன், ஏனெனில் BGP பாதை மாற்றம் அமர்வு ஒருபோதும் பாதிக்க முடியாத மற்றொரு இழை பாதைக்கு போக்குவரத்தை நகர்த்தும் என்று அவர்கள் எதிர்பார்த்தனர்.
மக்கள் ஒரு அமர்வு என்ன வாங்குகிறது என்று நினைக்கிறார்கள்
எதிர்பார்ப்பின் பெரும்பகுதி ஆய்வகத்தில் பாதை மாற்றம் எப்படி இருக்கிறது என்பதிலிருந்து வருகிறது. நீங்கள் சுரங்கப்பாதை வழியாக முன்னொட்டை அறிவிக்கிறீர்கள், தொலைப்பக்கம் அதை நிறுவுகிறது, போக்குவரத்து நகர்கிறது. அதே வரிசை உண்மையிலேயே போக்குவரத்து பொறியியல் கட்டுப்பாடுகள் உள்ள திசைவியிலும் நடக்கிறது, எனவே இரண்டும் குழப்பப்படுகின்றன. ஆய்வகத்தில் இரு தளங்களும் பொதுவாக ஒரே அணுகல் இணைப்பைப் பகிர்கின்றன, அதனால்தான் வித்தியாசம் அங்கு ஒருபோதும் தெரிவதில்லை.
BGP ஒரு அணுகல் திறன் நெறிமுறை. ஒரு முன்னொட்டுக்கு பொதிகளை வழங்க முடியும் என்று அது சக-இணைப்பாளரிடம் சொல்கிறது, பெறும் சலுகைகளை ஒவ்வொரு பக்கமும் வரிசைப்படுத்த அனுமதிக்கிறது. சுரங்கப்பாதை வழியாக இது உண்மையில் பயனுள்ளது: தளங்கள் வரும்போதும் போகும்போதும் முன்னொட்டுகள் தோன்றி மறைகின்றன, ஒவ்வொரு விளிம்பு சாதனத்திலும் நிலையான பாதையை எழுதாமல் ஒரு வரம்பை நிராகரிக்கலாம். அது செய்யாதது வழங்குநரின் திசைவிகளை உங்கள் கட்டுப்பாட்டுக்குள் கொண்டு வருவதுதான்.
அடுக்கு வெளிப்புற தலைப்பைச் சுமக்கிறது. உங்கள் சுரங்கப்பாதை முனை மறையாக்கப்பட்ட பொதிகளை சக-இணைப்பாளர் முகவரிக்கு அனுப்புகிறது, அந்த இரு முகவரிகளுக்கிடையிலான வலைப்பின்னல் அவற்றை அதன் இயக்குநர்கள் நிறுவிய பாதைகள் வழியாக அனுப்புகிறது. BGP அமர்வில் எதுவும் அந்த முடிவை மாற்றாது, அதே வழங்குநர் அதைச் செய்யும் ஆதரவு சேவையை வழங்காத வரை.
அமர்வு உண்மையில் சுமப்பது என்ன
BGP பேச்சாளர் தன் சக-இணைப்பாளரின் 179 துறைமுகத்திற்கு TCP இணைப்பைத் திறக்கிறார், RFC 4271 இல் வரையறுக்கப்பட்ட செய்தி வடிவங்களையும் பாதை பண்புகளையும் பயன்படுத்தி. சக-இணைப்பாளர் முகவரி சுரங்கப்பாதைக்குள் இருக்கும்போது, அமர்வு தொடங்கும் முன் சுரங்கப்பாதை மேலே இருக்க வேண்டும், அந்த முகவரி அணுகக்கூடியதாக இருக்க வேண்டும். முடிந்த IKE பரிமாற்றம் BGP அண்டை அல்ல. பாதை அடிப்படையிலான IPsec செயலாக்கங்கள் பொருந்தும் சுரங்கப்பாதை பாதை இருக்கும்போது மட்டுமே போக்குவரத்தை அனுமதிக்கின்றன, கொள்கை அடிப்படையிலானது பாதுகாக்கப்பட்ட தேர்வியில் சக-இணைப்பாளர் முகவரியைக் கோருகிறது. இதைத் தலைகீழாக்கினால் சுரங்கப்பாதை பச்சையாகவும் அமர்வு செயலற்றதாகவும் இருக்கும் பாரம்பரிய நிலை உருவாகிறது.
அமர்வு மேலே வந்தபின், அதைக் கடப்பது என்ன என்பதைக் கொள்கை தீர்மானிக்கிறது. முன்னொட்டு பட்டியல்கள், AS-பாதை வடிகட்டிகள், அதிகபட்ச முன்னொட்டு வரம்பு மற்றும் இயல்புநிலை பாதைகள் பற்றிய வெளிப்படையான முடிவு ஆகியவை குறைந்தபட்சம், அவை இரு திசைகளிலும் பொருந்தும். பெறுவதை எல்லாம் ஏற்கும் சக-இணைப்பாளர் உள்ளூர் இணைய அணுகலை அமைதியாக மாற்றும் இயல்புநிலை பாதையை உங்களுக்குத் தரலாம். இரு திசைகளுக்கும் தனித்தனி பட்டியல்கள் தேவை, ஏனெனில் சக-இணைப்பாளரிடமிருந்து நீங்கள் ஏற்பது வேறு, அவருக்கு அறிவிப்பது வேறு.
router bgp 65010
neighbor 10.255.0.2 remote-as 65020
address-family ipv4 unicast
neighbor 10.255.0.2 prefix-list SITE-B-IN in
neighbor 10.255.0.2 prefix-list SITE-B-OUT out
neighbor 10.255.0.2 maximum-prefix 50
பிறகு MTU கடிக்கிறது. உறைப்பொதிவு பயனுள்ள சுமையைக் குறைக்கிறது, எனவே பெரிய புதுப்பிப்பு முழுமையாக நிறுவப்பட்டதாகத் தோன்றும் அமர்வை நிறுத்தலாம்: சக-இணைப்பாளர் மேலேயே இருக்கிறார், முன்னொட்டுகள் ஒருபோதும் வருவதில்லை, பதிவில் தெளிவான எதுவும் விழுவதில்லை. வடிகட்டிகளைக் குறை சொல்லும் முன் சுரங்கப்பாதை இடைமுகத்தில் TCP MSS ஐ வரம்பிடுங்கள், அல்லது கூடுதல் செலவுக்கு இடம் விட்டு சுரங்கப்பாதை MTU வை அமையுங்கள்.
வெளிப்புற பொதிகள் இன்னும் எங்கே போகின்றன
ஒரு தளத்திலிருந்து மற்றொன்றுக்கு மறையாக்கப்பட்ட பொதிகள் உள்ளூர் திசைவி சக-இணைப்பாளரின் பொது முகவரிக்குத் தேர்ந்தெடுப்பதன் வழியாக வெளியேறுகின்றன. இரு தளங்களும் ஒரே வழங்குநரிடமிருந்து கடத்தலை வாங்கினால், ஒரே மெட்ரோ வசதியைக் கடந்தால், அல்லது ஒரு பக்கம் இயக்குநர் நிலை NAT பின்னால் இருந்தால், சுரங்கப்பாதை வழங்குநர் தோல்வியிலிருந்து தற்செயலாக மட்டுமே தப்பிக்கிறது. கண்காணிப்புக் கருவியில் சுரங்கப்பாதை சின்னங்களை எண்ணுவது இதைப் பற்றி எதுவும் சொல்லாது.
பாதை தேர்வும் அனுப்புதல் நிறுவலும் தனித்தனி நிகழ்வுகள். ஒரு முன்னொட்டு BGP அட்டவணையில் சிறந்ததாக இருக்கலாம், இன்னும் அனுப்புதல் அட்டவணையில் இல்லாமல் இருக்கலாம், ஏனெனில் அடுத்த தாவல் தீர்க்கப்படவில்லை அல்லது குறிப்பிட்ட பாதை வெல்லுகிறது. BGP முன்னொட்டைக் கற்றுக்கொண்டது ஆனால் போக்குவரத்து பாயவில்லை என்று யாராவது தெரிவித்தால், பயனுள்ள கேள்வி அது நிறுவப்பட்டுள்ளதா, எந்த அடுத்த தாவலை நோக்குகிறது என்பதுதான்.
வடிவமைப்பு மதிப்பாய்வுக்கு நேர்மையான பதில் பகிரப்பட்ட சார்புகளின் பட்டியல்: அணுகல் சுற்று, மேல் வழங்குநர், வசதி மற்றும் திரும்பும் பாதையில் நிலையை வைத்திருக்கும் எந்த சாதனமும். சுரங்கப்பாதை வழியாக ஒரு அமர்வு தான் மேலே அமராத சார்பை அகற்ற முடியாது.
பிரிக்கத் தகுந்த மூன்று முடிவுகள்
வடிவமைப்பு இவற்றைக் கலந்தால், ஒவ்வொரு செயலிழப்பு உரையாடலும் வட்டமிடுகிறது. முதலில் அவற்றைத் தாளில் பிரிக்கவும், பின்னர் ஒவ்வொன்றையும் அதை உண்மையில் நடைமுறைப்படுத்தும் சாதனத்துடன் இணைக்கவும்.
| Decision | Who controls it | Typical failure |
|---|---|---|
| Which prefixes may cross the relationship? | Both sides, through prefix and AS-path policy you configure deliberately | A default route accepted by mistake, or a vague aggregate |
| Which overlay next hop wins? | Local BGP selection plus next-hop resolution on your own routers | Prefix learned, never installed in the forwarding table |
| Where do the encrypted packets travel? | The underlay operators, unless a supported service adds real control | Path diversity that was never there |
ஒவ்வொரு வரிசைக்கும் வேறு உரிமையாளர். முதல் பேச்சுவார்த்தை, இரண்டாவது உங்கள் சாதனங்களில் உள்ள அமைவு, மூன்றாவது பெரும்பாலும் வேறொருவரின் வலைப்பின்னல். அது தொடும் வரிசையைப் பெயரிடும் மாற்றக் கோரிக்கை BGP பிரச்சினை என்று சொல்வதை விட மிக எளிதாக அனுமதிக்கப்படுகிறது.
திட்டமிடத் தகுந்த தோல்வி முறைகள்
சக-இணைப்பாளரின் சுருக்கப் பாதையை ஏற்பது மிகவும் பொதுவான சொந்தக் காயம். யாரோ பரிமாற்றத்தை எளிமைப்படுத்த ஒரு குறுகிய தொகுப்பை அறிவிக்கிறார், தொலைப்பக்கம் அதை ஏற்கிறது, சுரங்கப்பாதைக்குப் பின்னால் இல்லாத வரம்புகளின் போக்குவரத்து சுரங்கப்பாதையைப் பின்தொடர்ந்து இறக்கிறது. சரியாக எதிர்பார்க்கப்படும் முன்னொட்டுகளில் வடிகட்டுங்கள், அல்லது சரியான வரம்புகளுடன் முன்னொட்டு பட்டியலைப் பயன்படுத்துங்கள், அமர்வு சுத்தமாகத் தெரிகிறது என்பதற்காக வெற்றுத் தொகுப்பை ஒருபோதும் ஏற்க வேண்டாம்.
திரும்பப் பெறும் நேரம் இரண்டாவது. கண்டறிதல் தாங்கும் நேரக்கணக்கிகள், நீங்கள் இயக்கியிருந்தால் BFD, சுரங்கப்பாதையின் இறந்த சக-இணைப்பாளர் கண்டறிதல் மற்றும் தொலைப்பக்கம் எவ்வளவு விரைவாக அறிவிப்பதை நிறுத்துகிறது என்பதைப் பொறுத்தது. இருக்கும் அமர்வுகள் தனிப் பிரச்சினை: புதிய பாதை புதிய இணைப்புகளை மீட்டெடுக்கலாம், ஆனால் நிறுவப்பட்ட TCP அமர்வுகள் பழைய முகவரிகளைத் தொடர்ந்து பயன்படுத்துகின்றன, பாதையில் உள்ள நிலை-வைத்திருக்கும் தீச்சுவர்கள் அல்லது NAT இனி பொருந்தாத உள்ளீடுகளை வைத்திருக்கலாம். பாதை மாற்றம் எல்லாவற்றையும் சரிசெய்யும் என்று கருதுவதற்குப் பதிலாக பயன்பாட்டு மீட்பை ஏற்பு அளவுகோல்களில் சேர்க்கவும்.
மூன்றாவது திரும்பும் பாதையின் சமச்சீரற்ற தன்மை. போக்குவரத்து சுரங்கப்பாதை வழியாக வந்து, அதைச் சுமக்க ஒருபோதும் நோக்கப்படாத வழங்குநர் இணைப்பு வழியாகத் திரும்பலாம், இது ஒரு திசை ஒலி, தோல்வியுற்ற கைக்குலுக்கல் அல்லது பதில்களைத் தூக்கி எறியும் தீச்சுவர் ஆக தெரிகிறது. இரு திசைகளையும் தனித்தனியாகச் சரிபார்க்கவும்.
ஒப்பந்தத்தில் எழுத வேண்டியது, அதை எப்படிச் சரிபார்ப்பது
அனுமதிக்கப்பட்ட முன்னொட்டுகளை எழுத்துப்பூர்வமாகக் கேளுங்கள்: ஒவ்வொரு வரம்பையும் உருவாக்க யாருக்கு அதிகாரம் உள்ளது, இயல்புநிலை பாதை அனுமதிக்கப்படுகிறதா, சுரங்கப்பாதை சேவை எந்த முகவரி குடும்பங்களை ஆதரிக்கிறது. RFC 8212 அதைப் பின்பற்றும் செயலாக்கங்களில் eBGP க்கு வெளிப்படையான இறக்குமதி மற்றும் ஏற்றுமதிக் கொள்கையை எதிர்பார்ப்பாக்கியது, எனவே இன்னும் மறைமுகமாக எல்லாவற்றையும் ஏற்கும் நடத்தையை நம்பும் சக-இணைப்பாளரைக் கேட்பது மதிப்புள்ளது.
பின்னர் வரைபடத்திலிருந்து அல்ல, சாதனத்திலிருந்து சரிபார்க்கவும். FRR பாணி திசைவிகளில் பயனுள்ள கட்டளைகள்:
show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16
பாதை அட்டவணை தர முடியாத இரண்டு கண்காணிப்புகளைச் சேர்க்கவும். உறைப்பொதிவு செய்யப்பட்ட பொதிகள் உண்மையில் எந்த முகவரியை இலக்காகக் கொள்கின்றன என்பதை உறுதிப்படுத்த வெளிப்புற இடைமுகத்தில் பதிவு செய்யுங்கள், எடுத்துக்காட்டாக tcpdump -ni eth0 udp port 51820 WireGuard சுரங்கப்பாதைக்கு, அல்லது IPsec க்கு ESP வடிகட்டி. பின்னர் சக-இணைப்பாளரின் பொது முகவரி நோக்கி தடம் பதியுங்கள், சுரங்கப்பாதைக்குள் உள்ள தடத்துடன் தாவல்களை ஒப்பிடுங்கள்; இரண்டும் ஒரே வழங்குநர் சங்கிலியைப் பின்தொடர்ந்தால், உங்கள் மிகையளவு வலைப்பின்னலில் அல்ல, பாதைக் கொள்கையில் வாழ்கிறது.
இறுதியாக, வேண்டுமென்றே திரும்பப் பெறுதலைச் சோதிக்கவும். பராமரிப்பு சாளரத்தில் சுரங்கப்பாதையை இறக்குங்கள், முன்னொட்டு எவ்வளவு காலம் நிறுவப்பட்டிருக்கிறது, இருக்கும் அமர்வுகளுக்கு என்ன நடக்கிறது, தொலைப்பக்கம் நீங்கள் உண்மையில் ஏற்கும் பாதைக்குத் திரும்புகிறதா என்பதைப் பதிவு செய்யுங்கள். அந்தப் பயிற்சி எந்த வரைபடத்தையும் விட வடிவமைப்பைப் பற்றி அதிகம் சொல்கிறது.
பாதை என்பது அனுமதி அல்ல. நீங்கள் பரிமாறிக்கொள்ள ஒப்புக்கொள்ளும் முன்னொட்டுகள் சுரங்கப்பாதைக்குப் பின்னால் எந்தச் சேவைக்கு எந்தப் பயனர்கள் அணுகலாம் என்பதைப் பற்றி எதுவும் சொல்லாது, எனவே அங்கீகாரம், அனுமதிக்கப்பட்ட சேவைகள் மற்றும் புரவலன் தீச்சுவர்களை இருந்த இடத்திலேயே வைத்திருங்கள். அணுகக்கூடிய சக-இணைப்பாளரும் வரம்பற்ற கடத்தலுக்கோ தன்னிச்சையான முகவரிகளை உருவாக்கவோ அனுமதி அல்ல, அத்தகைய அதிகாரம் BGP கொள்கை வரியில் அல்ல, வணிகக் கேள்வியாக ஒப்பந்தத்தில் இருக்க வேண்டும்.
- ஒவ்வொரு பக்கமும் உருவாக்கக்கூடிய முன்னொட்டுகளையும் ஒருபோதும் ஏற்கக்கூடாதவற்றையும் பெயரிடுங்கள்.
- சுரங்கப்பாதையில் MSS ஐ வரம்பிட்டு பெரிய புதுப்பிப்புகள் உண்மையில் வருகின்றன என்பதை உறுதிப்படுத்துங்கள்.
- பகிரப்பட்ட அடுக்கு சார்புகளைப் பட்டியலிடுங்கள், சுரங்கப்பாதைகளின் எண்ணிக்கையை அல்ல.
- உண்மையான திரும்பப் பெறுதலை அளந்து பயன்பாடு என்ன செய்கிறது என்பதைப் பதிவு செய்யுங்கள்.