عملاء OpenVPN لا يرون بعضهم: الشبكة الفرعية أم net30؟
يصل العملاء إلى الخادم لكن لا يصل بعضهم إلى بعض. افصل العطل بنقرة ping واحدة، ثم اختر طوبولوجيا الشبكة الفرعية أو client-to-client أو مقطع TAP موصولاً بجسر.
عطلان غير مترابطين ينتجان الشكوى نفسها. في الأول، لا يستطيع أحد العملاء الوصول إلى آخر حتى بعنوان النفق، لأن العناوين ليست في شبكة فرعية واحدة أو لأن الخادم لا يمرر حركة الأقران. في الثاني، يعمل ping وتبقى قائمة الأجهزة في التطبيق فارغة، لأن الاكتشاف يعتمد على البث الذي لا يستطيع نفق الطبقة 3 حمله. نقرة ping واحدة تفصل بينهما، والإصلاح في كل حالة لا يشبه إصلاح الأخرى.
نقرة ping واحدة تقسم المشكلة إلى نصفين
من أحد العملاء، اعمل ping لعنوان النفق الخاص بالعميل الآخر، لا لاسمه ولا لعنوان شبكته المحلية. إذا فشل، فالمشكلة في التمرير أو العنونة، والاكتشاف غير ذي صلة حتى تُصلح. وإذا نجح، فالتمرير يعمل أصلاً والفجوة المتبقية هي البث أو تحليل الأسماء.
ip addr show tun0اقرأ واجهة العميل قبل أي شيء آخر، لأن قناع الشبكة يسمّي الطوبولوجيا. القناع /24 أو أي قناع شبكة فرعية آخر يعني مجمعاً مشتركاً؛ والقناع /30 مع عنوان قرين يعني التخطيط القديم من نقطة إلى نقطة، حيث لكل عميل جار واحد فقط هو الخادم.
net30 مقابل الشبكة الفرعية، كما تُقرأ من جهة العميل
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
مع net30 يوزع الخادم كتلة صغيرة لكل عميل، لذلك لا يوجد مسار إلى عنوان نفق عميل آخر إلا إذا مرره الخادم. ومع الشبكة الفرعية يكون المجمع كله شبكة واحدة، ويستطيع كل عميل مخاطبة كل عميل آخر، ويمرر الخادم بينها. لهذا قد تبدو إعدادات خادم واحدة سليمة بينما تفشل pings الأقران: لا شيء معطل، لكن العملاء ليسوا في شبكة واحدة. يرى العميل وصلة عاملة وعنوان قرين لا يستجيب، وهو ما يبدو كجدار حماية لكنه في الحقيقة تخطيط عنونة.
تغيير التوجيه تعديل على جانب الخادم مع إعادة تشغيل، وينطبق على الاتصال التالي لا على الجلسات القائمة بالفعل. أعد توصيل العملاء قبل الحكم على التغيير. وإذا كان الجهاز يعيد توليد الإعداد من واجهة ويب، فسجّل التوجيه والملف والتاريخ، ونفّذ التعديل عبر الواجهة عند وجودها، لأن إعادة البناء ستطمس تعديلاً يدوياً عند الحفظ التالي.
client-to-client بوابة منفصلة
حتى داخل شبكة فرعية واحدة، يُسقط الخادم الحزم التي تأتي من عميل وتُوجَّه إلى آخر ما لم يكن client-to-client مضبوطاً. تلك الكلمة تحوّل الخادم إلى ممرر لحركة الأقران بدلاً من طرف نهائي يقبلها فقط. وهو الشرط الثاني الذي يفوته الناس بعد إصلاح الطوبولوجيا.
ولا يمتد ذلك إلى البث. الإعداد يمرر أحادي الإرسال بين العملاء؛ ولا يحوّل النفق إلى مقطع مشترك، ولن يوصل أي قدر منه استعلام اكتشاف متعدد الإرسال إلى كل قرين.
TUN مقابل TAP، وما يستطيع كل منهما حمله
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
ربط جهاز tap بجسر إلى الشبكة المحلية يضع العملاء البعيدين في نطاق بث المكتب، وهذا يحل الاكتشاف تماماً. الثمن هو المنصات التي لا تنفذ TAP، وجسر يجب أن يكون موجوداً على الخادم، ونطاق فشل تصل فيه عاصفة بث على كابل المكتب إلى كل حاسوب محمول بعيد.
لجهازي عمل أو ثلاثة تحتاج إلى تحليل أسماء، فإن إدخال hosts أو عنوان أحادي الإرسال أرخص بكثير من جسر. استخدم TAP عندما يعتمد بروتوكول لا يمكن استبداله على اكتشاف الطبقة 2، وليس قبل ذلك.
عملاء الشبكة الفرعية نفسها بدون جسر
إسناد عنوان من نطاق الشبكة المحلية لا يضع العميل على الكابل. الخادم يوجّه بين النفق وإيثرنت، لذا يتوقف ARP عن ذلك العنوان عند واجهة الخادم ولا يعرف بقية الشبكة المحلية أين يسكن.
ip neigh add proxy 10.50.1.250 dev eth0يغلق Proxy ARP تلك الفجوة بأن يجيب الخادم بالنيابة عن العميل. ولنطاق كامل يدير parpd الإدخالات مع مجيء العملاء وذهابهم، بينما يجيب sysctl net.ipv4.conf.eth0.proxy_arp=1 عن كل ما يُوجَّه إلى مكان آخر، وهو أوسع من أن يخلو من مفاجآته على مقطع مزدحم.
أياً كان المسار الذي تختاره، أزل NAT بين النفق والكابل. قاعدة MASQUERADE تخفي بالضبط مسألة العنونة التي تحاول الإجابة عنها. وتترك للشخص التالي طوبولوجيا لا يستطيع التفكير فيها من جهة العميل.
قبل تغيير أي شيء، التقط محاولة واحدة على الخادم باستخدام tcpdump -ni tun0 وتأكد مما إذا كانت حزمة القرين تصل أصلاً. الوصول ثم الإسقاط يشير إلى client-to-client؛ وعدم الوصول أبداً يشير إلى الطوبولوجيا أو التوجيه. دليل OpenVPN 2.6 يوثّق الكلمتين المفتاحيتين والافتراضي في الطوبولوجيا، ويستحق المقارنة بإصدارك قبل نسخ سطر من منشور منتدى.
- واجهة tun تُظهر قناع مجمع بدلاً من زوج قرين /30.
- نجاح ping مباشر إلى عنوان النفق الآخر قبل اختبار الاكتشاف.
- يتضمن إعداد الخادم
client-to-clientكلما وجب على الأقران تبادل الحزم. - سمِّ بروتوكول الاكتشاف الذي تختبره بدلاً من القول إن التطبيق يفشل.
- استخدم TAP فقط إذا كانت كل منصة عميل في المجموعة تدعمه.
- أبقِ NAT خارج المسار بين النفق والشبكة المحلية عندما تكون إمكانية الوصول داخل الشبكة الفرعية نفسها مهمة.