ستاسو VPN یوازې د ننوتلو وروسته کار کوي، د کیلي غونډې له امله
ستاسو په غونډه کې کار کوونکی پروفایل د بوټ وخت خدمت نه دی. وګورئ کوم مالک تونل پیلوي، راز چېرې ژوند کوي او ریښتینې پېښه څنګه وازموئ.
امر هغه وخت کار کوي چې تاسو ننوتلي یاست، نو تاسو یې په پیل سکریپټ کې ږدئ او کور ته ځئ۔ بله سهار ماشین آنلاین وي او تونل نه وي۔ افسانه دا ده چې کار کوونکې غوښتنه کار کوونکی خدمت دی۔ په عمل کې توپیر معمولاً له دوو شیانو څخه یو دی: پروفایل ستاسو د کاروونکي غونډې پورې اړه لري نه سیستم ته، یا راز هغه څه خلاصوي چې یوازې ستاسو له ننوتلو وروسته شتون لري۔ دواړه په لاسي ازموینه کې په بشپړ ډول کار کوي او په سمه توګه هغه شیبه ناکامېږي چې هیڅوک نه ګوري۔
ولې ننوتل دا کاروي
ګرافیکي ننوتل یو غونډه بس او د پټو خدمتونو استازی پیلوي، او هماغه ځای کې ډېر ډیسکټاپ ته متوجه کلاینټونه د پروفایل پټنوم یا د خصوصي کیلي پټنوم ساتي۔ له ننوتلو وروسته ستاسو د کاروونکي په توګه چلېدونکې فعالېدنه کولای شي له هغه استازي څخه راز وغواړي او بریالي شي۔ هماغه فعالېدنه چې د بوټ وخت واحد یې ترسره کوي هیڅ غونډه، بس او استازی نه لري، نو پلټنه ناکامېږي یا په داسې غوښتنه بنده کیږي چې هیڅوک نه ګوري۔
هماغه پروفایل د ننوتلو دمخه او وروسته چل کړئ او له یوې تنظیم څخه دوه مختلفې پایلې ترلاسه کوئ۔ دا د مات شوي تونل نښه نه ده، بلکې د اعتبارنامو پورې تړاو نښه ده، او تشریح کوي چې ولې په ټرمینل کې لاسي ازموینه له ښکاره کم څه ثابتوي۔ تونل سم دی؛ هغه څه چې راز یې خلاصوي ورک دی۔
پریکړه وکړئ کوم مالک تونل پیلوي
دوه ملاتړ شوي بڼې شته، او د هغوی ګډول د دې ناکامۍ بله لار ده۔ NetworkManager کولای شي د سیستم کچې اړیکه فعاله کړي، کوم چې هغه وخت مناسبه ده چې ماشین خپله شبکه هلته متمرکزه کړې وي۔ په بدیل سره، یو ځانګړی systemd واحد VPN په مستقیم ډول چلوي او پخپله د انټرفیس مالک دی۔
systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0
دواړه مالکان په یوه تنظیم کې مه چلوئ۔ که NetworkManager انټرفیس مدیریت کړي او واحد یې هم پورته کړي، دوی به پر لارو او DNS جګړه وکړي، او پایله یې د دې پورې اړه لري چې څوک وروستی پای ته ورسېد۔
راز هغه ځای کېږدئ چې خدمت یې لوستلی شي
د شالید خدمت نشي کولای غوښتنې ته ځواب ووایي۔ د سند پټنومونه، د حساب پټنومونه او راجع شوي تصدیق فایلونه ټول داسې زېرمې ترتیباتو ته اړتیا لري چې واحد پرته له انسان ورته ورسېږي، د هغه حساب ملکیت وي چې خدمت چلوي او نورو ټولو لپاره نالوستونکی وي۔
زړه راښکونکې لنډه لار دا ده چې فایل تر هغه پورې د ټولو لپاره لوستونکی کړئ چې د اجازې تېروتنه ورکه شي۔ دا د پیل ناکامي له اوږدمهاله اعتبارنامې افشا سره بدلوي، او دا د هغه بدلون ډول دی چې هیڅوک بیا نه ګوري۔ هغه میکانیزم وکاروئ چې ږغونه پرې مخکې باور لري: محدود اعتبارنامې فایل، نه کوډ شوې کیلي چې د فایل اجازو له خوا ساتل کیږي، یا د سیستم کچې اړیکه چې خپله پټه زېرمه ولري۔
هغه پېښه وازموئ چې واقعاً پېښیږي
د ننوتلو وروسته د خدمت لاسي پیلول تقریباً هېڅ نه ازموي۔ بیا پیل کړئ، یا د یوې دورې لپاره ګرافیکي ننوتل غیرفعال کړئ، او وګورئ چې واحد پخپله پورته کیږي۔ دا یوازینۍ ازموینه ده چې د اعتبارنامې شتون، د شبکې چمتووالی او د واحدونو ترتیب یوځای تمرینوي۔ دا هغه ازموینه هم ده چې کاروونکي راپور ورکړې ناکامي بیا تولیدوي، کوم چې لاسي پیل هېڅکله نه کوي۔
systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager
ترتیب هم د اعتبارنامو په اندازه مهم دی۔ واحد چې د بنسټیز پورتنۍ اړیکې له تنظیم دمخه پیل شي تسلیم شي، او ځینې وېشونه په دې کې توپیر لري چې آیا د اړیکې انتظار کوي۔ که واحد د بوټ پر مهال ناکامي راپور کړي خو کله چې دېرش ثانیې وروسته لاسي پیل شي بریالی شي، تاسو د راز نه، بلکې د ترتیب ستونزه موندلې ده۔
نه یوازې انټرفیس، لارې او DNS وګورئ
شته انټرفیس کار کوونکی تونل نه دی۔ له بې څارنې پیل وروسته، د نوم له کتلو دمخه لارې، د حل کوونکي حالت او د پتې له مخې یو هدف وګورئ۔ بیا هغه اپلیکیشن وګورئ چې تونل د هغه لپاره شته۔
ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'
که پته کار وکړ او نوم نه، پاتې ستونزه د DNS پالیسي ده نه تونل۔ ولیکئ چې کوم مالک خدمت پیلوي او راز چېرې ژوند کوي، ځکه بل څوک چې دا ماشین بیا پیل کړي دواړه حقایق ته اړتیا لري۔