ولې د روټر خپل DNS د VPN تونل څخه تېرېږي؟

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

د پاکټ ثبت واقعاً کوم بهیر ته اړه لري

یوه پوښتنه دوې تبادلې لري۔ LAN کلاینت د روټر حلکوونکي ته پوښتنه لېږي، او هغه د LAN انټرفېس پر لېږدول شوي ترافیک په توګه رارسېږي، نو د لېږدول شوو پاکټونو لپاره لیکل شوې د پالیسۍ لار یا NAT قاعده ورسره سمون خوړلی شي۔ بیا روټر له کیش راهیسې ځواب ورکوي، یا که نه وي، خپله پوښتنه پورته سرور ته پرانیزي۔

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

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

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

که د ساکټ لیست یو اورېدونکی وښيي چې له loopback یا LAN پتې سره تړلی وي، روټر بل هوسټ ته د لېږدولو پرځای په محلي توګه ځواب ورکوي۔ بیا ثبت ښيي چې پایله لرونکې پورتنۍ پوښتنه د تونل انټرفېس له لارې وځي که د WAN له لارې، او دا هغه ځواب دی چې د پالیسۍ لار قاعده به هېڅکله نه ورکاوه۔

ولې د پالیسۍ لار دوهمه پوښتنه هېڅکله نه ویني

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

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

pfSense حلکوونکی خپله پورتنۍ لار چېرته ټاکي

pfSense دا وېش ښکاره کوي۔ د کلاینت ترافیک د پالیسۍ لارې له مخې د VPN دروازې له لارې تېرولی شو، خو د اور دیوال خپل ترافیک د LAN قواعدو پرځای د حلکوونکي د وتلو تنظیم تعقیبوي۔ په وېب انټرفېس کې هغه تنظیم Services > DNS Resolver > Outgoing Network Interfaces لاندې دی، او ارزښت یې د هغو انټرفېسونو لیست دی چې حلکوونکی یې د پورتنو پوښتنو لپاره کارولی شي۔

هلته د تونل انټرفېس نومول، او یوازې هماغه انټرفېس، همدا د روټر خپلې پوښتنې تونل ته رسوي۔ که پر ډیفالټ پرېښودل شي، حلکوونکی د لارښوونې جدول څخه وتل ټاکي، چې په دوه WAN یا VPN لرونکي هوسټ کې ډېری WAN وي۔

نور فرم ویئرونه هماغه پرېکړه تر بلې نښې لاندې ښيي: له سرچینې پتې سره تړلی د پورتنو سرورونو لیست، یوازې لېږدولو حالت، یا مستند شوې د لارې پالیسي۔ هغه تنظیم چې باید ولټول شي هغه تل دی چې په محلي توګه جوړو شوو پوښتنو لپاره وتل یا سرچینه ټاکي۔ د حلکوونکي د کانفیګورېشن مرجع د pfSense لپاره هغه انتخاب مستند کوي او له بدلون دمخه لوستل یې ارزښت لري۔

له تنظیم دمخه د ناکامۍ چلند وټاکئ

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

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

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

دواړه لارې وازموئ او پایلې جلا وساتئ

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

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

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

بیا تونل راکوز کړئ او دواړه پوښتنې تکرار کړئ۔ رد شوي ځوابونه معنا دا ده چې حلکوونکی په ناکامۍ کې تړل کېږي؛ بریالی ځواب د بیرته تګ حلکوونکي او د هغې کارول شوې لارې ته اشاره کوي۔ دا له خپلې لیکل شوې یادې او په هماغه دقیقه کې د WAN انټرفېس پر اخیستل شوي ثبت سره پرتله کړئ۔

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