AWS இலிருந்து Azure சைட் VPN: முதலில் திரும்பும் பாதையை எழுதுங்கள்
இரண்டு கிளவுட்களுக்கிடையே இணைக்கப்பட்ட சுரங்கப்பாதை, ஒவ்வொரு பணிச்சுமை துணைப்பிணையமும் தொலை முன்னொட்டுக்கு வழிவகுக்காத வரை எதையும் நிரூபிக்காது. திட்டத்தை வரிசையாகச் செய்து, பின்னர் சேவையைச் சோதிக்கவும்.
சுரங்கப்பாதை மேலெழும். பொதுவாக அப்படியே நடக்கும், ஏனெனில் IKE-க்கு பொருந்தும் முன்மொழிவுகள் மற்றும் அணுகக்கூடிய சக முகவரி மட்டுமே தேவை. அதன் பிறகு தோல்வியடைவது திரும்பும் பாதையே: AWS பணிச்சுமை பாக்கெட்டுகளை சுரங்கப்பாதைக்கு அனுப்புகிறது, ஆனால் Azure பக்கத்தில் 10.10.0.0/16-க்கு எப்படிப் பதிலளிப்பது என்று யாருக்கும் தெரியாது, அல்லது Azure பாதை பணிச்சுமை துணைப்பிணையம் பயன்படுத்தாத அட்டவணையில் உள்ளது. எந்தக் கன்சோலையும் தொடும் முன் பாதைத் திட்டத்தை எழுதுங்கள், சுரங்கப்பாதை வேலையின் மிகக் குறைந்த சுவாரஸ்யமான பகுதியாகிவிடும்.
படி 1: முகவரித் திட்டத்தை உறையவைக்கவும்
உறுதியான மதிப்புகளுடன் வேலை செய்யுங்கள். AWS பணிச்சுமை 10.10.0.0/16-க்குள் 10.10.1.20-இல் உள்ளது, 10.20.0.0/16-க்குள் 10.20.1.30-இல் உள்ள Azure சேவைக்கு TCP 443 தேவை. இரு வரம்புகளும் ஒன்றின்மீது ஒன்று வரக்கூடாது, ஏற்புச் சோதனை சேவை இணை, சுரங்கப்பாதை அல்ல.
வேறு எதற்கும் முன் அந்த நான்கு உண்மைகளை எழுதுங்கள், ஏனெனில் ஒவ்வொரு அடுத்த படியும் அவற்றுக்கு எதிராகச் சரிபார்க்கப்படுகிறது.
படி 2: ஒவ்வொரு முனையின் உரிமையாளர் நுழைவாயிலைப் பெயரிடுங்கள்
AWS Site-to-Site VPN மெய்நிகர் தனியார் நுழைவாயிலிலோ அல்லது போக்குவரத்து நுழைவாயிலிலோ முடியலாம், இவை வெவ்வேறு வழித்தட உரிமையாளர்கள். Azure அதன் நிர்வகிக்கப்பட்ட VPN Gateway மற்றும் தனியாக வாடிக்கையாளர்கள் தாமே இயக்கும் VM அடிப்படையிலான சாதனங்களை வழங்குகிறது. உங்களிடம் எந்த இணை உள்ளது எனப் பதிவு செய்யுங்கள், ஏனெனில் ஒவ்வொரு சேர்க்கையிலும் அடுத்த தாவல் வேறுபடும்.
நிர்வகிக்கப்பட்ட நுழைவாயிலுக்கு, ஊகிக்கப்பட்ட தனியார் சாதன முகவரிக்கு சுட்டும் பாதையை நகலெடுக்க வேண்டாம். சாதனத்திற்கு, கிளவுட் பாதைப் பரவல் விருந்தினர் இயங்குதளத்தை அமைக்கும் என்று கருத வேண்டாம், ஏனெனில் அது அவ்வாறு செய்யாது.
இங்கு தவறு செய்தால் முழுமையாகத் தெரியும் திட்டம் உருவாகி, ஒருபோதும் பதிலளிக்காத முகவரிக்குப் பாக்கெட்டுகளை அனுப்பும்.
படி 3: ஒவ்வொரு பணிச்சுமையும் உண்மையில் பயன்படுத்தும் பாதையை எழுதுங்கள்
கீழே உள்ள ஒவ்வொரு எல்லையும் தனித் தேடல், அவற்றில் ஒன்றின் பாதை பாக்கெட்டுக்கான பாதை அல்ல. சுரங்கப்பாதை இயங்கத் தொடங்கும் முன் அட்டவணையை உங்கள் மதிப்புகளால் நிரப்புங்கள்.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
AWS-இல், BGP அல்லது சுரங்கப்பாதை ஆரோக்கியமான பிறகும் பணிச்சுமை துணைப்பிணையத்தின் பாதை அட்டவணையை நீங்களே புதுப்பிக்க வேண்டும்; வழித்தட கண்ணோட்டம் அதை இணைப்பின் பகுதியாகக் கருதுகிறது. Azure-இல், பயனர் வரையறுத்த பாதை அட்டவணை மெய்நிகர் வலையமைப்புடன் அல்ல, துணைப்பிணையத்துடன் இணைகிறது, எனவே பயனுள்ள பாதையை VNet பிளேடில் அல்ல, பணிச்சுமை NIC-இல் சரிபார்க்கவும்.
நிர்வகிக்கப்பட்ட Azure நுழைவாயில் நுழைவாயில் பரவல் மூலம் தொலை முன்னொட்டைக் கற்கலாம், UDR அந்த முடிவை ரத்து செய்யலாம். காரணம் இருக்கும்போது UDR சேர்க்கவும், பழக்கத்தால் அல்ல. சேர்த்தால், சாதன முகவரியைக் கற்பனை செய்வதற்குப் பதிலாக நுழைவாயில் VPN பாதைக்கு வெளியிடும் அடுத்த தாவலுக்கு இயக்கவும். பின்னர் NIC-இல் பயனுள்ள பாதைகளை மீண்டும் படியுங்கள், ஏனெனில் முடிவு உண்மையில் அங்கேயே எடுக்கப்படுகிறது.
படி 4: எல்லையைப் பொருத்துங்கள்
BGP-க்கு, ஒவ்வொரு பக்கமும் அறிவிப்பதை மறுபக்கம் உண்மையில் கற்றவற்றுடன் முன்னொட்டு வாரியாக ஒப்பிடுங்கள். நிலையான வழித்தடத்திற்கு, அமைக்கப்பட்ட தொலை வரம்புகளை படி 3-இல் எழுதிய பணிச்சுமை பாதைகளுடன் ஒப்பிடுங்கள்.
குறியாக்கவியலில் உடன்படும் IKE உறவு, எந்தப் பக்கமும் 10.10.0.0/16 அல்லது 10.20.0.0/16 கற்றது என்பதற்கான சான்று அல்ல. நீங்கள் திட்டமிட்ட /16-க்குப் பதிலாக ஒரே /24-ஐ அறிவித்துக்கொண்டே இரு சுரங்கப்பாதைகள் மேலிருக்கலாம். முன்னொட்டை வழித்தட அட்டவணையில் சரிபார்க்கவும், சுரங்கப்பாதை நிலையில் அல்ல. முரண்பாடு பின்னர் வேலை செய்யும் ஒரு துணைப்பிணையமாகவும் ஒருபோதும் பதிலளிக்காத மற்றொன்றாகவும் தெரியும்.
படி 5: உண்மையான மூலத்திலிருந்து சேவையைச் சோதிக்கவும்
AWS பாதுகாப்புக் குழுக்கள் மற்றும் வலையமைப்பு ACL, Azure NSG, மற்றும் பாதையில் உள்ள எந்தச் சாதன வடிகட்டியிலும் நோக்கிய ஓட்டத்தை அனுமதிக்கவும். பின்னர் 10.10.1.20-இலிருந்து அங்கீகரிக்கப்பட்ட சேவை முகவரி மற்றும் துறைமுகத்திற்கு ஒரு இணைப்பைத் திறந்து, பதில் அதே மூலத்திற்குத் திரும்புகிறது என்பதை உறுதிப்படுத்தவும்.
கிளவுட் பாதுகாப்புக் குழுக்களும் NSG-களும் stateful, எனவே நிராகரிக்கப்பட்ட திரும்பும் பாக்கெட் வழித்தடத்தின் அறிகுறி, எதிர் திசையில் எழுத மறந்த விதி அல்ல.
எந்த நுழைவாயிலிலிருந்தும் ping எதையும் தீர்மானிக்காது. நுழைவாயில் முகவரிக்கு ICMP கட்டுப்பாட்டுத் தளப் பாதையைப் பயிற்சி செய்கிறது, பணிச்சுமைக்குத் தேவையான அனுப்பப்பட்ட TCP சேவையை அல்ல.
பின்னடைவு மற்றும் பதிவுகள்
சுரங்கப்பாதை அடையாளங்களுக்கு அருகில் பாதை உரிமையாளர்களைப் பதிவு செய்து, மாற்றத்திற்கு முந்தைய பாதை அட்டவணைகளைச் சேமிக்கவும். மாற்றத்தை அகற்ற வேண்டுமானால், சுரங்கப்பாதையை உடைப்பதற்கு முன் பணிச்சுமை பாதைகளை அகற்றுங்கள், இனி இல்லாத அடுத்த தாவலுக்கு எந்தத் துணைப்பிணையமும் சுட்டாமல் இருக்க.
பின்னர் துணைப்பிணையம் நகர்த்தல் அல்லது spoke இணைப்புக்குப் புதுப்பிக்க ஒரு நிஶ്ചित இடம் இருக்கும், ஒருபோதும் தனக்குச் சொந்தமில்லாத பாதைக்கான குற்றத்தைச் சுமக்கும் இயங்கும் சுரங்கப்பாதைக்குப் பதிலாக.