تونل وصل کېږي، بیا د لاسرسي لینک پر سر د کرایې نوی کول هغه وژني، او لاګ د لارې پر ځای د وخت پای ته تور لګوي۔ د VPN په ترتیباتو کې هېڅ نه دي بدل شوي، او همدا نښه ده: له هغې بهر یو څه بدل شوي۔ د DHCP یوې پېښې پته یا ګېټوې بیا ولیکله، او هغه هوسټ لار چې د تونل پای نقطه یې رسېدونکې ساتله اوس د بل هغه ګام ته اشاره کوي چې نور نشته۔ دا د لارښوونې له ستونزې مخکې د مالکیت ستونزه ده۔

نښه د نیمګړو ډیفالټ لارو سره پرتله کړئ

د redirect-gateway def1 سره، OpenVPN د ډیفالټ لارې د بدلولو پر ځای 0.0.0.0/1 او 128.0.0.0/1 نصبوي۔ دواړه یوځای ټول پته تشیال پوښي، او یوازې د مخکښ اوږدوالي له مخې 0.0.0.0/0 ته ماتې ورکوي۔ نو له همدې امله له لا ځانګړي سمون پرته هر هدف تونل ته ننوځي۔

پای نقطې ته یوه استثنا غواړي۔ OpenVPN د نیمګړو ډیفالټونو له ننوتلو مخکې د اصلي لاسرسي ګېټوې له لارې د سرور پتې ته د هوسټ لار ورزیاتوي، ترڅو پوښل شوي کڅوړې ووځي۔ کله چې هغه استثنا ورک شي، یا هغه بل ګام وساتي چې نور نشته، د تونل خپلې بهرنۍ کڅوړې له نیمګړي ډیفالټ سره سمون خوري او بېرته تونل ته لېږل کېږي۔ پایه یې هغه اړیکه ده چې په بل keepalive یا لاس ورکولو کې مري، او په لاګ کې د لارښوونې د تېروتنې په څېر هېڅ نه ښکاري۔

له بل هر څه لاس وهلو مخکې د جدول بڼه تایید کړئ۔ ip route show باید دواړه نیمې او د سرور پتې لپاره یوه هوسټ لار ولیکي؛ کله چې هوسټ لار نه وي، د پاتې څېړنې لپاره روښانه پیل ټکی شته۔

ولې نیمګړي ډیفالټونه پرته له متریک بدلون بریالي کېږي

ټیټ متریک اوږد مخکښ نه شي ماتولای۔ د /1 لارې بریالۍ کېږي ځکه چې کرنل لومړی تر ټولو ځانګړې لاره سره سمون خوري، نو پر ډیفالټ لار د متریک لوړول په دې کې هېڅ نه بدلوي چې تونل ته روان ترافیک چېرته ځي۔ د متریکونو پسې منډې وهل په دې تشخیص کې تر ټولو عام غلط بل ګام دی۔

د ip route get 203.0.113.10 سره انتخاب وګورئ، او په هغه کې د سرور ریښتینې پته ځای پرځای کړئ۔ ځواب هغه انټرفېس او بل ګام نوموي چې کرنل به واقعاً کاروي، او دا له جدول لوستلو او پر هغه فکر کولو څخه ډېر معلوماتي دی۔

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

یو نه، درې سکرین شاټونه واخلئ

د لاسرسي پته، د لاسرسي ګېټوې، د پای نقطې هدف، ټاکل شوې لار او هر ډول پالیسي قاعده په درېوو شیبو کې راټول کړئ: د لاسرسي لینک له ترتیب وروسته، د VPN له وصلېدو وروسته، او د کرایې یا اپراتور له پېښې وروسته۔ هر سکرین شاټ یو څو کمانډه دي، او یوازې یوځای معنا لري۔ له ناکامۍ وروسته یو سکرین شاټ بدلون نه، بلکې حالت ثبتوي۔ کمانډونه په یوه کوچني سکریپټ کې ولیکئ ترڅو هر سکرین شاټ په یوه طریقه واخیستل شي۔

سکرین شاټونه په یوه فایل کې د وخت نښو سره وساتئ، ځکه وروسته زړه راښکونکی پوښتنه ترتیب دی۔ د DHCP پېښه د OpenVPN د خپلې لارې له تازه کولو مخکې راغله که وروسته؟ ځواب پرېکړه کوي چې څوک یې سمول غواړي۔ د غلط ساعت وخت نښه له نه شتون څخه بدتره ده، نو هغه له هغه هوسټ څخه واخلئ چې د لارښوونې جدول لري۔

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

پرېکړه وکړئ چې کومه برخه استثنا تازه کوي

په dhcpcd سیستم کې، هنګونه د هنګ فولډر او د وتلو هنګ څخه چلېږي، او د مدیر حالت په پراخه کې د هر انټرفېس له حالت څخه توپیر لري۔ هنګ هر څه چې کوي، باید idempotent وي، ځکه نوي کېدل کېدای شي په ډلو راشي۔

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

مالک په ترتیباتو کې ثبت کړئ۔ بل څوک چې بیا اړیکه ډیبګ کوي باید پوه شي چې د استثنا لار مسؤلیت پر VPN نه، بلکې پر هنګ دی۔

یوازې بیا اړیکه نه، بلکې د ژوند دوره وګورئ

د dhcpcd -n eth0 سره یا د کرایې په خوشې کولو او بیا اخیستلو نوی کېدل اجباري کړئ، بیا د پای نقطې لپاره ip route get بیا وګورئ۔ دا دوه ځله وکړئ، ځکه دوهم پړاو هغه هنګونه نیسي چې دوه ځله لارې ورزیاتوي۔ بیا بیا پیل کړئ، ځکه دوام له سم والي څخه بېله ځانګړنه ده۔

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

اړوندې مقالې