VPN په خپل پورټ کې هېڅ ځواب نه ورکوي، او دوه ممکن لاملونه مخالف ترمیم غواړي: یا هېڅ پروسه سوکیټ نه دی خلاص کړی، یا سوکیټ شته او د ماشینونو ترمنځ څه پاکټونه بندوي. یوه کمانډ د دې پوښتنې لومړۍ نیمه فیصله کوي، نو ځکه له هر اوروال قاعده مخکې راځي. لاندې ترتیب هر ګام کې یوه تشریح لرې کوي، نه بله اټکل ورزیاتوي. همدا د دواړو ترمنځ اټکل کول لس دقیقې تشخیص یوه بشپړه ماښام جوړوي.

فرض وکړئ چې تاسو سرور ته ننوتلای شئ او کلاینټ سکنر نه، بلکې ریښتینی پروفایل دی. دواړه فرضونه مهم دي، ځکه عمومي پروب د پروتوکول ځانګړې پوښتنې ځواب نه شي ورکولای.

ایا سوکیټ لږ تر لږه شته

له هغه څه پیل وکړئ چې خدمت د خپل ځان په اړه وایي: ایا پورته شو او، ډېر ګټور، لومړنی پیل غلطي یې څه وه. د پارس ناکامي، ورک شوی کیلي یا د تړلو غلطي اورېدونکي ته د رامنځته کېدو اجازه نه ورکوي، او پروسه کولای شي دومره په غلې پټه ووځي چې د حالت کرښه مبهمه ولوستل شي. هغه واحد چې ځان فعال ښیي په خپله ثبوت نه دی، ځکه اصلي پروسه ژوندې کېدای شي پداسې حال کې چې هغه برخه چې باید پورټ وتړي مخکې له مخکې تسلیم شوې وي.

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

د سوکیټ لیست هغه واقعیت دی چې پاتې تشخیص پرې ولاړ دی. د ځایي پتې کالم ولولئ نه یوازې پورټ، ځکه په همدې کالم کې لوپ بیک تړل او په غلط انټرفیس تړل ښکاري. هغه اورېدونکی چې په 127.0.0.1 شته، بشپړ کار کوي او سره له دې ستاسو لیپ ټاپ ته نه ښکاري.

سوکیټ په کومه پته او کوم کورنۍ ځواب وایي

دوه غلطۍ د کلاینټ له اړخه یو شان ښکاري او ډېری "نه رسیږي" راپورونه تشریح کوي. لوپ بیک پتې ته تړل شوی سرور هېڅکله له بل ماشین څخه ترافیک نه اخلي، او یوازې IPv4 پتې ته تړل شوی سرور هېڅکله هغه کلاینټ ته ځواب نه وایي چې د همدې کوربه IPv6 پته ډایل کوي. له پالیسۍ په اړه هر څه فرض کولو مخکې د سوکیټ جدول پته له هغې پتې سره توري په توري پرتله کړئ چې کلاینټ یې واقعاً ډایل کوي.

لیست یوې پورټ ته محدودول هغه وخت لوستل کېدونکی ساتي چې کوربه څو خدمتونه چلوي. د sport فلټر پورټ له هغه ټرانسپورټ سره اخلي چې تاسو یې ازموئ:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

د پروتوکول کالم ټول ځواب بدلوي

د سوکیټ جدول له پورټ سره سره پر پروتوکول هم کیلي کیږي، او دا دوه خپلواکې ننوتنې دي. هغه خدمت چې په 1194 کې TCP ته ځواب وایي، د دې په اړه څه نه وایي چې آیا څه په UDP 1194 اورېدل کیږي، او کلاینټ به تل یوازې یو له دوی څخه کار اخلي. تایید کړئ چې د سرور کنفیګریشن کوم ټرانسپورټ ټاکي او د کلاینټ پروفایل کوم لیږي، بیا هماغه کرښه ولټوئ.

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

یوه هڅه، د کتلو درې ځایونه

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

دوې پایلې مخالف لوري ته اشاره کوي. که هېڅ پاکټ کوربه ته ونه رسېده، لاره یې غورځوي او اورېدونکی بې ربطه دی. که پاکټ سوکیټ ته ورسېد او خدمت یې رد کړ، لاره سمه ده او ځواب په پروتوکول، کرپټوګرافي یا اعتبار پاڼو کې دی. د هغه خدمت لپاره پورټ خلاصول چې مخکې یې اړیکه منلې، بله تشخیص ستونزمنوي نه اسانه.

له قاعدې بدلولو مخکې پړاو ونوموئ

هغه خبرې چې پیل کیږي او هغه تصدیق چې ناکام کیږي یوه خرابي ده، او هغه ټونل چې د لیږد د بندېدو پر مهال جوړیږي بشپړه بله ده. د پړاو مخکې نومول ترمیم تنګ ساتي: د اعتبار پاڼو ستونزه د اوروال قاعدې سره نه جوړیږي، او د معلوماتو د لارې ستونزه د بیا پیل سره نه جوړیږي.

تر ټولو تنګه هغه تشخیص وکاروئ چې پوښتنې ته ځواب وایي. په یوه پورټ د پاکټونو لنډمهاله کتنه، د یوه مدیر تر کنټرول لاندې، مناسبه وسیله ده؛ ټول اوروال بندول نه، ځکه پایله د چا سره تړل ناشونده کیږي. د ss اسناد پورتنۍ کارول شوې فلټرې رانغاړي، او دا له هر نیولو ارزانه لومړی ګام دی. ولیکئ چې له دوه څانګو کومه مو ثابته کړه، او بله پېښه له یوې معلومې ځواب څخه پیل کیږي.

اړوندې مقالې