Azure S2S VPN සම්බන්ධයි නමුත් ට්‍රැෆික් නැත: IKE ලොගය කියවන්න
Azure ට site-to-site සම්බන්ධතාවය Connected ලෙස පෙන්විය හැකි අතර සෑම පැකට්ටුවක්ම මිය යයි. පළමුව AH සහ ලිපින අවකාශයේ දෝෂ සඳහා අපනයනය කළ IKE ලොගය කියවන්න.
පෝර්ටලය Connected යයි පවසයි, ටනලයට ක්‍රියාකාරී කාල ගණකයක් ඇත, සහ ඔබේ අතථ්‍ය යන්ත්‍රයෙන් ගත් trace එක දෙවන hop එකේදී මිය යයි. සම්බන්ධතා තත්ත්වය IKE සහ IPsec සාකච්ඡාව විස්තර කරයි, දෙපසම ප්‍රතිපත්ති ස්ථරය හරහා එක් පැකට්ටුවක් ගමන් කරනවාද යන්න නොවේ. මේ ටිකට් බොහොමයක් සඳහා හේතුව දෝෂ දෙකකි, සහ ඉන් එකක්වත් Azure මාර්ගයක් වෙනස් කිරීමෙන් හදන්නේ නැත. දෙකම දැනටමත් ගේට්වේ නිපදවූ ලොගයේ ලියා ඇත, ඒ නිසා මම මාර්ග වගුවෙන් නොව එතැනින් ආරම්භ කරමි.
Connected සැබවින්ම සහතික කරන්නේ කුමක්ද
සම්බන්ධිත site-to-site සම්බන්ධතාවයක් යනු 1 වන සහ 2 වන අදියර සම්පූර්ණ වී ආරක්ෂක සංගම් ක්‍රියාත්මක බවයි. එය සාකච්ඡාව පිළිබඳ ප්‍රකාශයකි: දෙපසම යෝජනාවකට එකඟ වී, යතුරු හුවමාරු කරගෙන SA යුගලය ස්ථාපනය කළහ. ඔබ ආරක්ෂිත යැයි සිතන උපජාලා සමඟ රහස්‍ය තෝරක ගැලපෙනවාද, නැතහොත් විකේතනය කිරීමෙන් පසු ඈත පස පැකට්ටුව කොහේ හරි මාර්ගගත කරයිද යන්න ගැන එය කිසිවක් නොකියයි. ටනලය සති ගණනක් ක්‍රියාත්මකව තිබිය හැකි අතර සෑම රසවත් ප්‍රවාහයක්ම ඉවතට හරියි, සහ සෞඛ්‍ය සම්පන්න ගේට්වේ එකක් නැවත ගොඩනැගීමට මිනිසුන් යොමු කරන්නේ ඒ රටාවයි.
පළමුව පරීක්ෂා කළ යුතු දෝෂ දෙක වන්නේ ESP වෙනුවට AH යෝජනා කරන peer එකක් සහ ගේට්වේ අභ්‍යන්තර ලෙස නොසලකන අවකාශයක අංකනය කළ අතථ්‍ය ජාලයකි.
මාර්ග ස්පර්ශ කිරීමට පෙර අපනයනය කළ ලොගය විවෘත කරන්න
පෝර්ටලයේ අතථ්‍ය ජාල ගේට්වේ විවෘත කර සම්බන්ධතාවය මත VPN troubleshoot ක්‍රියාවලිය ධාවනය කරන්න, පසුව එය නිපදවන බණ්ඩලය බාගත කර විවෘත කරන්න. ඇතුළත 1 වන සහ 2 වන අදියර හුවමාරු සහිත IKE ලොගයක් ඇත, වේලා මුද්‍රා සහිතව සහ සාමාන්‍ය පෙළක් ලෙස කියවිය හැක. ඉහළ සිට පහළට කියවනවා වෙනුවට එහි transform පේළිය සොයන්න, මන්ද රසවත් සටහන සාමාන්‍යයෙන් රේඛා කිහිප සියයක් ඇතුළත පවතී. පෝර්ටලයට ප්‍රවේශය නොමැති නම්, රෝග විනිශ්චය සැකසුම් සක්‍රීයව ඇති විට එම රෝග විනිශ්චය ගේට්වේගේ ලොග ගමනාන්තයේ දිස්වේ.
සටහන් දෙකක් වැඩිපුරම වටිනාකම දරයි. පළමුවැන්න දළ වශයෙන් මෙසේ කියවේ: expected ESP with combined authentication and cipher, received AH. දෙවැන්න IKE හුවමාරුව අතරතුර invalid payload දෝෂයක් වන අතර, එය සාමාන්‍යයෙන් වැරදි ලෙස සකසන ලද හෝ අනුග්‍රහය නොදක්වන යෝජනා ක්ෂේත්‍රයක් අදහස් කරයි.
දෙකම විස්තර කරන්නේ ඔන්-ප්‍රෙමයිස් උපාංගය යෝජනා කළ දේය, එබැවින් දෙකම peer පැත්තේ සැකසුම් වේ. සම්බන්ධතාවයේ Azure පැත්ත නැවත ජනනය කිරීම ඔබේ firewall යවන යෝජනාව වෙනස් නොකරයි, සහ එසේ කිරීම මේ කාර්යයේ වැඩිපුරම නාස්ති වන පැයයි. peer එකේ 2 වන අදියර ඒකාබද්ධ සත්‍යාපනය සහ සයිෆර් සහිත ESP වෙත සකසා ඇල්ගොරිතමය සාකච්ඡා කිරීමට ඉඩ දෙන්න, පසුව combined mode වැනි නමක් ඇති විකුණුම්කරුගේ ලකුණු කොටුවක් යටින් නිශ්ශබ්දව AH යෝජනාවක් තෝරා ගනීදැයි පරීක්ෂා කරන්න.
අතථ්‍ය ජාලයේ ලිපින අවකාශය තහවුරු කරන්න
ගේට්වේ අපේක්ෂා කරන්නේ අතථ්‍ය ජාලය පෞද්ගලික පරාසවල තිබිය යුතු බවයි. පොදු කොටසක අංකනය කළ ජාලයක්, උදාහරණයක් ලෙස 111.x වලින් ආරම්භ වන එකක්, ටනලය ඉහළ නැංවිය හැකි නමුත් Azure එම අවකාශය අභ්‍යන්තර ලෙස සැලකීමට ප්‍රතික්ෂේප කරයි, එබැවින් සම්බන්ධතාවය සෞඛ්‍ය සම්පන්න ලෙස පෙනෙන අතර කිසිදු ප්‍රවාහයක් පිළිගැනෙන්නේ නැත. තෝරක මත දහවල් ගත කිරීමට පෙර ලිපින අවකාශය තහවුරු කරන්න. අංකනය පැරණි වෙන්කිරීමකින් ආ දැඩි අවශ්‍යතාවයක් නම්, විසඳුම වෙනත් ගේට්වේ එකක් නොව ලිපින සැලැස්ම වෙනස් කිරීමයි.
ලිපින අවකාශ පිටුවේ සිටියදීම ඔන්-ප්‍රෙමයිස් පරාස සමඟ ඇති අතිච්ඡාදනය සටහන් කරන්න, මන්ද අතිච්ඡාදනය වන උපසර්ග වෙනස් ආකාරයේ අසාර්ථකත්වයක් ඇති කරන අතර එය සේවාලාභියාට සමාන ලෙස පෙනේ.
උපසර්ග දෙපැත්තෙන්ම තහවුරු කරන්න
දේශීය ජාල ගේට්වේ සම්පත් ඔන්-ප්‍රෙමයිස් උපසර්ග රඳවා ගන්නා අතර ඒවා ඈත උපාංගය සැබවින්ම ආරක්ෂා කරන උපජාලා සමඟ ගැලපිය යුතුය. උපාංගය ඉවතට හරින ලිපින ඇතුළත් සාරාංශයක් සමහර ප්‍රවාහ ගමන් කරවා අනෙක්වා මත අසාර්ථක වන අතර, එය වින්‍යාස නොගැලපීමක් ලෙස නොව කලින් කලට එන මාර්ග දෝෂයක් ලෙස කියවේ. ඈත පසද බලන්න: එක් කෙළවරක් /16 ලැයිස්තුගත කරන අතර අනෙක් පස එහි ඇතුළත /24 තුනක් ලැයිස්තුගත කරයි — එයම සම්භාව්‍ය අර්ධ අසාර්ථකත්වයයි. කිසිදු ලැයිස්තුවක් තනිව බලයලත් නොවේ, එබැවින් ඔබට පෙනෙන එක විශ්වාස කිරීම වෙනුවට දෙකම අසලින් අසල තබා සසඳන්න.
උපසර්ග වෙනස්කමක් සැමවිටම තමන් විසින්ම ග්‍රහණය නොකරයි, එබැවින් සම්බන්ධතා වස්තුව නැවත සුරැකීමට හෝ නැවත නිර්මාණය කිරීමට සැලසුම් කර නව උපසර්ග දෙපසම දිස්වන බව තහවුරු කරන්න.
ping නොව මාර්ගය පරීක්ෂා කරන්න
ක්‍රියාකාරී ටනලයක් ක්‍රියාකාරී මාර්ගයකින් වෙන් කරන trace එක මෙසේ පෙනේ: පළමු hop එක ඔන්-ප්‍රෙමයිස් ගේට්වේ, පසුව පිළිතුරු නොදෙන hop කිහිපයක්, පසුව ඈත සත්කාරකය පිළිතුරු දෙයි. trace කිසිවිටෙක සත්කාරකයට නොපැමිණේ නම්, යෙදුම සැබවින්ම භාවිතා කරන TCP තොටුපොළ පරීක්ෂා කරන්න, මන්ද ICMP ප්‍රමාණවත් ලෙස නිතර පෙරහන් වන බැවින් අසාර්ථක ping එකක් ඉතා අල්පයක් ඔප්පු කරයි. එම trace ඈත සත්කාරකයක සිට Azure හි අතථ්‍ය යන්ත්‍රයක් දෙසට ධාවනය කරන්න. ප්‍රතිඵල දෙක අතර අසමමිතිය නැතිවූ ආපසු මාර්ගයක් හෝ එක් දිශාවකට පමණක් ඉඩ දෙන රීතියක් සොයා ගැනීමට වේගවත්ම ක්‍රමයයි.
peer යෝජනාව, ලිපින අවකාශ දෙක සහ සම්බන්ධතාවය නිර්මාණය කළ වේලාව ටිකට් පතෙහි ලියන්න, එවිට ඊළඟ ඉංජිනේරුවාට කුමන අගයන් නැවත ගොඩනඟන ලදද සහ කුමන ඒවාට කිසිවිටෙක ස්පර්ශ නොකළේදැයි දැනගත හැක.
ලොගය හිස්ව ආපසු එන්නේ නම්, ගේට්වේ ඔබේ සම්බන්ධතාවය කිසිසේත් අවසන් නොකරන තිබිය හැක. දේශීය ජාල ගේට්වේහි peer ලිපිනය ඔබ ලොගය කියවන උපාංගයට ගැලපෙන බව තහවුරු කරන්න, මන්ද එකම දායකත්වයක ගේට්වේ දෙකක් නැවත ගොඩනඟන විට පහසුවෙන් ව්‍යාකූල වේ. එම වැරැද්ද දිනක් වැය කරන අතර කිසිදු ලොගයක සලකුණක් ඉතිරි නොකරයි.