لماذا تتجاوز استعلامات dnsmasq شبكة VPN بعد إعادة توجيه DNS

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

العلامة لا تسافر مع الاستعلام

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

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

المحادثتان تشتركان فعلًا في اسم وفي توقيت، وهذا ما يجعلهما تبدوان كتدفق واحد عندما تستعرض التقاطًا بنظرة سريعة.

أين يتحول التمرير إلى تحليل محلي

ابدأ بمعرفة ما إذا كان المنفذ 53 يُعاد توجيهه أو يُترجم إلى مضيف آخر أو يُترك كما هو، لأن الحالات الثلاث تتصرف بشكل مختلف. إعادة التوجيه إلى منفذ محلي تُنهي التمرير، بينما الترجمة إلى جهاز آخر تبقي الحزمة تتحرك وتبقي مجموعة حقول العميل ذات معنى.

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

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

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

امنح المُحلِّل سياسة خروج خاصة به

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

server=/corp.example/10.30.0.53@tun_work
log-queries

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

ضع السطر لدى مالك الإعداد الذي يدعمه الموجه بدلًا من ملف مولَّد، وإلا فإن إعادة التحميل التالية تمحو الإصلاح.

ما لا يمكن لذاكرة مؤقتة مشتركة الحفاظ عليه

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

الإجابة المخزنة ليست أيضًا دليلًا على المسار الجديد. قد يصل الرد من الذاكرة بينما يبقى المسار الصاعد معطلًا.

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

تحقق من المحادثة الثانية، لا الأولى

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

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

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