لماذا يتجاوز نظام 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 على مضيف ثنائي WAN أو مضيف VPN.

تعرض برامج ثابتة أخرى القرار نفسه تحت تسمية مختلفة: قائمة خوادم صاعدة مرتبطة بعنوان مصدر، أو وضع تمرير فقط، أو سياسة توجيه موثقة. والإعداد الذي يجب البحث عنه هو دائماً الإعداد الذي يختار مخرجاً أو مصدراً للاستعلامات المتولدة محلياً. مرجع إعداد المُحلِّل يوثق هذا الخيار في pfSense ويستحق القراءة قبل التغيير.

اختر سلوك الفشل قبل الإعداد

هناك سلوكان يمكن الدفاع عنهما عند سقوط النفق: إيقاف استعلامات الصعود حتى لا يتسرب شيء، أو الرجوع إلى مُحلِّل معتمد على مسار معروف. كلاهما سياسة، وليس أياً منهما ما تحصل عليه افتراضياً. قرر أيّهما تحتاجه الشبكة قبل لمس قائمة الواجهات.

الانغلاق عند الفشل أبسط في الدفاع عنه، لكنه يحول انقطاع النفق إلى انقطاع في تحليل الأسماء لكل جهاز خلف الموجّه. أما الرجوع فيُبقي المكتب صالحاً للاستخدام، على حساب تبادل صاعد خارج النفق يجب أن يكون مقبولاً بالقصد لا بالمصادفة. اكتب الخيار، لأن الشخص التالي الذي يرى عنوان مُحلِّل خارج VPN سيقرؤه على أنه تسرب ما لم تنص ملاحظة على خلاف ذلك. تلك الملاحظة هي ما يفصل الرجوع الموثق عن اكتشاف غير مفسر في مراجعة الربع القادم.

هناك حالتان تعقدان القرار. قد تحتاج الأسماء الخاصة إلى مُحلِّل داخلي يستطيع النفق الوصول إليه، وقد يتجاوز متصفح أو تطبيق له DNS مشفر خاص به الموجّه بالكامل، لذا فالمُحلِّل الذي أعددته ليس دائماً هو الذي يستخدمه تطبيق معين.

اختبر المسارين واحفظ النتائج منفصلة

اختبار DNS القائم على المتصفح يجيب عن سؤال ضيق: أي مُحلِّلات استخدم ذلك المتصفح، في ظروف ذلك الاختبار. وهو لا يحصر الأجهزة على الشبكة ولا يستطيع رؤية استعلام أنشأه الموجّه لنفسه. تعامل مع ناتجه كنقطة بيانات واحدة لا كتدقيق.

من عميل LAN، اطلب من الموجّه اسماً عاماً ثم اسماً خاصاً يجب أن تجيب عنه منطقتك الداخلية وحدها. فشل الاستعلام الثاني وحده يشير إلى تمرير الأسماء لا إلى النفق:

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

ثم أسقط النفق وأعد كلا الاستعلامين. الإجابات المرفوضة تعني أن المُحلِّل مغلق عند الفشل؛ والإجابة الناجحة تشير إلى مُحلِّل احتياطي وإلى المسار الذي استخدمه. قارن ذلك بالملاحظة التي كتبتها وبالتقاط على واجهة WAN مأخوذ في الدقيقة نفسها.

أبقِ الملاحظات منفصلة في السجل: تبادل العميل مع الموجّه، وتبادل الموجّه مع الصاعد، والإعداد الذي حسم الثاني. أي تغيير لاحق في التوجيه سيشغّل ذلك التبادل الثاني دون إنذار. والإجابة التي تصل من مكان غير نقطة نهاية VPN ليست بحد ذاتها تسرباً؛ إنها تصبح تسرباً فقط عندما يكون الإعداد قد اختار ذلك المسار بالمصادفة.