توجيه خدمة ويب محلية واحدة فقط خارج VPN حسب المنفذ

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

افحص الشروط الثلاثة قبل أن تكتب قاعدة

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

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

طابق الرد، لا منفذ وجهة العميل

الرد من خادم يستمع على TCP 443 يغادر المضيف بمنفذ مصدر 443. المتصفح على المضيف نفسه عند اتصاله بموقع HTTPS بعيد يرسل منفذ مصدر عابرًا ومنفذ وجهة 443. كلاهما مرور على المنفذ 443، ويجب أن يستخدم واحد فقط منهما جدول WAN، ولهذا فإن مطابقة منفذ الوجهة ستأخذ النصف الخطأ.

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

ابنِ جدول عودة كاملًا قبل أن تشير القاعدة إليه

الجدول الفارغ يعني لا مسار، وهو ما يبدو كخدمة معطلة لا كسياسة معطلة. املأه أولًا، برقم جدول وأولوية لا يطالب بهما شيء آخر على المضيف:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

اقرأ الأرقام من المضيف الحيّ بدل نسخها. ip -4 rule show يخبرك بالأولويات المشغولة، وإضافة قاعدة بأولوية موجودة أصلًا تغيّر بصمت ترتيب قاعدتين تبدوان سليمتين كل بمفرده.

محدّدان يقومان بالعمل الحقيقي هنا. iif lo هي الطريقة التي تبلّغ بها النواة عن الحزم التي ولّدها المضيف بنفسه، فلا يمكن للقاعدة أن تلتقط بالخطأ مرورًا مُعاد توجيهه قادمًا من الخارج. ipproto tcp sport 443 تحصرها في نقل واحد ومنفذ واحد، وهو أضيق ما يسمح به الشرط. احذف محدّد البروتوكول فتلتقط القاعدة أيضًا UDP 443، وهي خدمة مختلفة بسلوك مختلف.

أبقِ الردود الخاصة داخل النفق

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

ip -4 route add table 100 throw 10.90.0.0/24

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

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

اختبر TCP، ثم QUIC، ثم إعادة تشغيل

افتح اتصالًا واحدًا من عميل خارجي مصرّح له وواحدًا من الجانب الخاص، ثم افحص بحث الرد بالعناوين والمنافذ الفعلية. إذا أخذ الرد الخارجي الجدول 100 ولم يأخذه الرد الخاص، فالسياسة تفعل ما طلبته.

يُقدَّم HTTP/3 عبر UDP ولن تطابقه قاعدة TCP، لذا يحتاج مستمع QUIC محدّده الخاص وإلا بقي يستخدم النفق بينما يعمل HTTPS. احفظ القواعد التي تستقر عليها مع المكوّن الذي يملك الواجهة، وأكّدها بعد إعادة اتصال أو تجديد DHCP. عندما يزيل مدير منافس مسارًا وقت التشغيل بعد إعادة تشغيل، فهذه مشكلة ملكية تُحلّ عند المصدر، لا سبب لإضافة قواعد NAT أوسع فوقها.