تاسو تونل ګورئ، systemctl status openvpn چلوئ او پرته له Main PID او د پروسس خالي لیست سره active (exited) ترلاسه کوئ۔ طبیعي لوستل دا دي چې خدمت پیل شو او مړ شو، نو تاسو unit پرانیزئ، /bin/true ومومئ او نتیجه اخلئ چې پیکج خراب دی۔ په Debian پیکج کې هغه حالت wrapper دی چې لکه څنګه چې ډیزاین شوی کار کوي، او تونل په هغو instance unit کې ژوند کوي چې هغه پیلوي۔ ټول unit به هیڅکله ونه وایي چې کوم انسټنکس دا جوړ کړ۔

په دې unit کې active (exited) واقعاً څه معنی لري

پیکج شوی unit یوه یوځله دنده ده: د هغې ExecStart /bin/true دی، او RemainAfterExit=yes هغه څه دي چې بشپړ شوی unit د active (exited) په توګه راپور شوی ساتي۔ هغه لارښوونه لرې کړئ او هماغه بریالۍ /bin/true دنده په inactive (dead) پای ته رسېږي، کوم چې ټاکلې هغه حالت دی چې خلک یې تمه لري او په مخالف لوري یې غلط لولي۔ امر یوازې ځای نیونکی دی، او unit د هغو کارونو راپور ورکوي چې نور unit یې کوي۔ په دې ترتیب کې هېڅ خراب نه دی، او د /bin/true بدلول تونل نه، بلکې د پیکج تړون بدلوي۔

wrapper استازیتوب کوي۔ هغه instance unit پیلوي چې د پیکج ترتیب یا د هغې systemd جوړونکی برابروي، له همدې امله خالي پروسس لیست د تونل په اړه هېڅ ثابت نه کوي۔ کله چې هېڅ انسټنکس نه وي ټاکل شوی، wrapper بیا هم بریالی کېږي او بیا هم هېڅ نه پیلوي۔ حالت ځواب ورکوي چې wrapper وچلو که نه، نه دا چې تونل شته که نه۔

د status د وتلو درې کرښې ولولئ، نه په قوس کې کلمه۔ Loaded هغه unit فایل نوموي چې systemd لوستی، Active د وروستي بریالي چل د وخت نښه لري، او د Main PID نه شتون له بشپړ شوې یوځله دندې سره سمون خوري۔ هماغه درې کرښې د دې wrapper د پیلېدو یوه ثانیه وروسته لوېدلې خدمت څخه د توپیر کولو لاره هم ده۔

له status بیا لوستلو دمخه unitونه لیست کړئ

له دې مخکې چې وپوښتئ څه روان دي، له systemd وپوښتئ څه شته۔ کېدای شي ټیمپلیټ نصب وي خو هېڅ انسټنکس جوړ شوی نه وي، او یوازې جوړ شوی unit تونل لري۔ له بار شوي سیټ څخه پیل کړئ:

systemctl list-units 'openvpn*'

هغه لیست هغه څه دي چې systemd په دې شیبه بار کړي، او د تونل لیست ته تر ټولو نږدې دی۔ نصب شوي unit فایلونه بلې پوښتنې ته ځواب ورکوي، او کله چې هېڅ جوړ نه وي هغه لیست بیا هم ټیمپلیټ ښیي:

systemctl list-unit-files 'openvpn*'

دواړه لیستونه یوځای ولولئ، ځکه چې په دوهم کې ټیمپلیټ او په لومړي کې انسټنکس دوه بېل ځوابونه دي۔ شته ټیمپلیټ او روان انسټنکس یوه حقیقت نه دی، او یوازې دوهم تونل معنی لري۔ د پیکج ترتیبات د توزیعونو او OpenVPN نسخو ترمنځ هم توپیر لري۔ زوړ openvpn@ ټیمپلیټ، جلا client او server جوړه، او د توزیع wrapper ټول کولای شي په خپل پیکج کې قانوني وي۔

له خپل ماشین سره سمون وکړئ، نه له هغه ټیوټوریل سره چې موندلی یې۔ د بل چا په وتلو کې د انسټنکس نوم office کېدای شي، پداسې حال کې چې ستاسو home یا work دی۔ لیږدول کېدونکی شی طریقه ده، نه سټرینګ۔

د انسټنکس نوم تعقیب کړئ تر هغه فایل چې هغه لولي

په upstream client ټیمپلیټ کې د unit کاري ډایرکټري /etc/openvpn/client ده او د هغې امر له هغه ځایه %i.conf اخلي، نو openvpn-client@office /etc/openvpn/client/office.conf لولي۔ دا نقشه په نصب شوي unit کې تایید کړئ نه دا چې مثال ته باور وکړئ، ځکه ستاسو ټیمپلیټ ممکن زوړ یا د توزیع بیا لیکل شوی وي:

systemctl cat [email protected]

د هغه وتلو په لاندې برخه کې ښکاره شوي drop-in ولولئ، ځکه چې د .d/ لاندې فایل کولای شي ExecStart، کاري ډایرکټري یا د ترتیب لاره بدله کړي۔ هغه پروفایل چې تاسو د office.ovpn په نوم ډاونلوډ کړی هغه فایل چې انسټنکس پرانیزي نه دی۔ همدا تشه معمولاً هغه لاره نوموي چې تاسو هیڅکله نه ده سمه کړې۔

د پروفایل دننه نسبي لارې بله تله ده۔ اصلي فایل لېږدول پداسې حال کې چې ca، cert او key حوالې نسبي پاتې وي، د ورک فایل تېروتنه په بله ورک فایل تېروتنه بدلوي۔ دوهمه هغه فایل ته اشاره کوي چې تاسو ډاډه واست چې شته، له همدې امله د پروفایل ډایرکټري د فایل له نوم مهمه ده۔

هغه پیل کړئ، بیا د هماغه انسټنکس ژورنال ولولئ

هغه انسټنکس پیل کړئ چې همدا اوس مو کتلی، ځکه د ټول unit لاګ به د تونل تېروتنې ونه لري۔ بیا د دې بوټ ژورنال ولولئ او په همدې ترتیب کې د ترتیب تېروتنه، د فایل لاسرسي تېروتنه او د اړیکې تېروتنه ولټوئ، ځکه هر یو یې د پیل په بېل پړاو کې ناکامېږي۔

sudo systemctl start [email protected]
journalctl -u [email protected] -b

پیلول او فعالول بېلې پرېکړې دي: start unit اوس چلوي، enable بله بوټ ترتیبوي، او enable --now دواړه په یوه ګام کې کوي۔ daemon-reload د unit تعریفونه بیا لولي او روان پروسس بیا نه پیلوي او سم شوی پروفایل نه پلي کوي۔ له پروفایل بدلولو وروسته انسټنکس بیا پیل کړئ، ځکه فایل بیا لوستونکی هماغه دی۔

په هماغه تونل باندې دوهم مدیر مه ږدئ

NetworkManager او OpenVPN 3 د سیسشن مدیران خپل د اړیکې حالت لري، او د دوی ترڅنګ systemd انسټنکس په هماغه تونل دوه مالکان ږدي۔ نښه دا ده چې تونل پورته کېږي او څو ثانیې وروسته بدلېږي، یا د درېدو لپاره پاتې کېدو څخه انکار کوي۔ هغه مدیر وټاکئ چې ستاسو توزیع یې د ډیسکټاپ لپاره مستند کوي، او په سرور کې systemd په قصد سره وکاروئ۔

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

د اصلي پوښتنې ځواب د انسټنکس نوم، هغه فایل چې لوستی یې او هغه ژورنال کرښه چې ناکامه شوې، سره ورکړئ۔ د systemd ادغام په اړه د OpenVPN یادښتونه د ټیمپلیټ ترتیب او هغه فایل نقشه بیانوي چې د انسټنکس نوم پر مټ حل کېږي۔

اړوندې مقالې