udp over tcp
v0.1.3
أداة سطر أوامر لنفق مخططات بيانات UDP عبر TCP.
إنه مفيد بشكل خاص لنفق UDP عبر SSH
تم تصميم الأداة بشكل أساسي لحالة الاستخدام حيث يكون لديك تطبيقان يحتاجان إلى التحدث مع بعضهما البعض عبر UDP دون وجود علاقة واضحة بين خادم العميل. أي أن أيًا من التطبيقين قد يبدأ حزمة، ويجب تهيئته باستخدام عنوان الآخر عند بدء التشغيل (أي، لا يمكن أن تكون المنافذ عشوائية).
يمكنك تشغيل udp-over-tcp على مضيفي التطبيقين. يعمل كل مثيل كنوع من النسخ المتماثلة المحلية على التطبيق الذي يعمل على الآخر. إذا كان التطبيق الموجود على أحد المضيفين يستمع إلى منفذ UDP P، فسوف يستمع udp-over-tcp إلى منفذ UDP P على المضيف الآخر ، ويتأكد من أن حركة المرور إلى النسخة udp-over-tcp P تنتقل إلى منفذ التطبيق الحقيقي P. سيقوم udp-over-tcp بذلك لمنافذ كلا التطبيقين في نفس الوقت ويربط المنافذ. سوف "يتظاهر" بشكل فعال بأن كل تطبيق يعمل محليًا على الآخر.
بشكل ملموس، إذا أرسل التطبيق الموجود على أحد المضيفين مخطط بيانات من المنفذ P الخاص به إلى المنفذ (النسخة المتماثلة المحلية) Q، فسيصل مخطط البيانات إلى منفذ التطبيق الحقيقي (البعيد) Q مع منفذ مصدر P . وهذا يعني أن التطبيق يرى دائمًا نفس العنوان الفردي (المضيف المحلي) والمنفذ (منفذ التطبيق الآخر)، ويمكن أيضًا استخدام نفس زوج العنوان والمضيف في تكوين النظير للتطبيق.
نأمل أن يساعد الرسم التخطيطي التالي في فهم تكوينات إعداد udp-over-tcp :
يأتي البرنامج مُجمَّعًا مسبقًا لعدد من المنصات (شكرًا لـ Cargo-dist!)، ويجب أن يكون قابلاً للتنفيذ دون أي تبعيات.
وبدلاً من ذلك، يمكنك تثبيته من خلال Cargo باستخدام
$ cargo install udp-over-tcp لديك تطبيق UDP يعمل على المضيف X على المنفذ A. وتريده أن يتحدث مع تطبيق UDP يعمل على المضيف Y على المنفذ B. وتريد أيضًا السماح للتطبيق الموجود على Y بالتحدث إلى A على X. عظيم، افعل ذلك على النحو التالي:
على أي من المضيفين (هنا X)، قم أولاً بإنشاء نفق TCP للمضيف الآخر:
ssh -L 7878:127.0.0.1:7878 $Y
بعد ذلك، قم بتشغيل udp-over-tcp على كلا المضيفين، أحدهما باستخدام --tcp-listen والآخر باستخدام --tcp-connect . يجب استخدام --tcp-listen على المضيف الذي تسمح عملية إعادة التوجيه بالاتصال به (هنا Y). يمكنك تشغيلها بأي ترتيب، ولكن أفضل الممارسات هي الاستماع أولاً:
Y $ udp-over-tcp --tcp-listen 7878 --udp-bind $A --udp-sendto $B
X $ udp-over-tcp --tcp-connect 7878 --udp-bind $B --udp-sendto $A
على Y، سيستمع هذا إلى منفذ UDP $A، ويعيد توجيه تلك عبر TCP إلى X، ثم يسلمها إلى منفذ UDP $A هناك. على X، سوف يستمع هذا على منفذ UDP $B، ويعيد توجيه تلك عبر TCP إلى Y، ثم يسلمها إلى منفذ UDP $B هناك.
الآن قم بتكوين التطبيق على X للإرسال إلى 127.0.0.1:$B وقم بتكوين التطبيق على Y للإرسال إلى 127.0.0.1:$A. وبعبارة أخرى، نفس المنفذ، عنوان IP المحلي.
تأخذ كل وسيطة رقم منفذ (كما هو مذكور أعلاه) أو addr:port لتحديد العنوان. (العنوان الافتراضي هو 0.0.0.0 للاستماع/الربط و127.0.0.1 للاتصال/الإرسال إلى)
توجد أدوات أخرى يمكن أن تساعد في حل هذه المشكلة، على الرغم من أن لها خصائص مختلفة عن هذه الأداة.
الحلول التي تعتمد على nc أو socat لا تحافظ على حدود مخططات بيانات UDP، مما يعني أن sendmsg UDP يمكن أن يتسببا في وصول رسالة واحدة (مجمعة) فقط من خلال recvfrom . لا تتمتع العديد من تطبيقات UDP بالمرونة تجاه هذا لأنها تعتمد على UDP لتوفير إطار الرسالة.
يوفر UDP-over-TCP الخاص بـ Mullvad إعادة توجيه أحادية الاتجاه فقط. يمكن للمرء تشغيل مثيلات إضافية للأداة لإعادة التوجيه في الاتجاه الآخر، على الرغم من أن القيام بذلك يعني أن منفذ المصدر لمخططات البيانات الواردة لن يتطابق مع منفذ الوجهة لمخططات البيانات الصادرة. ومع ذلك، من المحتمل أن يكون هذا جيدًا بالنسبة لتطبيقات نمط خادم العميل حيث لا يكون منفذ العميل مهمًا.
مرخص بموجب أي من
في خيارك.
ما لم تنص صراحةً على خلاف ذلك، فإن أي مساهمة يتم تقديمها عمدًا لتضمينها في العمل بواسطتك، كما هو محدد في ترخيص Apache-2.0، يجب أن تكون مرخصة بشكل مزدوج على النحو الوارد أعلاه، دون أي شروط أو أحكام إضافية.
