د OpenVPN هغه DNS چې ټېل وهل شوی له پامه غورځول شوی: کومه برخه یې پلي کوي

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

ټېل وهل شوی اختیار وړاندیز دی، نه نصب

په سرور کې دوه لارښوونې اراده بیانوي، نه اغېزه:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

کلینټ ترتیب شوی ریزولور نه ترلاسه کوي۔ هغه د چاپېریال بدلونکي ترلاسه کوي، foreign_option_1 او وروستي، د هر ټېل وهل شوي کرښې لپاره یو، او یو څه سیمه‌ییز باید هغه ولولي او د عملیاتي سیستم د ریزولور حالت بیا ولیکي۔ په Linux کې په ډیفالټ توګه هیڅ شی داسې نه کوي، نو سم سرور او نښلول شوی کلینټ لا هم کولی شي نومونه د LAN له لارې حل کړي۔

د دوو سرونو ترمنځ درې پړاوونه دي: ټېل وهل باید ورسېږي، کلینټ باید ښکاره کړي، او هوک باید پلي کړي۔ منځنی پړاو د کلینټ په لاګ کې او وروستی پړاو د ریزولور په حالت کې ولولئ، هیچ کله هم برعکس نه، ځکه چې د لاګ یوه کرښه یوازې لومړني دوه ثابتوي۔

بډايه شئ چې ټېل وهل ورسېدل او مالک یې ومومئ

پیل د لانچر په نومولو وکړئ: یو لوڅ openvpn کمانډ، یو systemd بېلګه، NetworkManager یا د پلورونکي کلینټ۔ دا ټاکي چې هوک چېرې اوسېدلی شي۔ په systemd-resolved لرونکي هوسټ کې، resolvectl status هره اړیکه د هغو DNS سرورونو او لټون ډومېنونو سره لیستوي چې واقعاً یې کاروي، او د تونل اړیکه تل tun0 نه بلل کېږي۔

که ټېل وهل شوی پته په لاګ کې وي خو په هیڅ اړیکه کې نه، نو یوځای والی نشته۔ که په اړیکه کې وي او پوښتنې لا هم بل ځای ته ځي، ستونزه دا ده چې کومې پوښتنې هغه اړیکه ټاکي۔ NetworkManager dns=dnsmasq په فایل کې /etc/NetworkManager/NetworkManager.conf یو سیمه‌ییز لېږدونکی چلوي چې ویشل شوی DNS په قصد پلي کوي: د VPN ډومېن دننه نومونه VPN ریزولور ته ځي، نور هر څه خپله پخوانۍ لار ساتي۔ دا چلند کله چې تمه ولرئ ټول ترافیک ځای بدل کړي، د نیمګړتیا په څېر ښکاري؛ د هرې اړیکې تنظیمات وګورئ nmcli connection show "My VPN" سره، چېرې چې ipv4.dns او ipv4.dns-search د وسیلې د راپور شوو شیانو شاته ارزښتونه ساتي، مخکې له دې چې نیمګړی یې وبولئ۔ که هره پوښتنه واقعاً باید VPN ریزولور ته ورسېږي، لرې کړئ dns=dnsmasq له NetworkManager.conf فایل څخه او NetworkManager بیا پیل کړئ، چې د نومونو حل کول د اړیکې تنظیماتو ته بېرته ورکوي؛ که نه، ویشل شوی DNS وساتئ او ټېل وهل شوې ډومېن لیست سم کړئ۔

Linux: اختیارونه ریزولور ته وسپارئ

د وېش پیکېجونه د دې لپاره هوک وړاندې کوي، او کلینټ ته باید د هغه د چلولو اجازه وي۔ په هوسټ کې پرته له systemd-resolved معمول ترتیب:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

له systemd-resolved سره زوړ resolv.conf سکریپټ ممکن مهم شی بدل نکړي، ځکه چې stub ریزولور د هرې اړیکې حالت ساتي۔ update-systemd-resolved مرستندوی د هوک بڼه مستندوي چې کاروي up-restart او down-pre, چې کله یوه انټرفېس له یوې اړیکې هڅې ډېر ژوندی پاتې شي مهم دی۔ هر څه چې وټاکئ، یوه برخه باید د حالت مالک وي۔ د NetworkManager ترڅنګ د بې‌اړیکې هوک زیاتول یوې اړیکې ته دوه لیکونکي ورکوي، او نتیجه بیا ستاسو له ترتیباتو نه، بلکې له ترتیب څخه په تړاو ده۔

دا هم شونې ده چې NetworkManager ټېل وهل شوی اختیار په بشپړه توګه له پامه غورځولی وي تر هغه چې د سرور پته د اړیکې IPv4 تنظیماتو کې ولیکل شوه، بیا ریزولور حالت وښوده چې کارول کېږي۔ د سکریپټونو بیا لیکلو مخکې د آزمویړنې وړ ده، ځکه ستونزه د شل هوک څخه هغه اړیکې پروفایل ته لېږدوي چې تونل مخکې له مخکې وړي۔

Windows او macOS بېلې برخې پلي کوي

د Windows کلینټ واقعاً د VPN اډاپټر DNS سرورونه ټاکي، خو Windows لا هم د میټریک له مخې انټرفېس ټاکي او لا هم لنډ نوم پراخولو لپاره پسوند ته اړتیا لري۔ پروفایل نه، د اډاپټر حالت تایید کړئ:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

که پته نشته، په دې یې ټاکئ Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, بیا پسوند د اډاپټر IPv4 ځانګړنو ته زیات کړئ ترڅو fileserver شي fileserver.corp.example۔ د ټول ماشین SearchList ارزښت Tcpip\Parameters لاندې هماغه کار کوي۔ چېرې چې اوږد نوم حل کېږي او لوڅ نه، ریزولور مخکې له مخکې سم دی او ګناه د لټون لیست ده۔ سمونې په ترتیب سره: ټېل ووهئ یو DOMAIN ترڅو کلینټ پسوند زده کړي، هغه پسوند د اډاپټر یا اړیکې لټون لیست ته زیات کړئ، او د لنډمهاله اقدام په توګه نوم په دې کې ټینګ کړئ hosts فایل کې، یا LMHOSTS کې پر Windows؛ NetBIOS ګړنه روټر نه تېرېږي، نو هغه خپرونه چې د دفتر LAN کې لنډ نوم مومي هیچ کله د تونل کلینټ ته نه رسېږي۔

block-outside-dns block-outside-dns د Windows کلینټ چلند دی، نه د لېږد وړ پروفایل کرښه، او Linux یا macOS پروفایل ته کاپي کول یې هلته بیا نه جوړوي۔ که پر Windows عام نومونه کار وکړي او داخلي ناکام شي، د پرمختللو تنظیماتو لاندې د اډاپټرونو ترتیب له دې سره پرتله کړئ ipconfig /all۔ په macOS کې د هر خدمت ریزولور ترتیب سیستم ته اړه لري، نو وکاروئ scutil --dns ترڅو وګورئ کوم ډومېن لپاره کوم ریزولور پوښتل کېږي، او هر یوازینی راپور شوی پروفایل سمون د عمومي نه، بلکې کلینټ ته تړلی وګڼئ۔

په همدې لپ‌ټاپ کې مجازي ماشین له دې څخه هیڅ نه میراث اخلي۔ میلمه ته د داخلي ډومېن لپاره خپله ریزولور ننوتنه ورکړئ، یا پرېږدئ چې د هایپر وایزر NAT د هغه پوښتنې د هوسټ له لارې ولېږي، چې یوازې تر هغه سمه ده چې د هوسټ تونل فعال وي۔

تاریخ درېیم لامل دی۔ د پخواني پروفایل DNS سرورونه یا پسوند تنظیمات کولی شي د بیا نښلولو څخه پاتې شي، نو کله چې اډاپټر سم ښکاري او لټونونه لا هم ناکامېږي، ژوندی اډاپټر له دې سره پرتله کړئ Get-VpnConnection او سرور ته د لاس وروړلو مخکې زوړ ننوتنه پاکه یا بیا ولیکئ۔

ثابت کړئ چې پوښتنه چېرې لاړه

د یوې لټون په جریان کې نیول بحث ختموي: tcpdump -ni eth0 port 53 په فزیکي انټرفېس کې پوښتنې ښیي، یعني هغه له تونل څخه بهر وځي او ریزولور هیچ کله نه بدل شو۔ dig @10.8.0.1 name.corp.example بیا پاتې دوه حالتونه جلا کوي۔ که مستقیمه پوښتنه ځواب ورکړي، ریزولور کار کوي او کلینټ یې نه کاروي؛ که وخت تېر شي، ریزولور د تونل له لارې نه‌رسېدونکی دی او هیچ سیمه‌ییز بدلون به مرسته نه کوي۔

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

رسېدنه پکې د VPN هوسټ فایروال هم شامل دی، چې باید له حوض څخه UDP او TCP 53 ته اجازه ورکړي۔ بند پورټ سم د مات شوي ټېل وهلو په څېر ښکاري، او همدارنګه هغه ریزولور چې یوازې د تونل شبکې له دننه ځواب ورکوي۔ د یو ځل نښلولو پرېکولو او بیا نښلولو وروسته نیول بیا کړئ، ځکه هغه تنظیمات چې په لومړي نښلولو کې ښکاري او په دویم کې ورک شي، د هوک د ژوند دورې نیمګړتیا ده، نه ورکه اختیار۔

یو مالک وساتئ او په ترتیب سره تایید کړئ

هغه سکریپټ چې د اټکل شوي تونل حالت له مخې د اډاپټر DNS بیا لیکي، هغه ترتیبات دوه ځله کوي چې پروفایل مخکې له مخکې وړي، او لومړی ځل چې اټکل غلط وي په خاموشۍ ناکامېږي۔ د اړیکې خپل DNS تنظیمات یا یو مستند هوک غوره کړئ، او ولیکئ چې کوم یې ټاکلی ترڅو بل کس دویم زیات نه کړي۔

د څلورو ګوتو/کنټرولونو سره حلقه بنده کړئ: ټېل وهل شوې پته د تونل اړیکه کې موجوده، داخلي نوم د بشپړ وړ نوم په توګه حل کېږي، هماغه نوم پرته له پسوند حل کېږي، او د یوې بیا نښلونې وروسته دواړه لا سم دي۔ یو نیول وایي چې له څلورو کوم ناکام شو۔ د OpenVPN 2.6 لارښود لیستوي dhcp-option او د سکریپټ لارښوونې د هغوی د پلیټ‌فارم یادښتونو سره۔