OpenVPN نه پیل کیږي: لومړی کرښه ولولئ، نه ترتیبات

هغه VPN چې په لومړۍ ثانیه کې مري، له هغه چې نښلول کیږي او بیا ناکام شي یو بل مخلوق دی، او معمول غلطي دا ده چې دواړه یو ډول وګڼل شي۔ دلته نه لاس ورکول دي، نه د سندونو تبادله او نه د کتلو لپاره کومه لار۔ په ژورنال کې یوه کرښه ټاکي چې له څو بې تړاوه ترمیمونو کوم یو عملي کیږي، او له هغې تېریدل د یوې ماسپښین په اوږدو کې د یوې داسې ترتیب د سمون لامل کیږي چې هیڅکله نه لوستل شوې۔ لومړی هغه کرښه ولولئ۔

د یوازې لوستلو درې کمانډونه تاسو هلته رسوي: لومړی journalctl -u openvpn@server -b --no-pager، بیا systemctl status openvpn@server، او د UDP اورېدونکو او د هغوی د مالکانو لپاره ss -lunp۔

لومړۍ کرښه څانګه ټاکي

د پورټ شخړه او نیمګړی باینري دواړه پیل په یوه ثانیه کې وژني، او بېلابېلې لومړنۍ کرښې پرېږدي۔ هغه پیغام چې پته لا دمخه کارول کیږي پورټ نوموي؛ نیمګړی اجرایوي فایل هغه لار نوموي چې نوره نشته؛ ناکام شرط یا نیمګړی د ترتیباتو فایل فایل نوموي۔ دا درې بېلابېلو ترمیمونو ته رسوي، او د دوی له جملې هیڅ یو د کلاینټ په بیا نصبولو نه ښه کیږي۔ له بل هر څه چلولو دمخه لومړنی ناکامي په خپلو یادښتونو کې کاپي کړئ۔

هغې بیا هڅې حلقې ته پام وکړئ چې اصلي کرښه پټوي۔ هغه یونټ چې د بیا پیل تګلاره لري کولای شي لومړنۍ ناکامي د لسګونو ورته ناکامیو لاندې ښخ کړي، نو له یونټ سره فلټر شوی او له پورته لوستل شوی journalctl -b له لکۍ غوره دی۔

بل څوک 1194 پورټ نیولی دی

مجرم معمولاً هغه دویم سرور نه دی چې چا په قصد جوړ کړی وي۔ د بل ټرمینل په کې لا ژوندی په لاس پیل شوی کلاینټ، هغه دویم پروفایل چې همدا پورټ یې ټاکلی، یا د پلورونکي هغه بنډل چې خپله ټونل یې 1194 نیولی دی، تمه یې وکړئ۔ د سوکټ مالک په ss -lunp کې ښکاري؛ هغه PID systemctl status ته ورکړئ ترڅو پوه شئ چې ایا کوم یونټ مسؤل دی۔ له سیګنال پرته، د هغه د خپل کنټرول لارې له لارې یې ښکته کړئ۔

د یونټ لخوا مدیریت شوي پروسې ته سیګنال معمولاً بیا پیل رامنځته کوي، او هماغه ناکامي څو شیبې وروسته د نوي ستونزې په څېر بیا څرګندیږي۔ یونټ لپاره systemctl stop، د پلورونکي نصب لپاره د بنډل خپل خدمت کمانډ، او سیګنال یوازې هغه څه لپاره چې تاسو پخپله په لاس په هغه شل کې پیل کړی وي وکاروئ۔

د حذف وروسته پاتې یونټونه

حذف باینري ګانې پاکوي؛ په لاس لیکل شوي د یونټ فایلونه، معمولاً د /etc/systemd/system لاندې، له هغې ژوندي پاتې کیږي۔ بیا Systemd هغه یونټ چې نوره نشته لار ته اشاره کوي بیا هڅه کوي، او پیغام د پرون حذف په اړه نه، بلکې د هغه نیمګړي فایل په اړه دی۔ systemctl status د یونټ د ټوټې لار د پورتنۍ برخې نږدې ښیي، نو له هر څه حذفولو دمخه یې په dpkg -S سره وګورئ۔ کله چې یتیم ولاړ، systemctl daemon-reload او systemctl reset-failed حالت پاکوي؛ که نه، هر وروستنی حالت کتنه یې په میراث اخلي۔

کله چې which openvpn د /usr/local لاندې څه ځواب کړي، هغه باینري چې په کار ده له apt نه نه، بلکې د پلورونکي د نصب کوونکي څخه راغلې۔ داسې نصب کوونکی معمولاً خپل اورېدونکی، خپل د پیل ثبت او خپله د ترتیباتو پوښۍ راوړي، نو د ښکاره کمانډ حذفول سوکټ بوخت پرېږدي۔

لکه څنګه چې پلورونکی سند کوي هغسې یې غیر نصب کړئ، په ss -lunp سره تایید کړئ چې پورټ ازاد دی، او د ویش کلاینټ یوازې هغه وخت ورزیات کړئ چې اړتیا یې لرئ۔

د بیا هڅې دمخه حالت سم کړئ

له هغه څخه د پایلو اخیستلو دمخه ناکام حالت پاک کړئ: systemctl reset-failed کاونټرونه لرې کوي، او بیا systemctl status د یونټ تاریخ نه، بلکې اوسنی حالت راپور کوي۔ یو ځل یې پیل کړئ او د ماشین ټولیز حالت نه، بلکې د هماغه چلېدو خپل ژورنال ولولئ۔ هغه یونټ چې فعال ښکاره کوي په داسې حال کې چې ټونل څه نه وړي، جلا ستونزه ده او ډیره عامه۔ دواړه د غلطیو راپورونو کې یو ځای کیږي ځکه دواړه د کارونکي په دې وینا پای ته رسي چې VPN کار نه کوي۔

هغه څانګه یاد کړئ چې ټاکلې مو ده: د پورټ شخړه، نیمګړی باینري، نیمګړي ترتیبات۔ بل ځل به پېژندل ګړندي وي۔