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 සම්බන්ධ කිරීමකට යාවත්කාලීන කිරීමට එක් නිශ්චිත ස්ථානයක් ඇත, කිසිදා තමන් සතු නොවූ මාර්ගයක වැරැද්ද දරන ක්රියාකාරී ටනලයක් වෙනුවට.