لماذا يخرج رد OpenVPN عبر UDP من العنوان الخطأ

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

ما يراه العميل عندما يتغير المصدر

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

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

ما الذي يفعله خيار multihome فعليًا

يُكتب التوجيه multihome في ملف الإعداد، ويُكتب --multihome على سطر الأوامر، وهو يجعل خادم UDP يرد من العنوان الذي وصلت إليه حزمة العميل. وتُسلّم النواة عنوان الوجهة الأصلي كبيانات إضافية عند الاستقبال، ويستخدم OpenVPN تلك القيمة مصدرًا للرد. وبذلك يتصرف خادم يستمع على عنوان شامل، local 0.0.0.0 في IPv4 أو ما يعادله في IPv6، كأن كل عميل وصل إلى مستمع مخصص. فالعملاء الذين دخلوا عبر العنوان العام يتلقون ردودًا من العنوان العام، والعملاء على عنوان داخلي يتلقون ردودًا من ذلك العنوان. ولا يتحرك شيء آخر في مسار الحزمة: فالمسار وقواعد الفلترة وإعداد النفق تبقى كما كانت تمامًا.

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

متى يكون العنوان المحلي الثابت هو الافتراضي الخاطئ

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

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

أثبت مصدر الرد من الخارج

اختبر من خارج الخادم، وسجّل العنوان والنقل الدقيقين اللذين استخدمهما العميل قبل التقاط أي شيء. والفحوص الثلاثة أدناه تجيب عن ثلاثة أسئلة مختلفة، والترتيب مهم.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

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

التوجيه والاكتشاف والفلترة تبقى منفصلة

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

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