openfortivpn په دوامداره توګه DNS بیا لیکي؟ ریښتینی مالک ومومئ

اړیکه له هغې شیبې تعقیب کړئ چې پورته راځي: کاروونکی تصدیق کوي، pppd خبرې اترې کوي، او بیا یو څه د DNS تنظیمات عملیاتي سیستم ته لیکي. که یوازې پدې پوه شئ چې VPN ستاسو حل کوونکی بدل کړ، لا هم نه پوه شئ چې د هغو مرحلو کوم یو دا کار کړی. دوه یې کولی شي، او په هغه کاروونکي چې مستند pppd یوځایوالی کاروي دوی دومره نږدې چلیږي چې لکه یو ګډونوال ښکاره شي. د لیکونکي نوم اخیستل لومړی ګام دی؛ د هغه بدیل ټاکل دویم دی، او دا د خپلو ناکامۍ لارو سره جلا پرېکړه ده.

لاندې ترتیب کاروونکی بهر ته تعقیبوي: اړیکې څه بدل کړل، کوم سویچ کوم لیکونکی ځپي، څوک باید مسؤلیت واخلي، او څنګه تایید کړئ چې پایله له بیا نښلېدو سره ټینګه پاتې کیږي. هر ګام بېل نښه پرېږدي، او هغه نښه ده چې تاسو ته وایي لېږد واقعاً وشو که نه.

له هغه څه پیل کړئ چې اړیکې واقعاً بدل کړل

د خپل معمول حکم سره یو ځل ونښلئ او د مخکې او وروسته حل پرتله کړئ. په systemd-resolved چلونکي Linux کوربه کې، resolvectl status د هرې اړیکې لپاره DNS سرورونه او د لټون ډومینونه چاپوي، او هغه نوی tun یا ppp اړیکه چې خپل سرورونه لېږدوي د کاروونکي خوا ته د تازه کېدو د ګوتو نښه ده. په macOS کې، scutil --dns د حل کوونکي ترتیب په هغه ترتیب ښیي چې غوښتنلیکونه ورسره مشوره کوي.

دا د هغه فایل سره پرتله کړئ چې تاسو یې بدلېدل تمه درلوده. په هرې اړیکې کې د اړیکې تړلی ننوتل او بیا لیکل شوی /etc/resolv.conf دوه بېلې پایلې دي، او دویمه کېدای شي یو سمبوليک تړون وي چې یو بل څه یې په بشپړه توګه مدیریت کوي. د حل کوونکي پته، د لټون ډومینونه او د انټرفیس نوم په هماغه شیبه ثبت کړئ؛ په هر یو کې بدلون بل لیکونکي ته اشاره کوي. پرته له دې بنسټ کرښې، هر وروستی سمون د دې اټکل دی چې له دریو برخو کومه یوه ښویه شوه.

دوه سویچونه او هغه لیکونکی چې هر یو یې ځپي

openfortivpn د انتخابونو یوه ټوټه مستندوي چې هغه دواړه لیکونکي بندوي چې کنټرول یې کولی شي، او هر سویچ بشپړ لیکل شوی سیالي لري چې لارښود یې ورته تنظیم ګڼي.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns کاروونکی له دې منع کوي چې هغه DNS سرورونه پلي کړي چې له ګېټوې څخه یې زده کړي، پداسې حال کې چې --pppd-no-peerdns pppd له دې منع کوي چې د سیال DNS په سیستم کې دننه کړي. د upstream لارښود خبرتیا ورکوي چې د PPP له لارې DNS تازه کېدل کېدای شي د کاروونکي خپلو DNS تازه کېدو سره سیالي وکړي، نو ځکه دواړه سویچونه باید په ټوټه کې وي، نه دا چې یو یې کافي وګڼل شي.

هیڅ سویچ د بدیل حل کوونکي نوم نه اخلي، او هیڅ یو د شبکې مدیر، DHCP کاروونکي یا جلا VPN یوځایوالي مخه نه نیسي چې وروسته حل ولیکي. د دوو لیکونکو ځپل ساحه پرانیستې پرېږدي، نه مالکیت لرونکې. که دریمه برخه لا دمخه DNS مدیریت کوي، ټوټه هغه څه نه بدلوي چې تاسو یې لیدلی شئ؛ که هیڅ شی یې مدیریت نه کوي، تاسو همدا اوس د شخصي نومونو حل یوازینی سرچینه لرې کړه. دا یوازې هغه وخت سم ترتیب دی چې بدیل مالک لومړی وټاکل شي او په جلا توګه وازمویل شي.

له دې مخکې چې هر څه غیر فعال کړئ مالک وټاکئ

لومړی پرېکړه وکړئ چې د کاري نومونو پوښتنو ته څوک ځواب وایي، ځکه هغه انتخاب وروسته هر څه محدودوي. شته حل کوونکی ساتل پدې معنا دي چې شخصي زون باید له هغه ځایه چې کاروونکی کېني دمخه د لاسرسي وړ وي، او په دفتر کې دننه شخصي حل کوونکی داسې لار ته اړتیا لري چې د تونل پورته کېدو ته ټینګه پاتې شي. هرې پوښتنې یو داخلي خدمت ته لېږل دریمه تګلاره ده چې تېره ناکامۍ لاره لري: کله چې هغه خدمت د لاسرسي وړ نه وي، عام نومونه د شخصي نومونو سره یوځای ناکام کیږي.

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

حل د هرې اړیکې لپاره وګورئ، د هر فایل لپاره نه

په محدود یا هر ډومین حل لرونکي کوربه کې چې غوښتنلیکونه واقعاً څه کاروي د هغې لیست یو /etc/resolv.conf نه دی، نو د حل کوونکي حالت هغسې ولولئ چې پلیټ فارم یې ښکاره کوي.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

کله چې اړیکه پورته شوه یو شخصي نوم او یو عام نوم وپوښتئ، او ولیکئ چې کومې اړیکې هر یو ته ځواب ورکړ. چېرې چې VPN اړیکه د هر ډومین لټون لیست لېږدوي، شخصي نوم کېدای شي په سمه توګه حل شي پداسې حال کې چې عام نوم لا هم ځایي حل کوونکي ته ځي، او دا وېش ناکامي نه ده، بلکې کار کوونکی ډیزاین دی. که شخصي پوښتنه ناکامه شي، له بیا DNS لمس کولو مخکې حل کوونکي ته لاره وګورئ؛ که هغه بریالۍ شي خو غوښتنلیک لا هم ناکام شي، غوښتنلیک ممکن خپل کیش شوی یا جلا تنظیم شوی حل کوونکی لولي.

بیا ونښلئ او د جلا شوي حالت تایید وکړئ

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

بیا ونښلئ او هماغه درې ارزښتونه ولولئ: د حل کوونکي پته، د لټون ډومینونه، انټرفیس.

که هغه ستاسو لیکل شوې تګلارې سره سمون ولري، لېږد بشپړ دی او VPN کاروونکی نور د لیکونکو څخه یو نه دی. که د اړیکې له پورته کېدو څو ثانیې وروسته یو ارزښت بیرته وښویږي، یو بل څه لا هم ترتیب پلي کوي، او بل ګام دا نه دی چې بله بیرغ اضافه کړئ، بلکې هغه برخه پیژندل دي. هغه وروستی حالت چې تاسو یې غواړئ پیښې نه لري: یو مالک، یوه مستنده تګلاره، او یو جلا شوی کوربه چې په سمه توګه هغسې حل کوي لکه مخکې چې تونل شتون درلود.