WireGuard DNS DNAT: حافظ على عمل مسار الرد

يعيد DNAT كتابة الوجهة لا المصدر. قرر كيف يمكن للخادم العلوي أن يجيب قبل إضافة القاعدة، وأبقِ كل مطابقة محدودة النطاق.

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

خُذ مثال العملاء المصرّح لهم في 10.77.0.0/24 القادمين عبر wg0، والذين يستعلمون عن العنوان المعلن 10.77.0.1 ويحتاجون إلى خادم DNS عند 203.0.113.53. عنوان الخادم العلوي عنصر نائب للتوثيق وليس خدمة عاملة.

إعادة توجيه الاستعلام تغيّر وجهته فقط

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

كلا نقلي DNS يحتاج إلى قواعد مطابقة، لأن العميل يعود إلى TCP عندما يُقتطع الرد.

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p udp --dport 53 -j DNAT --to-destination 203.0.113.53:53
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p tcp --dport 53 -j DNAT --to-destination 203.0.113.53:53

مسار الرد قرار منفصل

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

التوجيه يستحق المحاولة الأولى، لأنه يُبقي عنوان العميل مرئياً للخادم ويتجنب طبقة ترجمة ثانية. عندما يكون الخادم العلوي خارج سيطرتك، فترجمة المصدر على واجهة الخروج المحددة هي الخيار العملي.

اضبط نطاق تلك الترجمة بالضيق نفسه الذي ضبطت به إعادة التوجيه، وإلا أصبحت القاعدة NAT عامة لأي شيء يطابقها:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p udp --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p tcp --dport 53 -j MASQUERADE

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

اكتب القواعد أضيق مما تبدو المهمة

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

خادم البوابة نفسه مسار برمجي مختلف. الاستعلام الصادر محلياً يمر عبر OUTPUT، لذا فإن الاختبار من صدفة البوابة لا يمارس قاعدة PREROUTING ولا سياسة التمرير. لهذا يمكن أن ينجح اختبار محلي بينما يفشل كل عميل، والعكس شائع بالقدر نفسه.

لا يغطي هذا شيئاً من DNS عبر HTTPS على المنفذ 443 ولا DNS عبر TLS على المنفذ 853، ولا يغطي IPv6. العميل الذي أُعد له خادم IPv6 سيتجاهل الترتيب كله بسرور.

ما يثبته استعلام جديد

يتذكر تتبع الاتصالات التحويلات السابقة، فالاستعلام المرسل قبل تغيير القاعدة قد يُجاب من الحالة القديمة ويجعل القاعدة الجديدة تبدو معطلة. ابدأ بمنفذ مصدر جديد، وحيث يخزّن العميل الإجابات، باسم جديد.

dig @10.77.0.1 example.com A +short
conntrack -L -p udp --dport 53 | head

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

تأكد من أن الخادم يعرف الأسماء التي تتوقعها قبل إعادة توجيه أي شيء. بديل يجيب على الأسماء العامة لكن ليس منطقتك الخاصة يحوّل بحثاً عاملاً إلى NXDOMAIN يبدو كنفق معطل. اختبر الخادم مباشرة من البوابة قبل أن يتورط مسار العميل. أما مرجع إضافات iptables فيوثّق دلالات DNAT وmasquerade التي تعتمد عليها هذه القواعد.

مقالات ذات صلة