توجيه حساب Linux واحد عبر OpenVPN بقاعدة UID

التوجيه القائم على الحساب يناسبك عندما يجب أن يخرج كل مقبس IPv4 يملكه مستخدم Linux واحد عبر نفق قائم، ولا يناسبك عندما تحتاج إلى عزل على مستوى البرنامج. فهو يختار حسب UID، لذا كل ما يعمل بذلك الحساب داخل النطاق، بما في ذلك وظيفة الدفعات التي نسيتها. احسم هذه المسألة قبل أن تلمس ip rule واحدة.

يفترض المثال أدناه حساب متصفح مخصصا عند UID 1500، وجهاز نفق tun-office يحمل العنوان المحلي 10.80.0.11، وشبكة VPN تسمح بالوجهات المعنية. الخادم الخفي نفسه يعمل خارج ذلك UID.

ثلاثة شروط تحدد الآلية

اختر قاعدة UID عندما تكون الهوية التي تؤدي العمل هي الحساب، وعندما يكون نقل كل حركته مقبولا، وعندما يكون namespace أثقل مما تستحقه المهمة. اختر namespace شبكة عندما يحتاج الحمل إلى واجهاته ومسواه وجدول توجيهه الخاص. اختر وكيلا أو ربطا لكل عملية عندما يجب أن تنتقل تطبيقة واحدة بالضبط بينما تبقى بقية الجلسة على المسار المحلي. كتابة هذه الثلاثة تمنع قاعدة تغطي أكثر مما هو مقصود دون أن يلاحظ أحد.

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

الجدول والقاعدة والحاجز

بعد فحص القواعد القائمة واختيار أرقام جدول وأولوية غير مستخدمة، يكون الترتيب قصيرا: مسار افتراضي في جدول مخصص يحمل عنوان مصدر النفق، وقاعدة ترسل استعلامات الحساب إلى ذلك الجدول، وقاعدة إنهاء تحجب الاحتياطي. مكتوبا، هذا استبدال مسار عديم الأثر، ip -4 route replace default dev tun-office src 10.80.0.11 table 51820، يتبعه ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

الحاجز هو ip -4 rule add priority 12101 uidrange 1500-1500 unreachable، وهو يهم أكثر مما توحي به قصته. من دونه، يسقط مسار مفقود في الجدول 51820 إلى الرابط الصاعد العادي ويصدر الحساب بصمت حركة كان السياسة تهدف إلى احتجازها. معه، يصبح الفشل نفسه مهلة، أي حجبا لا احتياطا.

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

ما يتجاهله توجيه UID: DNS

الخادم الخفي للمسوال يفتح مقابسه الصاعدة تحت UID الخاص به، لذا اختيار 1500 لا ينقل تلك الاستعلامات إلى الجدول 51820. تكامل DNS قرار منفصل: وجه الحساب إلى مسوال يمكن الوصول إليه عبر النفق، أو اقبل أن تحليل الأسماء يتبع مسار المضيف بينما لا تفعل الحركة ذلك.

استعلام عبر loopback إلى خادم محلي محدود ليس دليلا على أن الاستعلام الصاعد استخدم مسار المتصفح، ولا تحميل صفحة ناجح من ذاكرة التخزين المؤقت دليلا كذلك.

IPv6 يحتاج جملته الخاصة في التصميم

القواعد أعلاه تغطي IPv4 فقط. إذا كان المطلوب نفق IPv4 دون IPv6 مباشر من هذا الحساب، فأضف قاعدة إنهاء مراجعة مثل ip -6 rule add priority 12101 uidrange 1500-1500 unreachable، ثم افحص قواعد IPv6 الأسبق واستثناءات loopback التي تنوي الاحتفاظ بها.

حجب IPv6 المباشر ليس أنفاقا مزدوج الحزمة؛ إنه حد. تسميته أنفاقا ستربك الشخص التالي الذي يقرأ السياسة، وسيظهر الارتباك في تذكرة دعم حول موقع IPv6 معطل.

تحقق بالحساب الحقيقي، ثم امتلك دورة الحياة

قارن الاستعلامات: ip -4 route get 198.51.100.25 uid 1500 مقابل الوجهة نفسها بـ UID عادي. ثم أنشئ طلبا مسموحا بموجب الحساب المخصص وافحص عنوان المصدر الذي يراه الطرف البعيد. عنوان المصدر المفضل ليس NAT مصدر، ولن يتجاوز تطبيقا يربط شيئا آخر. إذا أعاد الاستعلامان المسار نفسه، فالقاعدة لا تفعل ما تظنه.

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