د اړیکې ردېدل د سند ستونزه نه ده: د VPN چلونې لارښود

کلاینټ وایي چې د CRL له بیا جوړولو سملاسي وروسته اړیکه رد شوه، نو CRL ګناهګار ښکاري. داسې نه ده. ردېدل د لېږد طبقې ځواب دی، او د سند تصدیق وروسته، د تونل د لاس ورکولو په دننه کې ترسره کېږي. د وخت سمون شرایط دي، نه ثبوت.

دوه کتنې قضیې په یوه دقیقې څخه کم وخت کې بېلوي، او هیڅ یوه یې هم د باور تنظیماتو ته لاس نه ورکوي.

تېروتنه په هغه طبقه کې ولولئ چې هغه یې پیدا کړې

له connect څخه ECONNREFUSED یعنې د لېږد هڅه رد شوه: یو څه د reset سره ځواب ورکړ، یا سټک د نه رسېدونکي پورټ راپور ورکړ. د سند ستونزه نشي کولی دا تېروتنه پیدا کړي، ځکه چې د لېږد اړیکې پرته TLS لاس ورکول هېڅکله نه پیلېږي. که ردېدل ووینئ، کلاینټ هغې مرحلې ته هم نه دی رسېدلی چې سند وړاندې کړي. همدا یوه حقیقت لغوه کول د لامل په توګه بېلوي.

برعکس هم سم دی. لغوه شوی سند بشپړه TCP اړیکه او ناکام لاس ورکول پیدا کوي، چې په سرور کې د تصدیق تېروتنې په توګه ثبتېږي.

د TCP ردېدل: هیڅوک نه اوري

د TCP لپاره، وګورئ چې پام شوی انسټانس روان دی او په پروفایل کې د پتې او پورټ سره تړلی دی. ss -lntp اورېدونکي ښیي، او د یو نه شتون عادي توضیح دی. هغه فایر وال چې د غورځولو پر ځای ردوي، د کلاینټ په خوا کې هماغه پیغام پیدا کوي، نو ځکه دواړه کتئ.

د پتې کورنۍ هم وګورئ. هغه خدمت چې 127.0.0.1 یا یوازې IPv6 سره تړلی وي، هغه کلاینټ به رد کړي چې بل ته حل کېږي.

بیا د اټکل پر ځای د خدمت لاګ ولولئ. د CA له ساتنې وروسته بیا پیل کېدل ممکن په نه لوستل کېدونکي یا ورک فایل کې ناکام شي او هېڅکله د اورېدو حالت ته ونه رسېږي، او لاګ د فایل نوم اخلي. دا د پیل ناکامي ده، د رد شوي سند څخه بېله تېروتنه.

UDP د ردولو لپاره لاس ورکول نه لري

UDP باندې OpenVPN د TCP په مانا اړیکه نه جوړوي، نو د connect په وخت کې د ردولو څه نشته. په Linux کې، هغه تېروتنه چې د UDP ساکټ ښیي ممکن د پخوا ډیټاګرام لخوا پیدا شوي ICMP port-unreachable څخه راشي. د udp(7) لارښود پاڼه همدا غیر همغږي چلند بیانوي.

نو ځکه UDP کلاینټ ممکن ردېدل چاپ کړي کله چې د سرور بهیر روان وي خو د تمه شوې پتې سره نه وي تړلی.

CRL په رښتیا چېرته کتل کېږي

CRL د TLS لاس ورکولو په جریان کې، وروسته له دې چې مخالف لوري خپل سند وړاندې کړ، او یوازې هغه وخت چې د سرور ترتیبات اجازه ورکړي، مشوره کېږي. د OpenVPN crl-verify انتخاب فایل ته اشاره کوي، او ناکامي په سرور لاګ کې د سند نوم اخیستونکې تصدیق تېروتنې په توګه ښکاري.

نو ځکه لغوه شوی کلاینټ په لېږد طبقه کې نښلېږي او بیا په تصدیق کې ناکامېږي. هماغه سرور، هماغه پورټ، بشپړ بېل پیغام.

کله چې دې مرحلې ته ورسېدئ، د CRL صادروونکی او د اعتبار نیټې وګورئ. هغه CRL چې غلط CA لاسلیک کړی، یا هغه چې د کلاینټ له نښلېدو دمخه پای ته رسېدلی، د تصدیق تېروتنې پیدا کوي چې د کلاینټ د خپل سند سره هېڅ تړاو نه لري.

بل ځل لپاره لنډ لارښود

لومړی لېږد تایید کړئ: اورېدونکی شته، سمه پته کورنۍ، فایر وال رد نه کوي. بیا د پیل لاګ لوستلو سره تایید کړئ چې خدمت د اورېدو حالت ته رسېدلی. او بیا یوازې د تصدیق پیغامونو لپاره د لاس ورکولو تېروتنې وګورئ. دا ترتیب ثابت وساتئ، ځکه هر ګام د لاملونو یوه بشپړه طبقه لرې کوي.

لېږد، حل شوې منزل، پورټ او د تېروتنې دقیق متن ولیکئ. د کلاینټ بیا نصبول هغه ثبوت له منځه وړي او معمولاً هېڅ نه بدلوي.