مجموعة nftables التي يغذيها DNS إلى WireGuard: كيف يعمل التسليم
يمكن لاستجابة DNS أن تغذي مجموعة nftables، لكن المجموعة لا توجه أي شيء. تابع عمليات التسليم الأربع والأعمار الثلاثة التي تحدد ما إذا كان التوجيه سينجح.
تُحل الأسماء إلى عناوين، وقد تصل تلك العناوين إلى مجموعة في جدار الحماية تؤثر لاحقًا في التوجيه، ما يجعل التوجيه القائم على الأسماء ممكنًا دون وسيط. المفارقة أن أربعة مكونات يجب أن تتسلم العمل بشكل صحيح: المُحلِّل، والمجموعة، والمصنِّف الذي يضع علامة على التدفق الجديد، والنظير الذي يحمله. كل تسليم يفشل بطريقة مختلفة، ولكل منها توقيته الخاص.
تعامل مع التصميم كسلسلة لا كإعداد. السؤال في كل خطوة هو أي مكون يملك القرار، وماذا يحدث عندما تغيب مدخلاته.
ما تستطيعه استجابة DNS وما لا تستطيعه
يستطيع dnsmasq نسخ العناوين من الاستجابات إلى مجموعة nftables، وهذا تغذية وليس قرار توجيه. ذلك الخيار، الموثق في دليل dnsmasq، يحدد العائلة والجدول والمجموعة، وبادئته 4# تختار سجلات A فقط، لذا تحتاج وجهات v6 ترتيبًا خاصًا بها. يجب أن تكون المجموعة موجودة مسبقًا، لأن المُحلِّل يضيف عناصر إلى شيء أنشأه مالك الجدار. لا شيء في تلك الخطوة يختار واجهة أو جدولًا أو نظيرًا.
على العميل أيضًا أن يستخدم ذلك المُحلِّل للاسم. التطبيق الذي يستخدم DNS مشفرًا خاصًا به، أو استجابة مخزّنة من قبل وجود السياسة، يتصل دون إنشاء أي إدخال في المجموعة.
المجموعة مدخل وليست مسارًا
العنصر في المجموعة شرط مطابقة. يجب أن ينظر إليه شيء ما، ويقرر أن هذه الحزمة تبدأ تدفقًا جديدًا، ويطبق السياسة التي ترسل التدفق عبر النفق. على Linux يعني ذلك عادة مسار إخراج قادر على التوجيه يمكنه وضع علامة، وقاعدة ترسل الحزم المعلَّمة إلى جدول مخصص، ومسار في ذلك الجدول يشير إلى جهاز WireGuard. العضوية وحدها لا تثبّت أيًا من ذلك.
nft add set inet vpn_select office_v4 { type ipv4_addr\; }
ip rule add fwmark 0x40 table 200
ip route add default dev wg0 table 200
wg show wg0 allowed-ips
يطبق النظير فحص تغطية ثانيًا ينساه الناس. لا يشفّر WireGuard حزمة إلا لنظير تتضمن عناوينه المسموح بها الوجهة، لذا لا يكفي مسار سياسة إلى الواجهة عندما تستبعد قائمة النظير تلك البادئة. أبقِ القائمة تحت سيطرة مالك التوجيه بدلًا من الاعتماد على أي إنشاء مسارات يصادف أن يقوم به المدير.
العلامات والجداول وتغطية النظير
العلامات فضاء أسماء مشترك، لذا يجب الاتفاق على القيمة والقناع مع أي شيء آخر يستخدمها. تحتاج القاعدة التي ترسل حركة معلَّمة إلى جدول مخصص إلى نتيجة محددة عندما لا يكون في ذلك الجدول مسار مطابق، لأن بحثًا بلا جواب يمكن أن يستمر إلى القاعدة التالية ويرسل الحزمة خارج الواجهة الفيزيائية. المسار الافتراضي من نوع blackhole داخل الجدول المخصص يحوّل ذلك الهروب الصامت إلى إسقاط مرئي. ما يظل التصميم عاجزًا عنه هو الإغلاق عند الفشل لوجهة لم تدخل المجموعة قط.
يجب أن تفلت الحزم الخارجية للنفق نفسها من المصنِّف. توفر أدوات WireGuard علامة مقبس لهذا الغرض بالضبط، واستخدامها يمنع إعادة توجيه التغليف إلى الواجهة التي يبنيها.
اختبر كل عمر على حدة
ثلاثة مخازن تتقادم بثلاثة جداول زمنية: ذاكرة المُحلِّل، وعناصر المجموعة، والاتصال المتتبع. اختبرها بهذا الترتيب وراقب ما إذا كان كل منها يتحرك عندما ينبغي. الأوامر أدناه تقرأ المُحلِّل والمجموعة وجدول الاتصالات وقواعد السياسة دون تغيير أي شيء.
dig +short office.example
nft list set inet vpn_select office_v4
conntrack -L -d 10.60.8.15
ip rule show
البحث الجديد الذي يضيف عنصرًا يثبت أن التغذية تعمل، أما العنصر القديم الذي يعيش أطول من استجابته فعدم توافق في الأعمار يستحق التسجيل. ظهور اتصال جديد في جدول الاتصالات بالعلامة المتوقعة يدل على أن المصنِّف عمل، وبقاء اتصال قديم على علامته الأصلية سلوك صحيح لا خطأ. إدراج القواعد يجيب عما إذا كان بحث السياسة موجودًا أصلًا، وهو سؤال مختلف عن سؤال مطابقته. اقرأ المخرجات الأربعة بهذا الترتيب وسيعرّف التسليم الفاشل نفسه.
حين يكون المطلوب أن يستخدم اسم معين مسارًا واحدًا دائمًا، لا تستطيع مجموعة يغذيها DNS إثبات ذلك، لأن العناوين المشتركة تحمل أسماء أخرى أيضًا. الوسيط أو آلية على مستوى التطبيق هي الأداة لتلك الضمانة.