ولې OpenVPN د لپ ټاپ له ویښېدو وروسته مري؟

ماشین په خوب کې کیږدئ، بیا یې ویښ کړئ، او بیا د هر ترتیب د لاس وهلو دمخه په دې ترتیب سره درې شیان وګورئ: آیا tun0 لا هم شته، آیا داخلي پتې ته لاره لا هم هغه غوره کوي، او آیا سرور لا هم دا peer لیستوي۔ هغه وسیله چې له خوبه ژغورل کیږي خو لاره بل ځای ته اشاره کوي، پاتې شوی شی دی، نه تونل۔ کله چې لاره سمه وي او ترافیک سره له دې مري، نو خطا د تونل پورته ده او د کلاینټ بیا پیل کول به یې نه بدلوي۔ د بیا پیل اتومات کول یوازې هغه وخت معنا لري چې لاسي ازموینه وښيي چې له دې دریو کومه حالت لرئ۔

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

د اتومات کولو دمخه ویښېدل بیا تولید کړئ

خوب ډېری وخت کوډ شوې غونډه پای ته رسوي، نه دا چې وسیله لرې کړي۔ هغه UDP بهیر چې تونل ژوندی ساتل کېده بند شي، سرور کېدای شي peer وغورځوي، او کلاینټ یا دا ویني او بیا نښلوي یا هغه انټرفیس ساتي چې شاته یې هېڅ نشته۔ یوازې د انټرفیس کتنه ډېر لږ ثابتوي، ځکه زوړه وسیله په بشپړ ډول د کار کوونکې وسیلې په څېر ښکاري تر هغه چې پیکټونه دې له هغې تېر شي۔ د لارې پلټنه او له تونل څخه یوه ریښتینې غوښتنه وچلوئ، بیا د ویښېدو شېبې شاوخوا ژورنال ولولئ۔

که کلاینټ پخپله بېرته راشي، هنګامه د باور پر ځای اضافي ګډوډي ورزیاتوي۔ که هېڅکله روغ نشي، اتومات کول هغه ریښتینی حل دی۔

د systemd د خوب هنګامه واقعاً چېرته ده

ډېر زاړه لارښودونه /etc/pm/sleep.d ته اشاره کوي، دا هغه فولډر دی چې pm-utils یې مالک دی او systemd-based خوب هېڅکله ورسره مشوره نه کوي۔ systemd هنګامې له /usr/lib/systemd/system-sleep/ او /etc/systemd/system-sleep/ څخه لولي، لومړی پړاو او بیا عملیات ورکوي، نو pre او post یوازینې هغه ارزښتونه دي چې هنګامه پرې څانګه کوي۔ محلي کاپي د /etc لاندې وساتئ، د بسته شوي فایل د سمولو پر ځای، او په یاد ولرئ چې سکریپټ د بدلون په منځ کې د root په توګه ځي، نو باید ژر بېرته راشي۔

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart یوازې هغه وخت واحد ته لاس ورکوي چې لا دمخه فعال وي، نو هغه تونل چې تاسو په قصد بند کړی و په ویښېدو کې هم بند پاتې کیږي۔ --no-block هنګامه له دې څخه منع کوي چې د کلاینټ د خبرو اترو پر مهال انتظار وکړي، دا هغه وخت مهم دی چې شبکه لا نه وي پورته شوې۔ دواړه بیرغونه یوځای هغه هنګامه مانا کوي چې په خاموشۍ کې ناکامه شي، نه دا چې ټوله ویښېدو لړۍ وځنډوي۔ کله چې واحد لا دمخه ودرول شوی وي، هېڅ هم نه پیښیږي، او دا هغه پایله ده چې هلته یې غواړئ۔

خدمت بېرته راوړئ، tun0 پرېږدئ

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

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

هغه وخت مدیریت کړئ چې کنټرول یې نه شي کولی

بې تار نښلونه او DHCP ډېری وخت له هنګامې وروسته بشپړیږي، نو بیا پیل کېدای شي ناکام شي په داسې حال کې چې سرور ته لاره لا نه وي۔ هغې پتې ته لږ انتظار وکړئ، یو ځل بیا هڅه وکړئ او پایله ثبت کړئ۔

د نومونو حل یوه جلا سیالي ده، ځکه چې د ډیسکټاپ شبکه سټک کېدای شي DNS هغه وخت بېرته راوړي چې تونل لا دمخه پورته وي۔ پلټنې جلا په resolvectl query internal.example سره وازموئ، د دې پر ځای چې له کار کوونکې لارې یې اټکل کړئ۔ هغه تونل چې سمه لاره ټاکي او هېڅ نه حل کوي، د DNS ستونزه ده، د هنګامې ستونزه نه۔

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