UFW يُسقط خادم DNS في VPN بمجرد أن يصبح النفق جاهزًا
سياسة المنع الافتراضي في UFW تغطي واجهة النفق أيضًا. رتّب الحركة حسب الاتجاه، واسمح بخادم الأسماء المدفوع على tun0، ثم افتح المسار الخارجي.
تتوقف الأسماء عن الحل في اللحظة التي يتصل فيها VPN، بينما لا يزال ping إلى عنوان عام يجيب ولا تُظهر حالة الجدار الناري شيئًا يبدو خاطئًا. لم يتغير شيء في السياسة؛ الذي تغير هو ظهور واجهة جديدة، والمنع الافتراضي يغطيها من أول حزمة. يقرر UFW حسب الاتجاه والواجهة، لذا فإن قاعدة مكتوبة للوصلة اللاسلكية لا تقول شيئًا عن الحركة الخارجة من النفق. الإصلاح هو حفنة من القواعد الضيقة المطبقة بترتيب معين.
العَرَض لا يظهر إلا بعد أن يصبح النفق جاهزًا
سياسة المنع الافتراضي تفعل بالضبط ما أُمرت به: كل ما لا تطابقه قاعدة يُرفض، على كل واجهة موجودة. لم يكن النفق موجودًا حين كُتبت القواعد، لذا لا يمكن لأي منها أن تطابقه، والمنع الذي كان موجودًا دائمًا ينطبق الآن على حل الأسماء. يمكن أن تعمل الحركة المباشرة إلى عنوان صريح عندما تغطيها قاعدة سماح أوسع، ولهذا ينجح ping إلى خادم أسماء عام بينما يفشل البحث عن اسم. الفجوة هي قاعدة لواجهة لم ترها السياسة قط.
وهذا يفسر أيضًا لماذا ينعكس الفشل بشكل نظيف: أسقط النفق فتُحل الأسماء مجددًا، لأن الاستعلام يعود إلى واجهة لها قواعد فعلًا. السياسة التي تفشل فقط أثناء وجود النفق ليست مشكلة DNS، وضبط الخادم نفسه يهدر أكبر وقت هنا. اقرأ قائمة الواجهات قبل قراءة إعدادات الخادم.
ثلاثة اتجاهات، ثلاث مجموعات قواعد مختلفة
الجلسة الواحدة تمس قواعد في أكثر من اتجاه، والنفق يضيف واجهة ثانية إلى كل واحد منها تقريبًا. ترتيب الحركة حسب الاتجاه والواجهة أولًا يجعل الباقي آليًا، لأن كل صف أدناه يحتاج قاعدته الخاصة في مكانه الخاص. تستخدم الأمثلة tun0 ومجموعة 10.8.0.0/24، فاستبدل الأسماء والنطاقات بما يخرج من العميل نفسه.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
يُخلط عادة بين صفين لأن كليهما يذكر النفق. قاعدة خادم الأسماء تسمح بالحركة التي يرسلها العميل إلى النفق، بينما قاعدة SSH تسمح بالحركة التي يتلقاها الخادم منه؛ فهما تعيشان على جهازين مختلفين وتفشلان بشكل مستقل. الصف الذي يُنسى في أغلب الأحيان هو الثاني، لأن العميل لا يستطيع إنشاء النفق إطلاقًا حتى يُسمح بحركته إلى العنوان العام للخادم. اعمل من الأعلى إلى الأسفل وكل فشل له سبب مرشح واحد.
خادم الأسماء المدفوع يحتاج قاعدة خاصة به
يعتمد ما إذا كان النفق يحمل DNS على ما يرسله الخادم. الخادم الذي يدفع خيار خادم أسماء يثبت عنوانًا خاصًا في إعدادات العميل، وهذا العنوان قابل للتوجيه عبر النفق فقط. إذا لم يدفع الخادم شيئًا، يحتفظ العميل بخادم الأسماء الذي كان لديه، ولا يكون لدى القواعد أدناه ما تسمح به. تحقق من الحالة المدفوعة ومن نتيجة الاستعلام الحالية قبل كتابة أي شيء:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedتسمي مخرجات الحالة خادم الأسماء المستخدم والوصلة المرتبط بها، ويُظهر بحث المسار خلفها أي واجهة ستحمل استعلامًا إلى ذلك العنوان. عندما يكون خادم الأسماء على وصلة أخرى، تكون المشكلة قبل الجدار الناري ولن تساعد أي قاعدة. عندما يتفق الاثنان على النفق، تكون هناك حاجة إلى قاعدتين، لأن UDP يحمل معظم الاستعلامات وTCP يتولى عندما تُقتطع الإجابة. سجّل القيمتين، لأنهما القيمتان اللتان ستسميهما القواعد:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'افتح المسار الخارجي قبل الداخلي
على العميل الوصول إلى العنوان العام للخادم قبل أن يوجد النفق، لذا تجلس قاعدته على الوصلة الفيزيائية ويجب أن تكون موجودة أولًا. السياسة التي تسمح بخادم الأسماء وتنسى الخادم تترك العميل عاجزًا عن بناء النفق أصلًا، وعادة ما يُلام على ذلك مفتاح إيقاف. ثم اسمح بالخدمات التي أردتها فعلًا عبر النفق، قاعدة ضيقة واحدة في كل مرة، بدلًا من فتح الواجهة بالكامل. القواعد الضيقة هي السبب في أن المنع يمكن أن يبقى مكانه.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'الترتيب مهم أثناء الاختبار، لأن القاعدة الأولى هي ما يسمح للنفق بالظهور أصلًا. أضفها واتصل وتأكد من أن النفق جاهز قبل إضافة قاعدة الخدمة، لأن فعل الاثنين معًا يعني أن الفشل لا يخبرك أي نصف هو الخطأ. استبدل عنوان التوثيق أعلاه بنقطة النهاية التي تم تكوين العميل لاستخدامها.
أنهِ جانب العميل بفصل الاتصال عن قصد. يجب أن يظل المنع يرفض الحركة التي استبعدتها عن قصد، لأن خادم أسماء يجيب بينما النفق جاهز يغطي نصف سياسة ترفض عند الشك فقط.
العميل الذي يتصل ليس مقبولًا بعد
للخادم اتجاهه الخاص الذي يجب مراعاته، والعميل الذي يكمل المصافحة لا يزال لا يستطيع الوصول إلى أي شيء يعمل على الخادم حتى يقبله الخادم. قاعدة المستمع العام تسمح بوجود النفق فقط؛ وهي لا تسمح بدخول حركة النفق. على الخادم هذه قاعدتان بالإضافة إلى فحص واحد بأن الخدمة تستمع فعلًا:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'يجب أن تساوي المجموعة في القاعدة النطاق الذي يخصصه الخادم، ويجب أن يطابق رقم النفق الرقم الذي أنشأه الخادم، لأن قاعدة بواجهة مختلفة لا يمكن تمييزها عن عدم وجود قاعدة. limit مقصود لمنفذ إداري، لأنه يحد من الاتصالات المتكررة بدلًا من قبولها بلا حدود. يفصل فحص المستمع بين منفذ مغلق وحزمة مُسقطة، وهما يبدوان متطابقين من العميل. القواعد المرقمة ليست الصورة كاملة أيضًا: قواعد UFW السابقة وأي أسطر nftables مكتوبة يدويًا تُطابق أبكر ويمكنها رفض حزمة تبدو القائمة أنها تسمح بها.