نقطة اتصال Pi مع Pi-hole وVPN: أسند لكل خدمة وظيفة
حدّد من يملك DHCP وDNS وإعادة توجيه الحزم قبل تفعيل ثلاث أدوات مساعدة على Pi واحد. الملكية المكررة تنتج إيجارات عناوين متنافسة وحلقات في المُحلِّل.
ينضم هاتف إلى نقطة اتصال 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، والمُحلِّل الذي يستلمه العملاء. أبقِ ذلك النطاق منفصلًا عن الشبكة المحلية الأعلى وعن نطاق نفق VPN، لأن الشبكات الفرعية المتداخلة تحوّل مشكلة توجيه إلى مشروع ترجمة عناوين. النطاق المتداخل مع النفق يجعل Pi موجّهًا عرضيًا بين بادئتين متطابقتين. اكتب النطاق والمجمّع في إعداد نقطة الاتصال بدل تركهما لقيمة افتراضية.
إذا كان الوضع المشترك في NetworkManager يملك نقطة الاتصال، فافحص الاتصال الفعّال قبل إضافة خادم DHCP. يبدأ الوضع المشترك أدواته المساعدة ويفعّل إعادة التوجيه، فهو بالفعل مالك خطة العناوين لتلك الواجهة. إضافة خادم ثانٍ لأنه متاح تخلق عروضًا متنافسة بدل التكرار الاحتياطي.
قرّر بشأن IPv6 بوعي. إعلانات الموجّه وDHCPv6 تأتي من أداة مساعدة مختلفة عن DHCPv4 في كثير من الإعدادات، وترك IPv6 مفعّلًا بينما تغطي سياسة VPN بروتوكول IPv4 فقط يمنح العملاء مسارًا يتجاوز النفق. إما أن تخطّط لجانب IPv6 أو تعطّله على واجهة نقطة الاتصال مع سبب مكتوب.
من يجيب فعليًا على المنفذ 53
اسرد كل عملية تستمع على المنفذ 53 قبل تغيير أي إعداد. على Pi يشغّل وكيل مُحلِّل محليًا وPi-hole وأداة مساعدة للمشاركة، تكون قائمة المستمعين الخريطة الموثوقة الوحيدة لمن يجيب عن الاستعلامات:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routeيوضّح دليل واجهات Pi-hole أن وضع الاستقبال المقتصر على واجهة واحدة يمكنه مع ذلك استخدام مقبس شامل ورفض الواردات في أماكن أخرى. هذا ليس مثل الربط بالواجهات المختارة فقط، وهو الترتيب المقصود عندما يتعيّن على خدمة DNS أخرى مشاركة الجهاز.
لا يمكن لعمليتين عادةً ربط العنوان والمنفذ نفسهما، مع أن SO_REUSEPORT قد يجعل الربط المشترك ينجح؛ وحتى حينها يمكن لمستمع شامل أن يستحوذ على واردات كانت موجّهة للخدمة الأضيق. اختر الوضع الموثّق للدور الذي تريده وأعد تشغيل الخدمات بالترتيب المقصود.
أبقِ صفحة إدارة 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 بنجاح قد يُسقَط مع ذلك في طريق العودة، والعميل هو المكان الوحيد الذي يُرى فيه المسار كاملًا.