VPN الدائم على Android: كيف يُحل اسم نقطة النهاية أولا

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

ما يطلبه باني VPN فعلا

لا يعطي تطبيق VPN على Android للمنصة عنوان خادم. بل يبني واجهة محلية: عناوين ومسارات للنفق، والمحللات التي ينبغي للتطبيقات استخدامها داخله، ثم تعيد establish() واصف ملف يقرأه التطبيق ويكتب فيه كحزم IP خام. لا تظهر نقطة النهاية البعيدة في ذلك الباني إطلاقا.

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

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

سؤالان عن DNS، لا سؤال واحد

السؤال الأول هو: أين ترسل التطبيقات استعلاماتها بعد قيام النفق؟ الجواب عنوان محلل داخل النفق، يمكن الوصول إليه عبر واجهة tun، وهو رقمي بطبيعته.

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

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

لماذا يمكن أن تصل مرحلة الإقلاع إلى طريق مسدود

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

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

يكشف التوقيت الاعتماد نفسه بأشكال أخف. عند الإقلاع قبل أول فتح للقفل قد لا يكون للجهاز شبكة صالحة بعد؛ وعلى بوابة أسيرة توجد الشبكة لكنها تحظر كل شيء عدا البوابة؛ وعند الانتقال من Wi-Fi إلى الشبكة الخلوية تتغير الشبكة الأساسية للمقبس المحمي فعلى العميل ملاحظة ذلك وإعادة الحل. كل واحد من هذه حدث إقلاع، ويستحق الاختبار عمدا بدلا من اكتشافه في الساعة 3 صباحا.

لماذا ليس تثبيت الجواب إصلاحا

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

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

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

تصاميم تصمد بعد إعادة التشغيل

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

حيث يجب أن تبقى نقطة النهاية خاصة، وفّر مسار إقلاع صريحا تستطيع المنصة استخدامه، مثل محلل يمكن الوصول إليه بدون النفق، أو اتصال إدارة يتولاه المشغّل، وأبقِ ذلك الاستثناء ضيقا ومملوكا للسياسة لا لمفتاح مستخدم. توثيق Android VpnService هو المرجع لما تضمنه المنصة بشأن الحماية ودورة الحياة، ومرجع VpnService.Builder يؤكد أن حقل DNS يأخذ عناوين رقمية.

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

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