خادم Synology NAS بمنفذي LAN: لماذا يفشل مصافحة VPN

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

ما يبلّغ عنه العميل وما حدث فعلًا

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

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

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

اعثر على العنوان الذي تستمع عليه الحزمة

ترقّم DSM منافذ Ethernet، ولكل منها عنوانه الخاص. تعرض صفحة VPN Server الواجهة التي تستخدمها خدمة OpenVPN، وتعرض لوحة الشبكة العنوان المكوّن على تلك الواجهة. اقرأهما بهذا الترتيب، من الخدمة إلى الخارج، حتى تصف ما يستمع فعلًا بدلًا مما تفترض أنه ينبغي أن يستخدمه.

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

sudo ss -lunp | grep 1194

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

أصلح إعادة التوجيه، ثم راقب العدّاد

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

إذا حصلت DSM على ذلك العنوان عبر DHCP، فأنشئ حجزًا أولًا. تغيير الإيجار يكسر بصمت إعادة توجيه كانت تعمل أمس.

sudo tcpdump -i any -n udp port 1194

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

عندئذ فقط انظر إلى الشهادات والنقل

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

اختبر من خارج شبكتك الخاصة كخطوة أخيرة، لأن اتصالًا من داخل LAN قد ينجح عبر مسار لا يمس إعادة التوجيه إطلاقًا.

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