خادم VPN على Raspberry Pi: ابدأ من تطبيق الهاتف لا من الوصفة

تبدأ معظم عمليات بناء VPN على Raspberry Pi من وصفة الخادم وتنتهي بهاتف لا يستطيع الاتصال. الترتيب مقلوب. يطبق تطبيق الهاتف بروتوكولا محددا بتبادل مصادقة محدد، وعلى الخادم أن يطابق ذلك التبادل لا العكس. واختيار التطبيق أولا يحول بعد ظهر كامل من تنقيح الأخطاء إلى قائمة فحص قصيرة.

الترتيب الذي يوفر إعادة البناء

اكتب نظام تشغيل الهاتف وتطبيق VPN بالضبط قبل تثبيت أي شيء على Raspberry Pi. هذا الزوجان يحددان البروتوكول الممكن أصلا. لا يصبح تطبيق العميل عميلا مختلفا لمجرد أن الملف الشخصي يحتوي على حقل مألوف.

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

بعد تثبيت التطبيق، يضيق اختيار الخادم ويصبح لبقية البناء هدف.

ما يطبقه تطبيق الهاتف فعليا

تصف قائمة تطبيقات منشورة تطبيقا لا خدمة. يتوقع تطبيق OpenVPN Connect لنظام Android خادم OpenVPN؛ وهو لا يوفر الجانب الخادم. ولا يصبح عميل IPsec أو L2TP عندما يبدو الملف الشخصي مشابها.

يظهر هذا الفرق بأقصى وضوح عند اتباع دليل قديم. الوصفات المكتوبة لبروتوكول أسقطه التطبيق الحالي ستثبت بنظافة على Raspberry Pi وستفشل على الهاتف، ويبدو ذلك كخطأ في الإعداد لا كعدم تطابق في البروتوكول.

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

الاتفاق الرباعي

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

ترقية التطبيق أو تغيير حزمة الخادم أو سلطة شهادات جديدة كلها تنقض الاتفاق، ويبدو الفشل من الهاتف متطابقا في كل مرة. وكتابة الأربعة هي ما يتيح لك تحديد أي جزء تحرك.

بيانات الاعتماد لها وظائف منفصلة

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

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

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

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

الوصولية عقد منفصل

على الهاتف أن يصل إلى نقطة النهاية الخارجية للخادم عبر ترتيب المنبع الحقيقي. فترجمة عنوان الموجه المنزلي والتصفية و NAT الخاص بمشغل الشبكة كلها تقع بينهما. اسم DNS ديناميكي يمنح نقطة النهاية اسما ثابتا فقط; فهو لا ينشئ مسارا داخلا.

ثم حدد ما يجوز للعميل الوصول إليه بعد الاتصال: بادئات خاصة أو مخرج إنترنت كامل، ومسارات إعادة التوجيه والرد، وسلوك DNS، وما إذا كان IPv6 داخل النطاق. نجاح تسجيل الدخول لا يثبت شيئا من ذلك.

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