OpenVPN پرته له تېروتنې نه پیلېږي؟ journal وګورئ

امر بیرته راځي، خدمت ناکام ښکاري، او ترمینل ته د تشریح په څېر هېڅ نه رسېږي۔ دا غلې چوپتیا هغه نښه ده چې خلک یې «OpenVPN نه پیلېږي» بولي، او دا تقریباً هېڅکله نه معنا لري چې پروګرام پرته له دې چې څه ووایي مړ شو۔ معنا یې دا ده چې پیغام هغه چینل ته لاړ چې تاسو نه لوستل، یا هغه څه چې تاسو پیل کړل هغه نه و چې تاسو تنظیم کړی و۔ د پروفایل د شکمن ګڼلو له پریښودو وروسته دواړه حالتونه په یوه دقیقه کې هم تشخیص کېدای شي۔

پایلې څلور ځایونه جذبوي: د unit journal، هغه پلګین چې اړیکه لري، د تونل بل سر، او له هغه څخه بېل باینري چې تاسو فکر کوئ چلېږي۔ هر یو خپله څېړنه لري۔

چوپتیا معنا لري چې تاسو سم چینل نه کتل

د مخکیني پلان غوښتنه ستاسو ترمینل ته چاپ کوي۔ unit journal ته چاپ کوي، او ناکام unit کولای شي له دې مخکې ووځي چې څه ولیکي، که ناکامي په دې کې وي چې څنګه پیل شو، نه په هغه څه کې چې ورته وویل شول۔ دا توپیر مهم دی: په journal کې د ننوتلو نه موجودیت معنا لري چې بهیر هېڅکله واقعاً ونه چلېد، پداسې حال کې چې یو ننوتل او بیا وتل معنا لري چې چلېد او یو څه یې رد کړل۔

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

د پاک وتلو او سیګنال توپیر لپاره دا اضافه کړئ: systemctl show -p Result -p ExecMainStatus openvpn-client@office۔ حالت 1 او Result=exit-code د پروګرام پریکړه ده؛ Result=signal یا ټایم آوټ پرځای چاپېریال ته اشاره کوي، او د پروفایل کومه سمون به یې هم نه بدلوي۔ د هر څه د بیا پیلولو مخکې دواړه ارزښتونه ولیکئ، ځکه بیا پیل هغه لنډمهاله حالت پاکوي چې دوی یې تولید کړي وو۔

د instance نوم د لارې برخه ده

بسته شوی ټیمپلیټ unit د فایل لار نه اخلي۔ دا د instance نوم اخلي، او هغه نوم د پروفایل موندلو لپاره یوې ډایرکټرۍ ته ورزیاتېږي: office په Debian او Ubuntu بسته کې /etc/openvpn/client/office.conf ته حل کېږي۔ office-v2.conf نوم لرونکی فایل چې @office په توګه پیل شي هېڅکله نه لوستل کېږي، او unit په چوپتیا وځي ځکه چې د هغې له نظره د کولو څه نه وو۔ د لټون ډایرکټري د client او server حالتونو ترمنځ توپیر لري، نو هماغه تېروتنه د ټیمپلیټ بدلولو پر مهال بشپړ بل ځای ته اشاره کوي۔

همدا ناسم والی د غلې ناکامۍ ترټولو عامه سرچینه ده، او په پروفایل کې نه ښکاري ځکه چې پروفایل سم دی۔ ولیکئ چې واقعاً څه شته او دوه نومونه توري په توري پرتله کړئ، له هر هغه غځېدنې سره چې بسته یې تمه لري۔

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

که unit فعال وي خو هېڅ instance نه وي لیست شوی، فعالول یې پخپله کېدای شي هغه نوم ته اشاره وکړي چې وروسته بدل شوی۔ سم instance بیا فعالول معمولاً کافي دي، او پاتې شوی زوړ unit فایل د پاکولو ارزښت لري څو بل کس ګډوډ نه کړي۔ پاتې unit فایل یوه کوچنۍ خبره ده چې وروسته یو چا ته یو ساعت لګښت دی۔

کله چې پلګین د تونل خاوند وي، ترمینل هېڅ نه ویني

هغه اړیکه چې د ډیسکټاپ اپلیټ څخه پیلېږي د NetworkManager ملکیت دی، او د هغې OpenVPN پایلې هغه خدمت journal ته ځي نه ستاسو خلاص شوي shell ته۔ کلاینټ په لاس چلول او هېڅ نه لیدل په دې ترتیب کې تمه کېږي، ځکه په لاس چلېدونکی بهیر هغه نه دی چې اړیکه پورته کوي۔

په journal کې هغه خدمت ولټوئ چې دا لري، بیا پارس کول په هغه تفصیل سره تکرار کړئ چې تاسو یې لوستلای شئ۔ لاندې دوه امرونه د هماغه ناکامۍ بېلابېلو خاوندانو ته ګوري۔

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

جلا چلول د پیغامونو لوستلو لپاره دي، نه د مدیریت شوې اړیکې بدلولو لپاره، او دواړه وروسته توپیر لري: DNS ادغام، لارې او عمر د پلګین دي۔ په جلا چلولو کې د پارس تېروتنه سمول د اپلیټ د کنټرول اخيستلو وروسته د نومونو حلول په اتوماتيک ډول نه سمونکي دي، نو دواړه مشاهدې جلا وساتئ۔

دوه باینري، یو PATH

په لاس جوړ شوی نصب چې /usr/local لاندې وي د shell غوښتنې کې ګټي، ځکه /usr/local/sbin د Ubuntu ډیفالټ PATH کې له /usr/sbin مخکې راځي۔ unit ستاسو PATH نه کاروي؛ دا هغه مطلق لار چلوي چې په ExecStart کې لیکل شوې۔ نو هغه نسخه چې ستاسو ترمینل کې کار کوي او هغه نسخه چې د خدمت په توګه ناکامه کېږي واقعاً بېلابېل پروګرامونه کېدای شي۔

د هر څه بیا جوړولو مخکې دواړه پرتله کړئ۔ دریم امر هماغه دی چې بحث فیصله کوي۔

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

یو بل چاپېریالي توپیر په هماغه ځای کې پټ دی۔ بسته شوی unit /run لاندې د systemd هغه رنټایم ډایرکټرۍ ته تکیه کوي چې د هغې لپاره جوړوي؛ په لاس لیکل شوی بدیل unit چې هغه تنظیم پرېږدي کېدای شي له یو فایل خلاصولو مخکې ناکام شي، او ناکامي د OpenVPN پیغام پرته عمومي رد په څېر ښکاري۔

هغه ناکامۍ چې کلاینټ یې نه شي راپور کولای

ځینې پایلې په لرې سر کې فیصله کېږي۔ هغه ګېټوې چې د HTTP حالت سره ځواب ورکوي او اړیکه بندوي تاسو ته د خپل حالت په اړه ویلي، او بل ګټور ګام ستاسو محلي فایلونه نه دي، بلکې د هغې لاګ یا د اعتبار وروسته حساب دی۔ په هغه سناریو کې محلي هېڅ خراب نه دی، او د جبر لپاره د پروفایل سمول بله تشخیص سختوي۔ د کلاینټ تنظیماتو ته له لاس وهلو مخکې هغه لاګ ولولئ۔

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

پوړونه په ترتیب سره کاروئ: unit شته او د instance نوم سم دی، journal ته یا --log فایل ته څه رسېدلي، کوم باینري او پروفایل واقعاً چلېدلي، او ناکامي محلي ده که لرې۔ هر ځواب یو پوړ لرې کوي۔ له پروفایل څخه پیلېدل معنا لري هغه فایل بیا لیکل چې کېدای شي هېڅکله نه وي خلاص شوی۔