Check Point හෝ Nortel සමඟ vpnc: එය එල්ලී යන්නේ ඇයි

රෝග ලක්ෂණය වැරදි ලෙස කියවීම පහසුය: vpnc ආරම්භ වේ, කණ්ඩායම් මුරපදය ඉල්ලයි, පසුව ඉලක්කයෙන් ප්‍රතිචාරයක් නොමැති බව වාර්තා කරන තෙක් සාකච්ඡා පියවරක රැඳී සිටී. ප්‍රතිදානයේ කිසිම තැනක ද්වාර නිෂ්පාදනය සඳහන් නොවේ, ගිණුම බ්‍රවුසරයෙන් ක්‍රියා කරයි, එබැවින් පෙනෙන නිගමනය වැරදි මුරපදයක් හෝ අවහිර කළ වරායක් ය. මෙම අවස්ථාවන්ගෙන් බොහොමයක ද්වාරය කිසිසේත් IPsec සහකරුවෙකු නොවේ, එබැවින් හුවමාරුව කිසිදා අක්තපත්‍ර පරීක්ෂා කිරීම දක්වා නොපැමිණේ. පැතිකඩෙහි වෙනත් ඕනෑම දෙයක් වෙනස් කිරීමට පෙර මෙම රටාව පරීක්ෂා කිරීම වටී.

තවත් පැතිකඩ ක්ෂේත්‍රයක් සංස්කරණය කිරීමට පෙර නිෂ්පාදනය හඳුනාගන්න.

අසාර්ථකත්වය වැරදි අක්තපත්‍ර ලෙස පෙනේ

vpnc ආරම්භ වන්නේ UDP 500 වෙත IKE යැවීමෙනි, NAT තරණය ඉදිරිපත් කරන්නේ නම් UDP 4500 වෙත ද යවයි. IPsec වෙනුවට SSL අවසන් කරන ද්වාරය දෙකටම පිළිතුරු නොදෙයි, එබැවින් සේවාදායකය නැවත උත්සාහ කර අවසානයේ සාමාන්‍ය දෝෂයක් සමඟ අත්හැර දමයි. එම ගිණුම කුඩා සහායක යෙදුමක් පූරණය කරන බ්‍රවුසර ද්වාරයක් හරහා ක්‍රියා කරන්නේ නම්, එය උමං මාර්ගය SSL මත පදනම් වන බවට සහ සේවාදායකය වැරදි ප්‍රශ්නය අසන බවට ප්‍රබල සංඥාවකි.

මෙහි අසාර්ථක උත්සාහය පරිශීලක ගිණුම ගැන කිසිවක් නොකියයි, මන්ද ද්වාරයට කිසිදා අක්තපත්‍ර ඉදිරිපත් නොකළ බැවිනි.

ද්වාරය ලබා දෙන ප්‍රොටෝකෝලය පරීක්ෂා කරන්න

විනාඩි දෙකක විමර්ශනයක් IPsec සහකරුවා SSL ද්වාරයෙන් වෙන් කරයි. සේවාදායකය භාවිත කරන එම ජාලයෙන්ම ඒවා ධාවනය කරන්න, ලේඛනයක ඇති වරාය නොව පිළිතුරු දෙන වරාය කියවන්න. ප්‍රතිඵලය තබා ගන්න, මන්ද එම වරායන්ම තීරණය කරන්නේ ද්වාර හිමිකරු කුමන සේවාදායකය සහාය දිය යුතුද යන්නයි. ද්වාරය අසල ඇති සත්කාරකයකින් නොව සේවාදායක ජාලයෙන් විමර්ශනය කරන්න.

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

පිවිසුම් පිටුවට යොමු කිරීමක් සහිත විවෘත 443 සහ 500 සහ 4500 මත නිහඬතාව SSL VPN වෙත යොමු කරයි. 443 මත ලබා දෙන සහතිකයක් සමඟ 500 සහ 4500 විවෘත නම්, වෙබ් ඉදිරිපස ද ධාවනය කරන IPsec ද්වාරයක් යැයි යෝජනා කරයි, vpnc නිර්මාණය කළේ එම අවස්ථාව සඳහා ය.

Check Point හි SSL Network Extender සහ Nortel හි Aventail සේවාදායකය දෙකම දෙවන කාණ්ඩයට අයත් වන අතර, කිසිවක් IKEv1 කණ්ඩායම් රහස පිළිගන්නේ නැත.

vpnc පැතිකඩට ප්‍රකාශ කළ හැකි දේ සහ නොහැකි දේ

ඇතුළතින් vpnc කණ්ඩායම් පෙර-බෙදාගත් යතුරකට එරෙහිව IKEv1 ධාවනය කරයි, පසුව XAuth හරහා තනි පරිශීලකයාගේ අක්තපත්‍ර යවයි. එහි වින්‍යාස ගොනුවේ ඇති සියල්ල එම හුවමාරුවට අයත් ය: ද්වාරය, කණ්ඩායම් නම, කණ්ඩායම් රහස, පරිශීලක නාමය සහ පරිශීලක මුරපදය. එම ක්ෂේත්‍ර එක් ප්‍රොටෝකෝලයක් විස්තර කරයි, ඒවායේ කිසිදු සංයෝජනයකට සේවාදායකයට වෙනත් එකක් කථා කිරීමට බල නොකළ හැක.

එබැවින් සයිෆර ලැයිස්තුව පුළුල් කිරීම හෝ සහතික පරීක්ෂා නිවා දැමීම මෙම ආකාරයේ අසාර්ථකත්වය කිසිදා නොවිසඳයි. එම වෙනස්කම් ද්වාරය නොඅසන සාකච්ඡාවක් දුර්වල කරයි.

ද්වාරයට ගැළපෙන සේවාදායකය තෝරා ගැනීම

Check Point ද්වාරයක් සඳහා එම ද්වාර නිකුතුව සඳහා ගොඩනගන ලද SNX පැකේජය භාවිත කරන්න, එය සැපයුම්කරු දුරස්ථ ප්‍රවේශ ලේඛන සමඟ ප්‍රකාශයට පත් කරයි. පැරණි SNX ගොඩනැගීම් වර්තමාන බෙදාහැරීම්වල බොහෝ විට අසාර්ථක වන්නේ තවදුරටත් ස්ථාපිත නොවන 32-bit පුස්තකාල අපේක්ෂා කරන බැවිනි, සහ අත්හැර දැමූ පැකේජයක් පැච් කිරීම සාමාන්‍යයෙන් සහාය දක්වන වේදිකාවක සහාය දක්වන සේවාදායකය ධාවනය කිරීමට වඩා නරක ය.

Aventail සේවාදායකයන් බොහෝ කලකට පෙර සහාය අහිමි කර ගත්හ. එවැනි ද්වාරයක් තවමත් සේවයේ ඇත්නම්, සංවිධානය සක්‍රීය කරන්නේ නම් බ්‍රවුසර ද්වාරය, නැතහොත් සහාය දක්වන මෙහෙයුම් පද්ධතියක සැපයුම්කරුගේ සහාය දක්වන සේවාදායකය යනු යථාර්ථවාදී තේරීම් ය.

ද්වාර හිමිකරුගෙන් නිෂ්පාදනය සහ අනුවාදය, Linux හි ඔවුන් සහාය දක්වන සේවාදායකය, සහ IPsec පැතිකඩක් ඇත්දැයි අසන්න. ඇත්නම්, කණ්ඩායම් හඳුනාගැනීම සහ කණ්ඩායම් රහස වෙන වෙනම අයිතම ලෙස ඉල්ලන්න, මන්ද ඒවා පරිශීලක මුරපදය නොවන අතර මාරු වූ යුගලය අසාර්ථක උමං මාර්ගයක අනෙක් පොදු හේතුවයි. සම්බන්ධතාවය අවසානයේ සාර්ථක වූ විට, කුමන ප්‍රොටෝකෝලය සාකච්ඡා වුණාද යන්න සටහන් කරන්න, එවිට ඊළඟ පුද්ගලයා එම අනුමානයම නැවත නොකර කරුණකින් ආරම්භ කරයි.