இரு கிளைகளுக்கிடையேயான டிராஃபிக்கை Azure VPN கேட்வே வழியாக ரூட் செய்யுங்கள்
ஒரே Azure VPN கேட்வேயில் உள்ள இரு சைட்-டு-சைட் இணைப்புகள் கிளைகளின் டிராஃபிக்கைக் கடக்க அனுமதிக்கும், ஆனால் இரு முனைகளும் முன்னொட்டைக் கற்று LAN திரும்பும் பாதை இருக்கும்போது மட்டுமே.
இரு கிளைகள் தங்களுக்கிடையே நேரடி சுரங்கம் இல்லாமல் Azure VPN கேட்வே வழியாக டிராஃபிக்கை பரிமாறிக்கொள்ளலாம். ஒவ்வொரு கிளையும் அதே கேட்வேக்கு சைட்-டு-சைட் இணைப்பைத் திறக்கிறது, கேட்வே கற்றுக்கொண்ட முன்னொட்டுகளை இரு இணைப்புகளுக்கிடையே கடத்துகிறது. இதைச் செயல்படுத்துவது இரண்டாவது சுரங்கம் அல்ல, ரூட் பரிமாற்றம்: கிளை A கிளை B இன் முன்னொட்டைக் கற்றுக்கொள்ள வேண்டும், B கிளை A வின் முன்னொட்டைக் கற்றுக்கொள்ள வேண்டும். கீழே உள்ள சோதனைகளை வரிசையாகச் செய்து முதலில் தோல்வியடையும் சோதனையில் நிறுத்துங்கள், ஏனெனில் ஒவ்வொரு அடுத்த படியும் அதைச் சார்ந்துள்ளது.
எதையும் உள்ளமைக்கும் முன் முன்நிபந்தனைகள்
இந்த வடிவமைப்பு எதற்கும் வேலை செய்யுமா என்பதை நான்கு நிபந்தனைகள் தீர்மானிக்கின்றன. கேட்வே ரூட் அடிப்படையிலானதாக இருக்க வேண்டும் மற்றும் BGP ஐ ஆதரிக்கும் SKU இல் இருக்க வேண்டும், இரு இணைப்புகளிலும் BGP இயக்கப்பட்டிருக்க வேண்டும், கிளைகளின் முகவரி இடங்கள் ஒன்றையொன்று மேலெழக்கூடாது, எந்தப் பக்கமும் தன் உண்மையான முன்னொட்டை மறைக்க NAT ஐ நம்பக்கூடாது.
ASN களை வேண்டுமென்றே திட்டமிடுங்கள். Azure இன் ஆவணப்படுத்தப்பட்ட இயல்புநிலை மதிப்பு 65515, ஒவ்வொரு கிளை ரவுட்டருக்கும் கேட்வே அல்லது மற்ற கிளையுடன் மோதாத அதன் சொந்த தனிப்பட்ட ASN தேவை. தற்போதைய கேட்வே உள்ளமைவைச் சரிபார்க்காமல் இயல்புநிலையை மீண்டும் பயன்படுத்துவதே பின்னர் AS பாதை நிராகரிக்கப்படுவதற்கான வழி.
நீங்கள் VNet பியரிங் நடத்தையை எதிர்பார்க்கவில்லை என்பதையும் உறுதிப்படுத்துங்கள். கேட்வே நீங்கள் உள்ளமைத்த இரு இணைப்புகளுக்கிடையே ரூட்டுகளைப் பரிமாறுகிறது; இது தன்னிச்சையான பியரிங்குகளை கடத்தக்கூடியதாக்காது. மூன்றாவது நெட்வொர்க் இரு கிளைகளையும் அடைய வேண்டுமானால், அதற்கு அதன் சொந்த இணைப்பு அல்லது அதன் சொந்த ரூட் பாதை தேவை, கேட்வே டிராஃபிக்கைப் பங்கிடும் என்ற ஊகம் அல்ல. முதல் மாற்ற சாளரத்திற்கு முன் அந்த எல்லையை எழுதி வையுங்கள், ஏனெனில் பின்னர் தளம் சேர்க்கப்படும்போது மக்கள் திரும்பி வருவது அந்த வடிவமைப்பு முடிவுக்கே.
இந்த வரிசையில் உள்ளமைக்கவும்
ஒவ்வொரு படிக்கும் கவனிக்கக்கூடிய முடிவு உள்ளது, எனவே அது தோன்றும் வரை முன்னேற வேண்டாம்.
- மெய்நிகர் நெட்வொர்க் கேட்வேயில் BGP ஐ இயக்கி அதன் ASN மற்றும் பியர் முகவரியைக் குறிப்பிடுங்கள்.
- ஒவ்வொரு கிளைக்கும் அந்தக் கிளையின் உண்மையான முகவரி இடம், அதன் ASN மற்றும் அதன் BGP பியர் முகவரியுடன் உள்ளூர் நெட்வொர்க் கேட்வேயை உருவாக்குங்கள்.
- ஒவ்வொரு சைட்-டு-சைட் இணைப்பையும் உருவாக்கி இணைப்பிலேயே BGP ஐ இயக்குங்கள்.
- கிளை ரவுட்டரை ஊகத்தின் அடிப்படையில் கேட்வேயின் பொது IKE முனையத்துடன் அல்ல, Azure ஒதுக்கிய கேட்வே முகவரியுடன் பியர் செய்ய உள்ளமைக்கவும்.
நான்காவது படியில்தான் பெரும்பாலான முயற்சிகள் தடைபடுகின்றன. Azure தெரிவிக்கும் BGP பியர் முகவரியே கிளை ரவுட்டர் அண்டை வீரராகப் பயன்படுத்த வேண்டியது, அது மக்கள் சுரங்க வரைபடத்திலிருந்து எதிர்பார்ப்பது எப்போதும் அல்ல.
கிளையின் முன்னொட்டையே அறிவியுங்கள், எடுத்துக்காட்டாக A இலிருந்து 10.10.0.0/16 மற்றும் B இலிருந்து 10.20.0.0/16. விடுபட்ட குறிப்பிட்ட நெட்வொர்க்கை மூட இயல்புநிலை ரூட் அல்லது பரந்த தொகுப்பை அறிவிக்க வேண்டாம்; இடைவெளி பின்னர் அமைதியான கருந்துளையாகத் திரும்புகிறது.
இரு முனைகளிலும் ரூட் பரிமாற்றத்தைச் சரிபார்க்கவும்
இணைப்பு நிலை என்பது சோதனை அல்ல. இரு இணைப்புகளிலும் IPsec இயங்கிக்கொண்டிருக்கலாம், ஆனால் அவற்றுக்கிடையே எந்த முன்னொட்டும் கடக்காது. கேட்வேயின் BGP பியர்கள் மற்றும் கற்ற ரூட்டுகளைப் படித்து, பின்னர் மற்ற கிளையை நோக்கிய ரூட் பயன்படுத்தக்கூடிய பாதையாகத் தோன்றுவதை உறுதிப்படுத்துங்கள்.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
BGP அட்டவணையில் உள்ள முன்னொட்டும் நிலையான ரூட் அல்லது மிகக் குறிப்பிட்ட முன்னொட்டுக்கு அனுப்புதல் முடிவை இழக்கலாம். பெற்ற ரூட்டை மட்டுமல்ல, தேர்ந்தெடுத்த ரூட்டைச் சரிபார்க்கவும்.
LAN பக்கத்தில் திரும்பும் பாதையைப் பின்பற்றுங்கள்
இதுதான் Azure இல் சரியாகத் தெரிந்து தளத்தில் தோல்வியடையும் பகுதி. கிளை A இல் உள்ள ஒரு ஹோஸ்ட் அந்த ரவுட்டர் அதன் இயல்புநிலை கேட்வேயாக இருந்தால், அல்லது ஹோஸ்ட் அல்லது அதன் கேட்வே B இன் முன்னொட்டுக்கு ரூட் வைத்திருந்தால் மட்டுமே தன் பாக்கெட்டை A இன் VPN ரவுட்டருக்கு அனுப்புகிறது. எதிர் திசையிலும் இதுவே உண்மையாக இருக்க வேண்டும்.
தனி கோர் சுவிட்ச் LAN இன் இயல்புநிலை கேட்வேயாக இருந்தால், அது VPN ரவுட்டரை நோக்கிச் சுட்டும் மற்ற கிளை நோக்கிய ரூட்டைக் கொண்டிருக்க வேண்டும். அது இல்லாமல் கோரிக்கை வந்து பதில் இணையப் பாதை வழியாக வெளியேறுகிறது, பயனர் திறந்து பின்னர் தொங்கும் இணைப்பைக் காண்கிறார்.
இதைச் சரிசெய்ய கேட்வே சப்நெட்டில் உள்ள நெட்வொர்க் பாதுகாப்புக் குழுவை நாட வேண்டாம். அந்த சப்நெட்டுக்கு அதன் சொந்தத் தேவைகள் உள்ளன, அங்குள்ள NSG கிளைப் பக்கக் கொள்கைக்கு ஆதரிக்கப்படும் மாற்று அல்ல. வடிகட்டுதல் கிளைகளின் ஃபயர்வால்களிலும் பணிச்சுமைகளிலும் தான் இருக்க வேண்டும், அங்கு விதிகளை உரிமையாளர்கள் மதிப்பாய்வு செய்யலாம். அந்த விதிகளை சப்நெட் NSG க்கு நகர்த்துவது அடுத்த பழுதை பிழைதிருத்தும் குழுவிடமிருந்தும் அவற்றை மறைக்கிறது.
செயல்பாட்டை அனுமதித்து, பின்னர் நிராகரிக்கப்பட்ட சோதனையால் நிரூபியுங்கள்
கற்ற ரூட் அனுமதி அல்ல. உங்களுக்கு உண்மையில் தேவையான மூலம், இலக்கு மற்றும் சேவையை கிளைகளின் ஃபயர்வால்கள் மற்றும் முனையக் கொள்கை வழியாக அனுமதியுங்கள், மீதமுள்ளதை நிராகரிக்கப்பட்டதாக விடுங்கள்.
கிளை A இன் சாதாரண பணிச்சுமையிலிருந்து கிளை B இன் உண்மையான சேவைக்குச் சோதித்து, பதிலை உறுதிப்படுத்தி, பின்னர் தடைசெய்யப்பட்டிருக்க வேண்டிய செயல்பாட்டை முயற்சிக்கவும். VPN சாதனம் உருவாக்கும் டிராஃபிக் வேறு மூல முகவரியைப் பயன்படுத்தி LAN ரூட்டிங் படியைத் தவிர்க்கலாம், எனவே ரவுட்டரிலிருந்து வெற்றிகரமான ping தெரிவதை விடக் குறைவாகவே நிரூபிக்கிறது.
நான்கு உண்மைகளை எழுதி முடிக்கவும்: பரிமாறப்பட்ட முன்னொட்டுகள், பயன்படுத்தப்படும் ASN, ஒவ்வொரு பக்கத்தின் LAN திரும்பும் பாதை, மற்றும் சேவையை அனுமதிக்கும் கொள்கை. இவற்றில் ஒன்று விடுபட்டால் அமைப்பு முதல் மாற்றம் வரை வேலை செய்யும், பின்னர் ஏன் என்று யாரும் விளக்க முடியாது.