نفس عنوان IP للخادم، مساران: وسم التدفق الخارجي لـ OpenVPN

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

ابدأ بالتدفقين اللذين تريد فصلهما

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

في هذا الشرح، افترض عميلًا على 10.90.0.10 عبر tun1، وعنوانًا عامًا للخادم هو 198.51.100.25، وجدولًا رئيسيًا لم يُمَس مساره الافتراضي يشير إلى الوصلة الصاعدة العادية. على جانب الخادم أيضًا قبول خدمة الويب على المسار الداخلي وإعادة الحركة إلى مصدر النفق؛ إرسال حزمة إلى عنوان عام لا يلغي مستمع الخادم أو سياسة جدار الحماية.

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

ضع علامة على المقبس الذي يحمل المظروف

يكتسب إعداد العميل علامة لحزمه الصادرة المشفّرة ويتوقف عن تثبيت المسارات بنفسه، كي تكون سياسة الاستبدال هي الشيء الوحيد الذي يحدد المسارات:

mark 42
route-noexec
disable-dco

العشري 42 هو السادس عشري 0x2a، والصيغة السادسة عشرة هي ما ستطابقه قواعد التوجيه. مرجع link-options يصف mark بأنه ينطبق على الحزم الصادرة المشفّرة على Linux، أي المقبس نفسه الذي تحتاج إلى التحكم في مساره. إيقاف تفريغ قناة البيانات يبقي هذا المثال على مسار مساحة المستخدم، حيث سلوك العلامة هو الموصوف.

route-noexec يكبت الإضافة والإزالة التلقائيتين للمسارات من OpenVPN. لا يثبّت شيئًا مكانها، لذا من هذه اللحظة يجب على مالك المسارات صيانة كل مسار يحتاجه النفق. إذا اختفت وجهة خاصة بعد التغيير، فهذه سياسة الاستبدال الغائبة، لا عيب في العلامة.

لا تُبقِ مسار مضيف في الجدول الرئيسي للعنوان 198.51.100.25 أثناء فعل ذلك. مثل هذا المسار يعيد إدخال الاستثناء نفسه الذي يحاول التصميم تضييقه، وسيفوز لتدفق HTTPS قبل أن تُسأل أي سياسة أدناه.

أرسل كل شيء آخر إلى جدول النفق

بمجرد أن توجد واجهة النفق وتحتفظ بعنوانها، تبدو السياسة هكذا:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

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

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

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

اجعل مسار العودة يرى العلامة نفسها

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

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

التحقق المتساهل من مسار العودة ليس بديلًا أيضًا. يحتاج النمط المتساهل إلى وجود مسار ما للمصدر، وحارس unreachable الذي أضفته يزيل واحدًا عن قصد للبحوث غير الموسومة. أكمل تكامل علامة الاتصال وراجعه قبل الاعتماد على هذا التصميم، وتعامل مع مرشحات المضيف كسؤال منفصل: العلامة إشارة توجيه، لا إذن. إذا غاب التكامل، فالعراض جلسة تُنشأ ثم تصمت بمجرد أن تبدأ الردود بالوصول.

أثبت ذلك ببحثَي مسار

قارن ما يقرره النواة للسياقين، واقرأ حقلي dev و src بدلًا من حالة الخروج:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

ينبغي أن يُحل البحث الأول إلى tun1 بمصدر النفق، والثاني إلى الوصلة الصاعدة. هذه بحوث اصطناعية، لذا تثبت السياسة لا العملية الحية: أكّد مسار النقل الفعلي للعميل العامل على حدة، ثم نفّذ طلب HTTPS حقيقيًا مع إبقاء التحقق من الشهادة مفعّلًا.

اكتب ما لا يغطيه التصميم قبل إعلانه منتهيًا. DNS وIPv6 ودورة حياة القواعد تحتاج كل منها قرارها الخاص، وهذا مثال توجيه IPv4 لا إعداد خصوصية كامل. قيمته في المحدِّد: يحصل المظروف على استثناء الوصلة الصاعدة، ولا يضطر خدمة عادية على العنوان نفسه إلى وراثته.