OpenVPN یو DNS سرور ولېږه، خو Linux یې نه مني

لېږل شوی DNS سرور په لاګ کې دی، تونل پورته دی، او داخلي نومونه لا هم ناکامېږي۔ په خود لېږلو کې هېڅ خراب نه دی؛ ترتیبات ورسېدل او هماغه ځای ودرېدل۔ لېږل شوی DNS انتخاب پیرودونکي ته پیغام دی، نه د عملیاتي سیستم ریزالور ته لارښوونه، او د دې دواړو ترمنځ سپارل هغه ځای دی چې ډېری دا قضیې هلته پای ته رسېږي۔ پنځه څېړنې، په ترتیب سره، هغه سپارل مومي چې نه دی شوی۔

لومړۍ څېړنه: اړیکه څنګه پیلېږي

د اړیکې مالک ټاکي چې څوک کولی شي د ریزالور ترتیبات پلي کړي۔ له شیل څخه مستقیم openvpn امر پرته له خپل پروسې هېڅ نه لري، خو systemd واحد، NetworkManager یا د پلورونکي پیرودونکی هر یو خپله لاره لري چې DNS خپور کړي۔ له دې څخه د یوې انګېرنې مخکې د پروسو لیست او د واحد نوم ولولئ۔

د کمانډ کرښې پروسه په اتوماتيک ډول NetworkManager اړیکه نه ده، او NetworkManager اړیکه په اتوماتيک ډول هغه شی نه دی چې resolv.conf یې لیکلی۔ دا دوه انګېرنې په دې پلټنه کې د ضایع شوو ساعتونو ډېره برخه تشریح کوي۔ وپوښتئ چې تاسو ته د ریښتیني ښکاره کېدونکي انټرفېس لپاره کومه برخه DNS خپروي۔

له دوام مخکې مالک ولیکئ۔ هرې وروستۍ څېړنې پرې تکیه کوي۔

دویمه څېړنه: د ریزالور لینک واقعاً څه لري

په systemd-resolved کوربه کې، resolvectl status هر لینک د خپلو DNS سرورونو او ډومینونو سره لیست کوي۔ د تونل لینک ومومئ او د هغې ننوتنې ولولئ، او مه انګېرئ چې انټرفېس tun0 نومیږي، ځکه شمېرنه د جوړېدو ترتیب تعقیبوي۔ که لېږل شوی پته په لینک کې نه وي، سپارل ناکام شو، نه پوښتنه۔

که پته شتون ولري، بیا راتلونکې پوښتنه دا ده چې هغه لینک کوم ډومینونه غواړي۔ پرته له ډومین لیست لینک یوازې هغو نومونو ځواب ورکوي چې مستقیم ترې پوښتل کېږي، او split-DNS ځای پر ځای کول دا کله ناکله غواړي۔ یوازې پته اړینه ده، خو بس نه ده۔

له هرې پایلې مخکې د ریزالور په تولید کې د لینک نوم د VPN لاګ کې د انټرفېس نوم سره پرتله کړئ۔ هلته ناسم والی معمولاً معنا لري چې د لاګ کرښه له بلې پروسې څخه راغلې۔

درېیمه څېړنه: آیا د نومونو فضا هغه لینک ټاکي

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

د ډومین ګمارل وګورئ، نه یوازې د سرور پته۔ هغه ډومین چې ~corp.example ته ورته لیکل شوی لارښوونکی ډومین دی، او ټیلډ بدلوي چې نوم څنګه سره سمون خوري۔

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

څلورمه څېړنه: یو مالک، نه دوه

که NetworkManager لا دمخه VPN او د ریزالور حالت مدیریتوي، د نامرتبط hook سکریپټ اضافه کول سیال لیکونکي جوړوي۔ هغه hook چې بسته یې systemd-resolved لپاره برابروي، ملاتړ شوی ادغام دی، او ټاکلی ژوند چرخه غواړي: script-security 2، د up لار، up-restart، د down لار او down-pre۔ هغه انتخابونه لامل کېږي چې ثبت او لرې کول یوازې په لومړنۍ اړیکه کې نه، بلکې په سم وختونو کې وشي۔

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

د یوه وېش د ریزالور سکریپټ سمول ترڅو د هغې د تولید هدف بدل شي، د یوه کوربه د حل لارې ثبتوي۔ دا عمومي ترمیم نه دی۔

پنځمه څېړنه: له بیا نښلولو وروسته هماغه پایله

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

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