Proton VPN على جهاز Pi بلا واجهة رسومية: تطبيق أم ملف WireGuard؟

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

يأتي سؤال المعمارية أولًا، لأن لوحة 64 بت قد تشغّل مساحة مستخدم 32 بت، والتطبيق لا يُشحن إلا بإحداهما.

حدّا دعم، لا مثبّتان

اقرأ صفحة التثبيت الحالية للمزوّد الخاصة بالتطبيق الذي تنوي استخدامه وطابِقها مع اللوحة: إصدار التوزيعة، ومعمارية الحزمة، وأي متطلب لسطح المكتب أو الجلسة. كون جهاز Pi يدعم تشغيل 64 بت لا يخبرك بمساحة المستخدم المثبتة الآن، وهذه هي القيمة التي يفحصها مدير الحزم. dpkg --print-architecture و uname -m يجيبان عن ذلك بسطر واحد لكل منهما. وإذا وقع الإصدار أو المعمارية خارج المجموعة الموثقة، فالتطبيق غير مدعوم هناك حتى لو نجح تثبيته.

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

ما يمنحك التطبيق ولا يمنحك الملف

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

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

WireGuard يدويًا: الخطوات التي تهم

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

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

قرّر ما إذا كان Pi بوابة أيضًا

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

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

الأسطورة التي يحسن التخلص منها هي أن مثبّت Linux وملف WireGuard يمثلان القرار نفسه. إنهما نموذجا تشغيل بمالكين مختلفين.