الصفحة الرئيسية>كود المصدر CGI>فئات أخرى
تنزيل

UDP النفق العكسي

ما نوع المشكلة التي يحلها هذا؟

قصة الخلفية

لدي خادم Wireguard يعمل في المنزل حتى أتمكن من الدخول إلى شبكتي المنزلية من الخارج. يستخدم Wireguard UDP. لسوء الحظ، لا يمكنني فقط فتح منفذ IPv4 UDP في صندوق فريتز الخاص بي كما كان يعمل في الأيام الخوالي لأن مزود الخدمة الخاص بي وضعني خلف CG-NAT، ولا بد لي من استخدام IPv6 ولكن IPv6 ليس قابلاً للاستخدام بعد في مكان عملي.

لذلك لدي IPv6 في المنزل وفي العمل لدي IPv4 ولا توجد طريقة للوصول إلى شبكتي المنزلية.

لدي أيضًا VPS مع IPv4 عام يمكنني من خلاله إنشاء أنفاق ssh عكسية لحركة مرور TCP. لسوء الحظ، تدعم أنفاق ssh فقط TCP ولا ينبغي للمرء إجراء اتصالات VPN عبر TCP على أي حال، وهذا هو السبب وراء استخدام wireguard لـ UDP فقط.

مشكلة 

 VPN-Server                                 VPN-Client
  (UDP)         |        |                 (IPv4 UDP)
    |           |        | not possible        |
     -----------|--------| <-------------------
                |        |
               NAT     CG-NAT

حل 

 VPN-Server                                 VPN-Client
  (UDP)                                    (IPv4 UDP)
    |                                          |
    |                                          |
inside agent                              outside agent
   tunnel                                    tunnel
    ||          |         |                    ||
    ||     punch|    punch|                    ||
    | --------->|-------->|-------------------- |
     -----------|<--------|<--------------------
                |         |
                |         |
               NAT     CG-NAT

يعمل الوكيل الخارجي على VPS مع IPv4 العام

سيرسل الوكيل الداخلي مخططات بيانات UDP إلى عنوان IP العام ومنفذ الوكيل الخارجي، وهذا سيؤدي إلى إحداث ثغرات في كل من NAT، وسيتلقى الوكيل الخارجي مخططات البيانات هذه ويتعلم من عنوان المصدر والمنفذ كيفية إرسال مخططات البيانات مرة أخرى إلى الوكيل الداخلي .

يمكن لعميل VPN إرسال UDP إلى الوكيل الخارجي وسيتم إعادة توجيه مخططات البيانات هذه إلى الوكيل الداخلي ومن هناك إلى خادم VPN، ويمكن لخادم VPN الرد على الوكيل الداخلي، وسيتم إعادة توجيهها إلى الوكيل الخارجي ومن هناك إلى عميل VPN.

سيظهر الوكيل الخارجي كخادم VPN للعميل، وسيظهر الوكيل الداخلي كعميل VPN للخادم.

اتصالات العملاء المتعددة ممكنة لأنها ستستخدم نفقًا ومقبسًا جديدًا على الوكيل الداخلي لكل عميل جديد يتصل من الخارج، لذلك سيظهر للخادم كما لو كان هناك عملاء متعددون يعملون على مضيف الوكيل الداخلي.

التثبيت والاستخدام

قم باستنساخ أو فك ضغط الكود الموجود على كلا الجهازين وقم بإنشائه. تحتاج على الأقل إلى make و gcc. أدخل الدليل المصدر واستخدم الأمر 

 $ make

بعد الإنشاء الناجح، سينتهي بك الأمر مع udp-tunnel الثنائي في نفس المجلد. الآن يمكنك إما تشغيله مباشرة من الوحدة الطرفية (مع الخيارات الصحيحة بالطبع) لإجراء بعض الاختبارات السريعة، أو يمكنك تثبيته بمساعدة ملف makefile.

اختبار سريع دون تثبيت

يمكن udp-tunnel الثنائي المترجم أن يعمل إما كوكيل داخلي أو كوكيل خارجي، اعتمادًا على الخيارات التي تمررها في سطر الأوامر.

لنفترض كمثال أن خادم VPN يستمع إلى UDP 1234، ويعمل على مضيف محلي (مثل الوكيل الداخلي) والجهاز الخارجي هو Jump.example.com ونريد أن يستمع على منفذ UDP 9999.

في المضيف الداخلي نبدأ به 

 $ ./udp-tunnel -s localhost:1234 -o jump.example.com:9999

على المضيف الخارجي نبدأ به 

 $ ./udp-tunnel -l 9999

التثبيت مع makefile

يحتوي ملف makefile على 3 أهداف تثبيت: install لتثبيت الملفات الثنائية فقط، install-outside ، install-inside لتثبيت ملفات خدمة systemd أيضًا. يحتاج الأخيران إلى متغيرات تم تمريرها حتى تعمل بشكل صحيح.

لتثبيت الوكيل الخارجي على مضيف الانتقال (بافتراض أنك تريد المنفذ 9999)، عليك تنفيذ هذا الأمر: 

 $ sudo make install-outside listen=9999

سيؤدي هذا إلى تثبيت الملف الثنائي في /usr/local/bin/ وتثبيت ملف خدمة systemd في /etc/systemd/system/ الذي يحتوي على الأمر المطلوب لبدء تشغيله في وضع الوكيل الخارجي باستخدام المنفذ 9999.

لتثبيت الوكيل الداخلي على الجهاز الداخلي، استخدم الأمر التالي (بافتراض أن خادم VPN الخاص بك هو localhost:1234 كمثال ومضيف الانتقال السريع الخاص بك هو Jump.example.com): 

 $ sudo make install-inside service=localhost:1234 outside=jump.example.com:9999

سيؤدي هذا مرة أخرى إلى تثبيت الملف الثنائي في /usr/local/bin/ وملف وحدة systemd في /etc/systemd/system/

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

بعد تثبيت ملفات systemd والتأكد من صحتها، لم يتم تمكينها بعد لبدء التشغيل التلقائي، فأنت بحاجة إلى تمكينها وبدء تشغيلها. على الجهاز الداخلي: 

 $ sudo systemctl enable udp-tunnel-inside.service
$ sudo systemctl start udp-tunnel-inside.service

وعلى الجهاز الخارجي 

 $ sudo systemctl enable udp-tunnel-outside.service
$ sudo systemctl start udp-tunnel-outside.service

حماية

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

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

في المضيف الداخلي ستستخدمه على هذا النحو 

 $ ./udp-tunnel -s localhost:1234 -o jump.example.com:9999 -k mysecretpassword

على المضيف الخارجي ستبدأ به 

 $ ./udp-tunnel -l 9999 -k mysecretpassword

بعد نجاح خطوات التثبيت المذكورة أعلاه، قد ترغب في تحرير ملفات systemd يدويًا على كلا الطرفين وإضافة خيار -k، ثم إعادة التحميل وإعادة التشغيل على كلا الطرفين.

ستحتوي رسالة البقاء على قيد الحياة بعد ذلك على SHA-256 فوق كلمة المرور هذه وعلى رقم متزايد بشكل صارم يمكن استخدامه مرة واحدة فقط لمنع هجمات إعادة التشغيل البسيطة.

كيف يعمل

يحتفظ كلا الوكيلين بقائمة من الاتصالات، ويقوم كل اتصال بتخزين عناوين مأخذ التوصيل ومقابض مأخذ التوصيل المرتبطة باتصال العميل المحدد.

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

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

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

في هذه المرحلة، يمتلك كلا العميلين نفقين في قائمتهما، أحدهما نشط والآخر احتياطي، في انتظار اتصال العميل التالي.

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

احذر

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

يوسع
معلومات إضافية
تطبيقات ذات صلة
نوصي لك
أخبار ذات صلة الكل