د Pi هټسپاټ Pi-hole او VPN سره: هرې خدمت ته خپله دنده وټاکئ
تر هغه چې په یوه Pi کې درې مرستندویان فعال کړئ، پرېکړه وکړئ چې DHCP، DNS او د پاکټونو لیږد څوک لري۔ تکراري مالکان سیالۍ لیزونه او د ریزولور لوپونه جوړوي۔
یو تلیفون د Pi هټسپاټ سره یوځای کیږي، پته ترلاسه کوي، او پاڼه بیا هم نه پرانیستل کیږي۔ Pi د هټسپاټ مرستندوی، Pi-hole او د VPN کلاینټ چلوي، او هر یو فکر کوي چې د لارې یوه برخه لري۔ د دې جوړښتونو ډیری برخه نه د دې له امله ناکامه کیږي چې یو برخه خرابه ده، بلکې د دې له امله چې دوه برخې یوه کار کوي۔ تر دې چې هر یو یې تنظیم کړئ، هرې دندې ته یو مالک وټاکئ۔
هرې دندې ته یو مالک وټاکئ
دلته څلور دندې مهمې دي، او هرې یوازې یو مالک ته اړتیا لري۔ لاندې جدول دنده، د کار وړ مالک او هغه څه ښیي چې خرابیږي کله چې دوه خدمتونه پرې دعوه وکړي۔
| Function | Workable owner | Duplicate-owner symptom |
|---|---|---|
| Client addresses | One DHCP server, such as the hotspot helper | Competing offers and changing leases |
| DNS reception | Pi-hole on port 53 | Bind failure or queries answered by the wrong process |
| Forwarding and NAT | One firewall manager | Double translation and broken return paths |
| VPN routing | One client configuration | Route flapping and traffic escaping outside the tunnel |
تیتوالی معمولا یو پاکټ په یو وخت راځي۔ د هټسپاټ مرستندوی خپله dnsmasq بېلګه نصبوي، Pi-hole پورټ 53 غواړي، او د VPN کلاینټ لارې زیاتوي۔ هر ګام یوازې منطقي ښکاري، او یوځای ماشین جوړوي چې پکې دوهم پیل شوی خدمت په خاموشۍ کې د لومړي چلند بدلوي۔
تر دې چې بل څه فعال کړئ مالکان ولیکئ۔ د جوړښت یادښتونو کې لنډ جدول وروسته نصبولو ته اجازه نه ورکوي چې هغه دنده ونیسي چې دمخه یې مالک درلود۔
یوه ساحه وټاکئ او له ټنل څخه یې لرې وساتئ
د هټسپاټ ساحه، په هغې کې د Pi پته، د DHCP حوض او هغه ریزولور وټاکئ چې کلاینټان یې ترلاسه کوي۔ هغه ساحه د پورتنۍ LAN او د VPN ټنل له ساحې څخه جلا وساتئ، ځکه چې یو بل ته ننوځېدونکي فرعي شبکې د لارښوونې ستونزه د پتو ژباړې پروژې ته اړوي۔ هغه ساحه چې له ټنل سره یو ځای شي Pi د دوو ورته مخکښو ترمنځ ناڅاپي روټر کوي۔ ساحه او حوض په ډیفالټ نه پرېښودل، بلکې د هټسپاټ په کنفیګریشن کې ولیکئ۔
که چېرې هټسپاټ د NetworkManager شریک حالت لري، مخکې له دې چې DHCP سرور زیات کړئ اغیزمن اړیکه وګورئ۔ شریک حالت خپل مرستندویان پیلوي او لیږد فعالوي، نو هغه لا دمخه د هغه انټرفیس لپاره د پتو پلان مالک دی۔ یوازې د دې له امله چې شته، دوهم سرور زیاتول سیالۍ وړاندیزونه جوړوي نه زېرمه۔
د IPv6 په اړه په قصد سره پرېکړه وکړئ۔ د روټر اعلانونه او DHCPv6 په ډیرو تنظیماتو کې له DHCPv4 څخه بل مرستندوی راځي، او IPv6 فعال پرېښودل پداسې حال کې چې د VPN پالیسي یوازې IPv4 پوښي، کلاینټانو ته ټنل ته ورتېرېدونکې لار ورکوي۔ یا د IPv6 خوا پلان کړئ یا یې د هټسپاټ انټرفیس کې د لیکل شوې دلیل سره بند کړئ۔
په پورټ 53 کې واقعیا څوک ځواب ورکوي
د کنفیګریشن بدلولو دمخه هر هغه پروسس ولیکئ چې پورټ 53 ته غوږ نیسي۔ په Pi کې چې سیمه ایز ریزولور stub، Pi-hole او د شریکولو مرستندوی چلوي، د اورېدونکو لیست یوازینی باوري نقشه ده چې څوک پوښتنو ته ځواب ورکوي:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routeد Pi-hole د انټرفیسونو لارښود توضیح کوي چې یو انټرفیس ته محدود د ترلاسه کولو حالت لا هم کولی شي wildcard ساکټ وکاروي او بل ځای ته رسېدلي پاکټونه وغورځوي۔ دا د یوازې ټاکل شوو انټرفیسونو تړلو سره یو شان نه دی، کوم چې هغه ترتیب دی چې کله بله DNS خدمت باید ماشین شریک کړي۔
دوه پروسسونه معمولا نشي کولی یوه پته او پورټ وتړي، که څه هم SO_REUSEPORT کولی شي شریک تړل بریالي کړي؛ بیا هم wildcard اورېدونکی کولی شي تنګ خدمت لپاره راغلي ونیسي۔ د غوښتل شوي رول لپاره مستند حالت وټاکئ او خدمتونه په غوښتل شوې ترتیب کې بیا پیل کړئ۔
د Pi-hole اداري پاڼه د هټسپاټ شبکې څخه بهر وساتئ۔ کلاینټانو ته ریزولور ته اړتیا ده، نه ویب انټرفیس یا API چې د ریزولور کنفیګریشن بدلولی شي۔
د DNS دوه پښې، هر یو لپاره یوه پالیسي
د کلاینټ پوښتنه له تلیفون څخه Pi ته ځي، او جلا پوښتنه له Pi څخه د هغې پورتنۍ ریزولور ته ځي۔ د لارښوونې هغه قاعده چې لیږدول شوي هټسپاټ ټرافیک سره سمه وي په دوهمه پښه اتوماتیک نه تطبیقیږي، ځکه Pi هغه ټرافیک سیمه ایز جوړوي۔ که VPN باید DNS وړونکي وي، سیمه ایزې لارې خپله پالیسي ته اړتیا لري۔
له لوپ څخه ډډه وکړئ۔ د Pi-hole پورتنۍ ریزولور هغې پتې ته اړول چې Pi یې پخپله خدمت کوي، مستقیم یا د پورټ فارورډ له لارې، هغه پوښتنې جوړوي چې تر وخت ختمېدو ګرځي۔ هغې ته ریښتینې پورتنۍ ریزولور یا هغو ډومینونو لپاره شرطي فارورډر ورکړئ چې ځواب نشي ورکولی۔
پرېکړه وکړئ چې ټنل ولوېدو سره څه پیښیږي۔ سیمه ایز ریزولور ته بیرته تلل لټون ژوندی ساتي خو نومونه د VPN بهر ته لېږدولی شي؛ بندول پالیسي سمه ساتي او خرابي په لیدل شوې تېروتنه بدلوي۔ دواړه انتخابونه د دفاع وړ دي، خو باید وټاکل شي نه له ډیفالټ څخه میراث شي۔
لاره او د خرابۍ پر مهال چلند ثابت کړئ
په طبقو کې ازموینه وکړئ: کلاینټ پته ترلاسه کوي، کلاینټ نوم د Pi له لارې حل کوي، Pi د غوښتل شوې پورتنۍ ریزولور له لارې حل کوي، او اپلیکیشن غوښتنه بشپړوي۔ بریالی ping د DNS په اړه هیڅ نه وایي، او بریالۍ پلټنه د لیږد په اړه هیڅ نه وایي۔
dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1بیا ټنل ودروئ او تکرار یې کړئ۔ غوښتل شوی چلند باید په څو ثانیو کې ښکاره شي، نه د Pi-hole یا د هټسپاټ خدمت له لاسي بیا پیل وروسته۔ د خرابۍ پر مهال د کلاینټ ریزولور تنظیم وګورئ، ځکه دوهم عمومي ریزولور به ځواب ورکولو ته دوام ورکړي حتی کله چې پالیسي ناکامي تمه درلوده۔
د لیږد او NAT لپاره یو مالک وساتئ او له کلاینټ څخه یې تایید کړئ، نه له خود Pi څخه۔ هغه غوښتنه چې له Pi څخه په بریالیتوب وځي په بیرته راستنیدو کې بیا هم غورځول کیدی شي، او کلاینټ یوازینی ځای دی چې ټوله لاره لیدل کیږي۔