لماذا يفشل رد DNS عند جدار حماية طرفي عديم الحالة لـ VPN

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

التبادلان ليسا التبادل نفسه

دوّن صفوف الحزم وسيصبح الخطأ واضحًا. منفذ الوجهة في الطلب يصبح منفذ المصدر في الرد، وهو عكس ما يتصوره معظم الناس عند إضافة قاعدة واردة للمنفذ 53:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

القاعدة الواردة التي تشترط منفذ الوجهة 53 تصف حركة موجهة إلى مستمع DNS يعمل على المضيف، وهو خدمة مختلفة تمامًا. وتلك العناوين أمثلة توثيقية، ومنفذ المصدر يختاره العميل لكل استعلام، لذا ليس قيمة يمكن نسخها إلى قاعدة وتوقع أن تستمر في العمل.

الطرف عديم الحالة مقابل جدار حماية المضيف ذي الحالة

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

المقارنة مهمة لأن الجهازين يفشلان بشكل مختلف. جدار حماية ذو حالة يرفض الرد يسجل إسقاطًا؛ أما الطرف عديم الحالة فيرفضه بصمت، ولهذا ينتهي المضيف ببساطة إلى مهلة.

ابنِ الإذن حول البروتوكول، لا حول رقم منفذ

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

ثم تأكد من أي منتج في المسار يرشّح الحركة فعلًا. نطاق IPv4 طرفي موثق لا ينشئ سياسة IPv6، وقد لا تعبر حركة المزود الداخلية ذلك المرشّح نفسه أبدًا.

لماذا لا يُعد السماح بأي منفذ مصدر 53 إصلاحًا

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

إذا كان المُحلِّل خدمة تتحكم فيها، فالتقييد على عناوينه كافٍ. وإذا كان مُحلِّلًا عامًا، فقيّد على العناوين التي وافقت عليها واذكرها في تعليق القاعدة.

تحقق عند الحد الصحيح، وفي الاتجاه الصحيح

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

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