proto udp أم tcp-client: أيّهما يسمع خادمك؟

ملف تعريف كان يعمل الشهر الماضي صار الآن ينتهي بمهلة، فيقترح أحدهم تبديل proto udp إلى proto tcp-client. أحيانًا يكون ذلك التحرّك الصحيح، وأحيانًا ينتج عميلًا يتصل بمنفذ لا يستمع فيه أحد، لأن الخادم لم يُضبط قط للنقل الآخر. تصف التوجيهية طريقة تحدّث طرفك؛ ولا تستطيع إنشاء مستمع في الطرف الآخر. اقرأ ملف التعريف والخادم معًا قبل تغيير أي منهما.

اقرأ النقل الذي يستخدمه الاتصال المحدد

يمكن أن يحمل ملف التعريف عدة إدخالات remote، وقد يسمّي كل واحد منها نوع نقله الخاص. يعمل العميل عليها بالترتيب، لذا ليس بالضرورة أن يكون السطر الذي تراه أولًا هو السطر المطبَّق.

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

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

grep -nE '^(remote|proto)\b' client.ovpn

UDP وTCP ليسا إعدادًا للسرعة

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

هذه مقايضة وصول، لا ترتيبًا عالميًا. الاختيار الصحيح هو ما تسمح به الشبكة أمام العميل. المسار الذي يُسقط UDP على منفذ VPN لن يتفاوض أبدًا، مهما كان ملف التعريف محكم الكتابة. اختبر المسار ثم اختر النقل.

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

ما الذي يعنيه tcp-client فعلًا

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

التطابق يعني أن الطرفين يتفقان على النقل، لا أن يتشاركا السلسلة نفسها.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

اسأل الخادم على أي شيء يستمع قبل أن تفترض أن ملف التعريف خاطئ. مستمع UDP لا يظهر في قائمة مقابس TCP، والعكس صحيح أيضًا، لذا افحص العرض الخاص بالبروتوكول بدلًا من عرض عام.

حين يُستورد ملف التعريف لكنه لا يتصل أبدًا

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

اختبر المسار بأبسط طريقة ممكنة: اتصل بالمضيف والمنفذ نفسيهما بالنقل الذي يدّعيه ملف التعريف، من الشبكة نفسها التي يعمل منها العميل الفاشل.

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

سجّل النقل العامل

حين تنجح تركيبة، اكتبها مع الخادم والمنفذ والبروتوكول، ولاحظ الشبكة التي اختُبرت منها.

وإلا فإن الشخص التالي الذي تصادفه مهلة سيكرّر التجربة نفسها في الاتجاه الآخر، وربما يغيّر خادمًا كان سليمًا.

إذا نشر المزوّد البديلين، فاحتفظ بالملفين وسمِّهما حسب الشبكة التي يناسبانها. ملفان واضحا التسمية يمنعان الخلط العارض بين نقل عميل ومستمع خادم لم يُضبط له قط.