TAP أم TUN؟ عملاء OpenVPN على Android والخوادم الموصولة بجسر

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

ينقل TAP إطارات Ethernet. وينقل TUN حزم IP. ويُمنح تطبيق VPN على Android واجهة IP، وهذا يجعل أحد الترتيبين ممكنًا والآخر غير ممكن، بغض النظر عما يقوله الإعداد.

المقارنة قصيرة، لكنها تحدد ما إذا كان يمكنك إصلاح الأمر على الهاتف أو عليك تغيير الخدمة.

نوعان من الأنفاق بحمولات مختلفة

تتصرف واجهة TAP مثل محول Ethernet. فهي تنقل الإطارات، أي ARP والبث وكل ما تحمله الشبكة المحلية تحت IP. وهذا ما يجعل الجسر ممكنًا: يمدّ النفق نطاق بث، ويتصرف العملاء كأنهم موصولون بمبدّل.

تنقل واجهة TUN حزم IP الموجّهة إليها. لا توجد طبقة ربط للتفاوض، ولا ARP، ولا بث. التوجيه يقرر ما يدخل النفق، ويستخدم إعداد الخادم شبكة فرعية بدلًا من جسر.

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

ما يمنحه Android فعليًا للتطبيق

تمنح واجهة VpnService في المنصة التطبيقَ واجهة افتراضية لحزم IP، مهيأة بعناوين ومسارات وحجم MTU. لا يوجد محول Ethernet في تلك الواجهة، ولا طريقة للتطبيق لاختلاق واحد.

لهذا توثّق OpenVPN Connect دعم اتصالات TUN الموجّهة على Android بدلًا من جسر TAP. وتوضح أسئلة Android الشائعة بيان جانب العميل لهذا الحد، وهي تطابق واجهة المنصة.

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

كيف يبدو الأمر عندما تحاول على أي حال

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

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

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

ما يجب أن يغيّره جانب الخادم

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

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

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

قرّر انطلاقًا من التطبيق، لا من النفق

اسأل عمّا يجب أن يصل إليه الهاتف فعلًا، ثم ارسم خريطة له. مشاركة ملفات أو موقع إنترانت يُوصل إليه بالاسم أو العنوان هو متطلب IP، والنفق الموجّه يلبيه بمجرد أن يحل DNS الاسم ويوجد المسار. أداة اكتشاف تتصفح نطاق البث المحلي ليست متطلب IP، ولا مقدار من التوجيه سيملؤها.

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

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