NAT පිටුපස සිටින peer සමඟ Azure අඩවි-තොට-අඩවි VPN: පරීක්ෂණ ලැයිස්තුව

මෙම පරීක්ෂණ පිළිවෙලට කරන්න, පළමුව අසමත් වන එකේ නවතින්න. Azure NAT පිටුපස ඇති උපාංගයක් සහාය නොදක්වන බවට එන බොහෝ වාර්තා ඇත්ත වශයෙන්ම Azure වෙත ළඟා විය නොහැකි peer ලිපිනයක් හෝ නිවැරදි පැත්තෙන් කිසිදා ආරම්භ නොවන ටනලයක් බවට පත් වේ. පිටත ප්‍රවාහනය සහ ඇතුළත මාර්ගගත කිරීම වෙනස් ගැටලු දෙකකි, ඒවා මිශ්‍ර කිරීමෙන් අඩක් දවසක් නාස්ති වේ. පහත සෑම පියවරක්ම වෙනත් අයෙකුට දිය හැකි නිරීක්ෂණයක් ලබා දෙයි.

පියවර 1: peer සැබවින්ම NAT පිටුපස ඇති බව තහවුරු කරන්න

උපාංගයේ WAN අතුරුමුහුණතේ ලිපිනය Azure එය සඳහා දකින ලිපිනය සමඟ සසඳන්න. ඒවා වෙනස් නම්, යමක් පරිවර්තනය කරමින් සිටී, එම පරිවර්තකය දැන් ඔබේ VPN නිර්මාණයේ කොටසකි. සපයන්නාගෙන් අසන්න සිතියම්කරණය ස්ථිතික ද හවුල් ද කියා, මන්ද හවුල් සිතියම්කරණය ඔබට රැඳී සිටිය හැකි දේ වෙනස් කරයි. පෞද්ගලික WAN ලිපිනයක් සහ යොමු කිරීමක් නැති උපාංගය ස්ථාවර පොදු සිතියම්කරණයක් සහිත වාහක මට්ටමේ NAT පිටුපස ඇති උපාංගයට වඩා වෙනස් අවස්ථාවකි.

ලිපින දෙකම ගැළපෙන්නේ නම්, මෙතැන නවතින්න: NAT ඔබේ ගැටලුව නොවන අතර මෙම ලැයිස්තුවේ ඉතිරිය උදව් නොකරනු ඇත.

ටිකට්පතේ ලිපින දෙකම සහ පරිවර්තකයේ මාදිලිය සටහන් කරන්න. එම එක් පේළිය වින්‍යාස කළ peer පිළිතුරු නොදෙන්නේ මන්ද යන ඊළඟ ප්‍රශ්න වටය වළක්වයි.

පියවර 2: කවුරුන් ආරම්භ කරන්නේ දැයි එකඟ වන්න

Azure VPN Gateway නිතර අසන ප්‍රශ්න NAT-T සහාය සඳහන් කරන අතර, on-premises උපාංගය NAT පිටුපස සිටින විට IPsec ටනලය එයින්ම ආරම්භ කළ යුතු බව එකතු කරයි. එය තත්ත්ව සහිත පරිවර්තනය ක්‍රියා කරන ආකාරයට ගැළපේ, මන්ද ඇතුළත උපාංගය පළමු පැකට් යැවූ නිසා පරිවර්තකය සිතියම්කරණයක් තබා ගනී. Azure ආරම්භ කරනු ඇතැයි අපේක්ෂා කරන අතර එම සිතියම්කරණය සෑදීමට කිසිවක් නොපැමිණෙන්නේ නම්, ටනලය කිසිදා ආරම්භ නොවේ.

පිළිතුරු දෙන්නා පමණක් යන වැරැද්ද පැහැදිලි වන පරිදි peer වින්‍යාස කරන්න, උපාංගයම නැවත උත්සාහ කරනවා ද නැතහොත් ට්‍රිගරයක් අවශ්‍ය දැයි පරීක්ෂා කරන්න. සමහර උපාංග රසවත් රථවාහනයක් දිස්වන විට පමණක් ටනලය ඔසවයි, එය රසවත් රථවාහනය කිසිදා නොඑන සෞඛ්‍ය පරීක්ෂාවක් වන තෙක් හොඳය.

අතින් ආරම්භ කිරීමේදී උපාංගයේ IKE හුවමාරුව නිරීක්ෂණය කරන්න; එහි නිශ්ශබ්දතාව මාර්ගගත කිරීමේ හෝ ගිනිපවුරේ පිළිතුරකි, Azure හි පිළිතුරක් නොවේ.

පියවර 3: peer ලිපිනය නිවැරදිව ගන්න

Azure ට එහි දේශීය ජාල ද්වාර වස්තුවේ peer සඳහා ළඟා විය හැකි පොදු ලිපිනයක් අවශ්‍ය වේ, සාමාන්‍යයෙන් උපාංගයේ ඇතුළත ලිපිනය නොව පරිවර්තකයේ පොදු ලිපිනය. උපාංගය අත්සන් කරන අනන්‍යතාව වෙනම ක්ෂේත්‍රයක් වන අතර Azure අමතන ලිපිනයට වඩා නීත්‍යානුකූලව වෙනස් විය හැක. දෙකම වෙන් කර තබන්න, මන්ද ඒවා මාරු කිරීම NAT ගැටලුවක් හා හරියටම සමාන පෙනුමක් ඇති සත්‍යාපන අසාර්ථකත්වයක් ඇති කරයි.

පොදු ලිපිනය වෙනස් වුවහොත් එම වස්තුව ද ඒ සමඟ වෙනස් විය යුතුය. පැරණි ලිපිනයකට විසඳෙන නමක් අතින් යාවත්කාලීන කළ යුතු ස්ථිතික ලිපිනයකට වඩා නරකය.

අගයන් තුනම ලියන්න: උපාංගයේ දේශීය ලිපිනය, පරිවර්තිත පොදු ලිපිනය, වින්‍යාස කළ peer අනන්‍යතාව.

පියවර 4: NAT-T ට අවශ්‍ය වරායන් පමණක් විවෘත කරන්න

NAT-T ESP එක UDP තුළ රැගෙන යයි, RFC 3948 එම ආවරණය විස්තර කරන්නේ වරාය 500 ට පසු වරාය 4500 භාවිත කරන බවයි. ඔබේ ගිනිපවුර සහ පරිවර්තකය දෙකම හුවමාරුවට සහ එහි ආපසු රථවාහනයට අවසර දිය යුතුය. සම්බන්ධ නැති TCP වරායකට අවසර දීම මෙම මාර්ගය ගැන කිසිවක් ඔප්පු නොකරයි, පිටතට යාමට අවසර දී පිළිතුරට නොදෙන නීතිය ද තවමත් අසමත් වේ.

peer ආරම්භ කර පරිවර්තකය තත්ත්වය තබා ගන්නා විට ස්ථිතික ඇතුළු වරාය යොමු කිරීම ස්වයංක්‍රීයව අවශ්‍ය නොවේ. සිතියම්කරණය අස්ථිර වූ විට හෝ මාර්ගයේ යමක් තත්ත්වය ආක්‍රමණශීලී ලෙස කල් ඉකුත් කරන විට එය අවශ්‍ය වේ.

පරිවර්තකයේ දෙපසම එක් වරක් ග්‍රහණය කරන්න; ආවරණ වෙනස වහාම දිස්වේ.

පියවර 5: පිටත ප්‍රවාහනය ඇතුළත මාර්ගගත කිරීමෙන් වෙන් කරන්න

ස්ථාපිත වී කිසිවක් රැගෙන නොයන ටනලයක් මාර්ගගත කිරීමේ ගැටලුවකි, NAT-T ගැටලුවක් නොවේ. අඩවිවලට තවමත් ගැළපෙන රථවාහන තෝරක, ගැළපෙන ලිපින අවකාශ, ප්‍රවේශ නීති සහ යෙදුම් ජාල සඳහා ආපසු මාර්ගයක් අවශ්‍ය වේ. සාර්ථක IKE හුවමාරුවක් මේ කිසිවක් ලබා නොදේ.

අඩවි දෙකම එකිනෙක මුදුනට වැටෙන පෞද්ගලික පරාස භාවිත කරන්නේ නම්, ටනලය තුළ පරිවර්තනය තමන්ගේම නීති සහිත වෙනම නිර්මාණයකි. පිටත ද්වාරය ගෘහස්ථ රවුටරයක පිටුපස සිටින නිසා පමණක් උපජාලයක් නැවත අංකනය නොකරන්න.

කිසිවක් වෙනස් කිරීමට පෙර අසාර්ථකත්වය අදියර අනුව වර්ග කරන්න, එම වර්ගීකරණය ටිකට්පතේ තබන්න, එවිට ඊළඟ පුද්ගලයා ඔබ නැවතුණු තැනින් ආරම්භ කරනු ඇත.