vpnc د Check Point یا Nortel پر وړاندې: ولې بند پاتې کېږي

نښه په اسانۍ غلطه لوستل کېږي: vpnc پیلېږي، د ډلې پټنوم غواړي، بیا د خبرو اترو په یوه پړاو کې ناست وي تر څو چې راپور ورکړي چې له هدفه څخه هېڅ ځواب نه راځي۔ په پایله کې هېچېرې د دروازې محصول نه یادېږي، او حساب له براوزر څخه کار کوي، نو ښکاره پایله غلط پټنوم یا بند پورټ دی۔ په ډېرو دغو حالتونو کې دروازه په بشپړه توګه IPsec ملګری نه دی، نو تبادله هېڅکله د اعتبارنامې ازموینې ته نه رسېږي۔ دا بڼه د پروفایل په بل هر څه بدلون دمخه د ازموینې وړ ده۔

د پروفایل بل ساحه سمولو دمخه محصول وپېژنئ۔

ناکامي د غلطې اعتبارنامې په څېر ښکاري

vpnc د IKE په UDP 500 ته لېږلو پیلېږي او که د 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 ته اشاره کوي۔ پرانیستي 500 او 4500 چې پر 443 وړاندې شوی سند لري، IPsec دروازې ته اشاره کوي چې ویب مخ هم چلوي، او vpnc هماغه حالت لپاره جوړ شوی و۔

د Check Point SSL Network Extender او د Nortel Aventail کليانټ دواړه په دویمه کټګورۍ کې دي، او هېڅ یو یې د IKEv1 ډلې پټ راز نه مني۔

د vpnc پروفایل څه بیانولی شي او څه نه

د پړکالاندې، vpnc IKEv1 د ډلې د مخکې شریک شوي کلي په وړاندې چلوي، بیا د انفرادي کارن اعتبارنامه د XAuth له لارې لېږي۔ په خپل تنظیم فایل کې هر څه هماغه تبادلې ته اړه لري: دروازه، د ډلې نوم، د ډلې پټ راز، کارن نوم او کارن پټنوم۔ دغه ساحې یو پروتوکول بیانوي، او د هغوی هېڅ ترکیب نشي کولی کليانټ اړ کړي چې بل پروتوکول ووايي۔

نو د کوډونو لیست پراخول یا د سندونو کتنې بندول هېڅکله دا ډول ناکامي نه سمولي شي۔ دغه بدلونونه هغه خبرې اترې کمزورې کوي چې دروازه ورته غوږ نه نیسي۔

د دروازې سره سم کليانټ ټاکل

د Check Point دروازې لپاره هماغه SNX بنډل چې د دې دروازې خپرېدنې لپاره جوړ شوی وکاروئ، چې عرضه کوونکی یې د لرې لاسرسي سندونو سره یوځای خپرېږي۔ زاړه SNX جوړښتونه په اوسنیو وېشونو کې ډېری ناکامېږي ځکه چې 32-bit کتابتونونه تمه لري چې نور نه دي نصب شوي، او پرېښودل شوي بنډل پیچ کول معمولاً له دې څخه بدتر دي چې ملاتړ شوی کليانټ په ملاتړ شوي پلیټ فارم کې وچلېږي۔

Aventail کليانټونه ډېر پخوا ملاتړ له لاسه ورکړ۔ چېرې چې داسې دروازه لا هم په خدمت کې ده، واقعي غوراوي براوزر پورتال دي که سازمان یې فعال کړي، یا د عرضه کوونکي ملاتړ شوی کليانټ په ملاتړ شوي عملیاتي سیستم کې۔

د دروازې له مالک څخه محصول او نسخه، هغه کليانټ چې په Linux یې ملاتړ کوي، او دا چې آیا په اصل کې IPsec پروفایل شته که نه وپوښتئ۔ که وي، د ډلې پېژند او د ډلې پټ راز د دوو جلا توکو په توګه وغواړئ، ځکه دا د کارن پټنوم نه دی، او بدل شوې جوړه د ناکام تونل بله عامه لامل ده۔ کله چې اړیکه بالاخره بریالۍ شي، ولیکئ چې کوم پروتوکول پرې خبرې وشوې، تر څو بل کس د هماغه اټکل تکرارولو پر ځای له یوې واقعیت څخه پیل وکړي۔