OpenVPN على Android: إضافة مسار خاص دون روت للهاتف
أضف مسارًا واحدًا داخل الملف الشخصي الذي يحمّله Android فعليًا، ثم تحقق من سماح الخادم به. دليل تنفيذي للتعديل وإعادة الاتصال وأربعة فحوص.
تحتاج إلى شبكة فرعية خاصة إضافية، مثل 10.60.0.0/24، لا يتضمنها الملف الشخصي الآن. على الحاسوب المحمول تضيف مسارًا وتكمل. على Android فإن الـVPN تطبيق، وجهاز tun ملك لهذا التطبيق، ولا يوجد جدول توجيه يمكنك تعديله دون روت. يجب أن يظل المسار موجودًا، لكنه يدخل في الملف الشخصي الذي يحمّله العميل، ولا يعمل إلا إذا وافق الطرف الآخر. هذا هو التعديل وإعادة الاتصال وجانب الخادم والتراجع.
قبل التعديل: ما يمكن للمسار فعله وما لا يمكنه
المسار يجيب على سؤال واحد: أي واجهة يجب أن تحمل حركة المرور إلى هذه الوجهة. وهو لا يمنح أي إذن. إذا لم يوافق مالك الشبكة على وصول هذا الهاتف إلى تلك الشبكة الفرعية، فالمسار الصحيح ينتج إعدادًا يبدو صحيحًا وإسقاطًا صامتًا عند البوابة، وستقضي الساعة التالية في تعديل الملف الخطأ.
احصل على تلك الموافقة أولًا، كتابةً إذا كانت للشبكة مالك. ثم لاحظ ما لا تفعله: أنت لا تخصص للهاتف عنوانًا داخل تلك الشبكة المحلية، ولا تغيّر مستمع الخادم، ولا تختار موقعًا باسم المضيف. هذه أربعة تغييرات مختلفة، وأولها فقط هو تغييرك.
| The route gives you | The route does not give you |
|---|---|
| A destination prefix associated with the tunnel | Permission to forward at the gateway |
| A path for the phone's own traffic | A return route on the target host |
| A scope for the client's virtual interface | A name in DNS, or HTTPS identity |
عدّل الملف الشخصي الذي يحمّله العميل فعليًا
بالنسبة إلى عميل متوافق يستورد نص خيارات OpenVPN العادي، فإن الإضافة سطر واحد:
route 10.60.0.0 255.255.255.0أضفه إلى جسم الملف الشخصي قرب توجيهات المسارات الأخرى، مع الحفاظ على نقطة نهاية المشغّل والشهادات وإدارة المفاتيح وأسطر التحقق كما كانت تمامًا. لا تلصق مثالًا قديمًا كاملًا لتستعير منه سطرًا: فالضغط والمسارات المطلقة للملفات وإعدادات التشفير القديمة تسافر معه وتكلفك جلسة تصحيح منفصلة.
الخطوة التي يفوّتها الناس هي ملكية الملف. إذا استورد التطبيق ملفًا شخصيًا، فالنسخة التي يستخدمها ملك للتطبيق، وتعديل الأصل الذي نزّلته لا يغيّر شيئًا. استخدم المحرر المدعوم في العميل، أو أعد استيراد الملف المعدّل عبر مسار التحديث، وتأكد من اسم الملف النشط عند تشابه الأسماء. سجّل أيّها غيّرت.
إذا كان الملف الشخصي يحمل route-nopull مسبقًا، فلن يُثبّت أي مسار من الخادم، ويجب سرد كل بادئة يحتاجها الهاتف صراحةً. هذا تصميم مشروع، لكنه يعني أن سطرًا محذوفًا يبدو تمامًا كرفض من الخادم.
أعد الاتصال وتحقق على الجهاز
افصل أولًا، ثم أعد اتصال الملف الشخصي المحدد الذي عدّلته بدلًا من ترك التطبيق يستعيد الجلسة الأخيرة. افتح سجل الاتصال وتأكد من أن العميل حلّل السطر الجديد؛ فتوجيه مسار تتجاهله الواجهة الأمامية نتيجة شائعة لتعديل النسخة الخطأ.
اختبر الوجهة بعنوانها لا باسمها. فحص TCP إلى منفذ خدمة معروف أكثر إفادة من ping، لأن كثيرًا من المضيفين يجيبون على ICMP بينما منفذ الخدمة مفلتر. إذا أجاب العنوان ولم يجب الاسم، فلديك سؤال محلّل أسماء لا سؤال توجيه، والقسم التالي ليس لك.
هناك فحصان للنطاق ينتميان إلى هنا. شبكة VPN لكل تطبيق تعني أن مسار العنوان قد يكون موجودًا بينما التطبيق الذي تختبر به خارج المجموعة المشمولة، فاختبر بتطبيق داخل فعليًا. وبادئة IPv4 لا تقول شيئًا عن مسار IPv6؛ فإذا كانت الخدمة مزدوجة الحزمة، فأضف مسار IPv6 المقابل أو توقّع أن يفضّل العميل مسارًا لم تقصده.
نتيجة سلبية واحدة تستحق التعرّف المبكر: إذا كان مسار نفق كامل يغطي 0.0.0.0/0 مسبقًا، فالبادئة ليست ناقصة وإضافتها مرة أخرى لا تغيّر شيئًا. التغطية المزدوجة لا تصلح رفضًا من جهة الخادم ولا ردًّا مفقودًا.
أكمل الطريق على الخادم
ثلاثة أمور يجب أن تكون صحيحة خارج الهاتف: تحتاج البوابة إلى مسار نحو الوجهة وإذن بإعادة توجيه مصدر الهاتف نحوها، ويحتاج الهدف إلى قبول ذلك المصدر وإرجاع الردود عبر البوابة، وإلا احتاج التصميم إلى ترجمة متعمدة عند المخرج. خيار المسار في دليل OpenVPN يغطي توجيه جانب العميل؛ أما إعادة التوجيه وتوجيه العودة فهما إعدادان منفصلان على آلات منفصلة.
إذا كانت الوجهة خلف عميل VPN آخر لا خلف البوابة مباشرة، فالخادم يحتاج iroute لشبكة ذلك النظير الفرعية. هذا التوجيه ملك الخادم ويصف أي عميل يملك بادئة؛ لا يمكن للهاتف تقديمه من ملفه، ولا يغني عنه أي تعديل على جانب العميل.
افحص مسار العودة صراحةً. الرد الذي يخرج عبر المسار الافتراضي بدلًا من النفق ينتج العرَض الكلاسيكي للنصف المفتوح: اتصال قائم في اتجاه واحد ولا شيء يعود. ترجمة المصدر عند البوابة إصلاح مشروع حين لا يستطيع الهدف العودة، لكنه قرار سياسة له نتائجه.
التراجع والقبول
احتفظ بالملف الشخصي السابق قبل التعديل. إذا زاد التغيير الأمور سوءًا، فأعد تلك النسخة عبر مسار إعادة الاستيراد نفسه، وأعد الاتصال، وتأكد من عودة السلوك القديم؛ وهذا يؤكد أنك غيّرت ما ظننت. التراجع الذي لا يعيد الحالة القديمة يعني أن التطبيق يحتفظ بنسخة ثالثة لم تجدها.
اقبل التغيير عندما تتحقق أربعة أمور، تُختبر بهذا الترتيب بعد إعادة اتصال جديدة: الوجهة تجيب على منفذ خدمتها، والاسم الخاص يُحلّ إذا كان متوقعًا، وHTTPS لا يزال يتحقق من اسم المضيف المقصود، وكل شيء يعمل بعد إعادة تشغيل أو تبديل من Wi-Fi إلى الشبكة الخلوية. الفحص الأخير هو الذي يمسك مسارًا لا يوجد إلا حتى يعيد Android إنشاء النفق.
- تأكد أن مالك الشبكة يسمح بالوجهة قبل تعديل أي شيء.
- ضع المسار في الملف الشخصي الذي يحمّله العميل، ثم أعد الاستيراد وأعد الاتصال.
- تحقق عبر منفذ الخدمة، داخل نطاق كل تطبيق، ولعائلة العناوين الصحيحة.
- أصلح إعادة التوجيه وتوجيه العودة وiroute على الخادم لا على الهاتف.
- احتفظ بنسخة تراجع وأعد الاختبار بعد إعادة تشغيل.