هل توجّه عملاء OpenVPN عبر Cloudflare؟ تحقّق من الدور أولًا
عميل الجهاز ليس راوترًا. تأكّد من أن دور Cloudflare يعيد توجيه حزم الأجهزة الأخرى، ثم أبقِ نفق الخادم نفسه على مساره القديم.
لديك خادم OpenVPN يعمل، ومضيف يشغّل أيضًا برنامج الأجهزة من Cloudflare، والخطوة التالية البديهية تبدو وكأنها توجيه حركة العملاء إليه. اتصالان يعملان على جهاز واحد لا يشكّلان بوابة عبور. ما ينقص هو دور موثّق لإعادة توجيه حزم تخصّ طرفًا آخر، وسياسة تصنّف تلك الحزم عند وصولها.
تسبق أي قاعدة أربعة أسئلة: أي حركة تدخل، وإلى أين تذهب بعد ذلك، وكيف تجد الردود طريقها إلى الخلف، وما الذي يفعله التصميم عندما يفشل ذلك المسار الثاني. السؤالان الأولان سؤالا قدرة.
خدمتان على مضيف واحد ليستا مسار عبور
عميل الجهاز مصمّم لمعالجة الحركة التي تنشأ على الجهاز الذي يعمل عليه. يعترض تحليل الأسماء، أو حركة تطبيقات مختارة، ويرسلها عبر نفقّه الخاص، وسياسته مكتوبة لمستخدم ذلك الجهاز وعملياته. الحزمة المعاد توجيهها من عميل OpenVPN ليست مخرجات محلية، لذا لا تصنّفها القواعد نفسها. وهذا ليس تفصيلًا في الإعداد يمكن تجاوزه بقاعدة أوسع، لأنه يحدّد ما إذا كان البرنامج يرى الحزمة أصلًا.
ولهذا فإن سؤال التصميم سؤال قدرة. إما أن يكون للمنتج المثبّت دور موثّق يعيد توجيه الحركة لشبكات أخرى، وإما أن تكون وظيفة العبور في مكان آخر تمامًا.
أي دور في Cloudflare يُسمح له بإعادة التوجيه
يقدّم عميل الأجهزة من Cloudflare أوضاعًا تختلف في النطاق: تحليل الأسماء فقط، أو حركة الجهاز، وأحيانًا كلاهما. لا يحوّل أي من هذه الأوضاع المضيف إلى راوتر لنطاق خاص يصل عبر نفق مختلف. دور التوجيه المخصّص منتج منفصل له موصّله وتسجيله ونموذج شبكته الخاص.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
تحقّق من الدور المثبّت قبل تصميم المسارات حوله. اقرأ أي واجهة ينشئها الموصّل، وما إذا كان يعلن بادئات محددة أو مسارًا افتراضيًا، وما إذا كانت السياسة المحلية تنطبق على الحزم المعاد توجيهها وعلى الحزم المحلية معًا. إذا كانت الحركة المحلية وحدها هي المعالَجة، فلا يمكن لخادم OpenVPN أن يكون نقطة العبور مهما كُتبت قاعدة الترجمة.
وهنا أيضًا يجب تحديد متطلّب الخروج العام بدقة. الخروج الذي توفّره Cloudflare لحركة العملاء المعاد توجيهها حالة استخدام محددة، ويحتاج إلى تأكيد مقابل الخدمة التي لديك فعلًا.
أبقِ النفق الخارجي مستقلًا عن المسار الجديد
بمجرد إضافة مسار افتراضي نحو الواجهة الجديدة، تبدأ حركة الخادم الصادرة بالتنافس عليه، ويشمل ذلك الردود على عملاء OpenVPN وجلسة SSH الخاصة بك إلى الصندوق. العَرَض المعتاد نفق يُنشأ ثم يموت، أو مدير يُقفل خارج الجهاز بينما يبدو التغيير ناجحًا. قارن ip route get لنقطة النهاية قبل وبعد، واستخدم التوجيه بالسياسة أو مسارًا للمضيف لإبقاء نقل الخادم نفسه حيث كان. نفّذ تلك المقارنة من الصندوق نفسه، لأن رؤية الخادم لمساره الخاص هي التي تهم.
استثناء لعنوان الخادم العام لا يكفي بحد ذاته، لأن مسار العودة لكل مدير بعيد تدفّق مختلف. حدّد أي هذه التدفقات يجب أن ينجو من التغيير، ثم تحقّق من كل واحد بدلًا من افتراض أن الأول يغطي الباقي.
احصر إعادة التوجيه والترجمة في تدفّق واحد
تتبع الحزم المستلمة مسار إعادة التوجيه، لا مسار المخرجات المحلية، لذا فإن القاعدة المهمة تعيش في خطاف forward. حيث تحتاج الواجهة التالية إلى ترجمة، احصر المصدر في مجموعة العملاء، والوجهة فيما يُسمح به، والخروج في تلك الواجهة الواحدة. قاعدة masquerade المرتبطة بواجهة فقط لا تختار مسارًا بنفسها ولا تسمح بإعادة التوجيه عبر أي مرشّح آخر.
حدّد سلوك الفشل المغلق مسبقًا، ثم اختبره. أوقف المسار التالي وتأكّد من أن العملاء يفقدون الخروج المقصود بدلًا من التراجع بهدوء إلى الرابط الصاعد العادي، وهي النتيجة التي لا يلاحظها أحد حتى تخرج الحركة من الباب الخطأ. كرّر التحقّق لتحليل الأسماء ولـ IPv6، لأن مجموعة قواعد خاصة بـ v4 تترك مسار v6 مفتوحًا.
اكتب الإجابات الأربع التي استقرّت عليها والملاحظة التي تثبت كل واحدة منها. مسار العبور الذي تستطيع وصفه هو مسار يمكنك الدفاع عنه في مراجعة الحوادث التالية.