tunnel
1.0.0
معيد توجيه منفذ TCP/UDP آمن ومتعدد الإرسال باستخدام خادم الأنابيب بواسطة @nwtgck كمرحل. تم تصميمه بشكل أساسي لاتصالات p2p بين الأقران خلف (متعددة) NAT/جدران الحماية.
بالنسبة للحالة الخاصة لـ IPFS ، راجع #الأمثلة أدناه.
المعرف: يتم منح كل عقدة معرفًا فريدًا (base64) -
tunnel -iيرتبط المعرف بالأجهزة (عنوان MAC) ومتغيرات البيئة USER وHOME وHOSTNAME. شاركها مع زملائك مرة واحدة وإلى الأبد. ملاحظة: يتم منح اثنين من المستخدمين على نفس الجهاز معرفات عقدة منفصلة لأن متغيرات المستخدم والمنزل الخاصة بهما تختلف.
وضع الخادم: كشف المنفذ المحلي الخاص بك للأقران الذين تشارك معهم أي سلسلة سرية -
tunnel [options] [-u] [-k < shared-secret > ] < local-port >وضع العميل: قم بإعادة توجيه المنفذ المحلي الخاص بك إلى المنفذ المحلي المكشوف الخاص بالنظير -
tunnel [options] [-u] [-k < shared-secret > ] [-b < local-port > ] [-I < IP > ] < peer-ID:peer-port > إذا لم يتم توفير منفذ محلي باستخدام الخيار -b ، فسيستخدم tunnel منفذًا عشوائيًا غير مستخدم. يتم دائمًا الإبلاغ عن المنفذ المستخدم في stdout.
يكون الخيار -I مفيدًا عند تشغيل العميل على جهاز كمبيوتر محمول يتصل أحيانًا بشبكة LAN التي يعمل بها الخادم. عندما يمكن العثور على الخادم على شبكة LAN باستخدام عنوان IP الخاص = <IP> ، يتصل tunnel عبر شبكة LAN.
يجب أن يستخدم العميل والخادم نفس السر ليتمكنوا من الاتصال ببعضهم البعض. يمكن أيضًا تمرير السلسلة السرية باستخدام متغير البيئة TUNNEL_KEY . السر الذي تم تمريره بـ -k له الأسبقية.
تشير العلامة -u إلى استخدام UDP بدلاً من TCP الافتراضي. إذا تم استخدامه، يجب استخدامه من قبل كلا الزملاء.
جميع السجلات موجودة في stderr بشكل افتراضي. ومع ذلك، باستخدام الخيار -l <logfile> ، يمكن تشغيل tunnel في الخلفية ( وضع البرنامج الخفي ) مع حفظ السجلات في <logfile> . يتم عرض معرف عملية البرنامج الخفي للمستخدم أثناء التشغيل حتى يتمكن من قتل البرنامج الخفي في أي وقت
tunnel -K < procID >خيارات:
للحصول على قائمة كاملة بالخيارات، راجع: tunnel -h
تحميل مع:
curl -LO https://raw.githubusercontent.com/SomajitDey/tunnel/main/tunnelاجعله قابلاً للتنفيذ:
chmod +rx ./tunnelثم قم بالتثبيت على مستوى النظام باستخدام:
./tunnel -c install إذا لم يكن لديك امتياز sudo ، فيمكنك التثبيت محليًا بدلاً من ذلك:
./tunnel -c install -lللتحديث في أي وقت بعد التثبيت:
tunnel -c update هذا البرنامج هو ببساطة برنامج bash قابل للتنفيذ يعتمد على أدوات GNU القياسية بما في ذلك socat و openssl و curl و mktemp و cut و awk و sed و flock و pkill و dd و xxd و base64 وما إلى ذلك المتوفرة بسهولة على توزيعات Linux القياسية.
إذا كان نظامك يفتقر إلى أي من هذه الأدوات، ولم يكن لديك امتياز sudo المطلوب لتثبيته من مستودع الحزمة الأصلي (على سبيل المثال sudo apt-get install <package> )، فحاول تنزيل ملف ثنائي محمول وتثبيته محليًا على ${HOME}/.bin .
سش :
يكشف النظير أ عن منفذ SSH المحلي -
tunnel -k " ${secret} " 22يتصل النظير ب -
tunnel -b 67868 -k " ${secret} " -l /dev/null " ${peerA_ID} :22 " # Daemon due to -l
ssh -l " ${login_name} " -p 67868 localhost إيبس :
دع النظير A لديه معرف IPFS-peer: 12orQmAlphanumeric . يستمع برنامج IPFS الخاص بها إلى منفذ TCP الافتراضي رقم 4001. وتكشفه باستخدام -
tunnel -k " ${swarm_key} " ipfs swarm_key هو مجرد أي سلسلة سرية قد يستخدمها نظير "أ" للتحكم في من يمكنه الاتصال بها باستخدام tunnel .
يتصل النظير B الآن مع النظير A لمشاركة الملفات أو pubsub أو p2p -
tunnel -k " ${swarm_key} " 12orQmAlphanumericيتصل سرب الأوامر الأخير هذا بالنظير "أ" من خلال مرحل خادم الأنابيب ويستمر في اتصال السرب كل بضع ثوانٍ في الخلفية للحفاظ على الاتصال حيًا.
يبدأ tunnel برنامج IPFS في الخلفية إذا لم يكن نشطًا بالفعل.
يمكن تمرير المسار إلى IPFS repo باستخدام الخيار -r . بخلاف ذلك، يتم استخدام متغير البيئة IPFS_PATH أو المسار الافتراضي ~/.ipfs كالمعتاد. مثال: tunnel -r ~/.ipfs -i يعطي معرف نظير IPFS.
شل البعيد :
لنفترض أنك ستحتاج بانتظام إلى تشغيل الأوامر في صندوق Linux في مكان عملك من جهازك المنزلي. وأنت لا تريد/لا تستطيع استخدام SSH عبر tunnel لسبب ما.
في كمبيوتر مكان العمل، قم بكشف بعض منافذ TCP المحلية العشوائية، على سبيل المثال 49090 وقم بتوصيل الصدفة بهذا المنفذ:
tunnel -l " /tmp/tunnel.log " -k " your secret " 49090 # Note the base64 node id emitted
socat TCP-LISTEN:49090,reuseaddr,fork SYSTEM: ' bash 2>&1 'العودة إلى منزلك:
tunnel -l " /dev/null " -b 5000 -k " your secret " " node_id_of_workplace:49090 "
rlwrap nc localhost 5000استخدام rlwrap ليس ضرورة. ولكنه بالتأكيد يجعل التجربة أفضل لأنه يستخدم GNU Readline ويتذكر سجل الإدخال (يمكن الوصول إليه باستخدام مفاتيح الأسهم لأعلى/لأسفل المشابهة لجلسات bash المحلية).
ريديس :
هل تحتاج إلى الاتصال بمثيل Redis البعيد الذي يستضيفه أحد الأقران أو تستضيفه بنفسك؟ في المضيف البعيد، اكشف عن منفذ TCP الذي يعمل عليه redis-server (الافتراضي: 6379)، باستخدام tunnel .
على جهازك المحلي، استخدم tunnel لإعادة توجيه منفذ TCP إلى المنفذ البعيد. قم بتوجيه redis-cli إلى المنفذ المحلي المُعاد توجيهه.
فيما يلي بعض حالات الاستخدام العشوائية التي يمكنني التفكير فيها tunnel . بشكل عام، أي شيء يتضمن اجتياز NAT/جدار الحماية (على سبيل المثال WebRTC بدون TURN) أو الانضمام إلى شبكة LAN بعيدة، يجب أن يجد tunnel مفيدًا. بعض الأفكار التالية غير واضحة إلى حد ما، ولم يتم اختبارها على الإطلاق، وربما لا تعمل، ولكن مع ذلك تم توثيقها هنا، على الأقل في الوقت الحالي، فقط من أجل الإلهام. إذا وجدت أيًا من هذه الأشياء مفيدة، أو غير مجدية، أو وجدت تطبيقات جديدة تمامًا tunnel ، فيرجى النشر في المناقشات. تم تصنيف الحالات التي قمت باختبارها على أنها "عاملة".
tunnel .tunnel في Heroku (مجانًا) وإعادة توجيه المنفذ المخزن في متغير البيئة PORT إلى المنفذ المحلي الذي تريد كشفه. ولديك عنوان URL العام الخاص بك على النحو التالي: https://your-app-name.herokuapp.com.tunnel . يقوم tunnel بتشفير كل حركة المرور بين النظير والمرحل باستخدام TLS، إذا كان المرحل يستخدم https. لا يوجد تشفير شامل في حد ذاته بين الأقران أنفسهم. ومع ذلك، يُزعم أن مرحل خادم الأنابيب لا يمكن تخزينه .
يمكن لنظير العميل الاتصال بنظير يخدم فقط إذا كان يستخدم نفس المفتاح السري (TUNNEL_KEY). يُستخدم المفتاح بشكل أساسي لاكتشاف الأقران في مرحلة الترحيل. لكل اتصال جديد بالمنفذ المحلي المعاد توجيهه، يرسل العميل مفتاح جلسة عشوائي إلى النظير الذي يخدم. يقوم الأقران بعد ذلك بتكوين اتصال جديد عند نقطة ترحيل أخرى بناءً على هذا المفتاح العشوائي حتى يتم نقل البيانات الفعلي. الغرباء، أي. لا ينبغي للجهات الفاعلة السيئة التي لا تعرف TUNNEL_KEY أن تكون قادرة على تعطيل هذا التدفق.
ومع ذلك، يمكن للنظير الضار القيام بما يلي. نظرًا لأنه يعرف TUNNEL_KEY ومعرف العقدة للنظير الخادم، فيمكنه انتحال شخصية الأخير. وبالتالي، سيتم إرسال البيانات الواردة من نظير متصل غير متوقع إلى المنتحل، مما يؤدي إلى تجويع الخادم الأصلي. يجب أن تتعامل التحديثات/التطبيقات المستقبلية tunnel مع هذا التهديد باستخدام تشفير المفتاح العام. [في هذه الحالة، سيكون مفتاح الجلسة العشوائي الذي يتم إنشاؤه لكل اتصال جديد تتم إعادة توجيهه قابلاً لفك التشفير بواسطة الخادم الأصلي وحده].
نظرًا لأن tunnel هو في الأساس طبقة النقل، فلا ينبغي أن تكون النقاط المذكورة أعلاه محبطة، لأن معظم التطبيقات مثل SSH وIPFS تقوم بتشفير البيانات في طبقة التطبيق. إن تشفير tunnel من طرف إلى طرف لجميع عمليات نقل البيانات لن يؤدي إلا إلى زيادة زمن الوصول. ومع ذلك، يمكنك دائمًا إنشاء نفق SSH بعد إنشاء النظير منخفض المستوى مع tunnel ، إذا اخترت ذلك.
المرحل الافتراضي الذي يستخدمه tunnel هو https://ppng.io. يمكنك أيضًا استخدام بعض الترحيلات العامة الأخرى من هذه القائمة أو استضافة المثيل الخاص بك على الخدمات المجانية مثل تلك التي تقدمها Heroku. وغني عن القول أنه للاتصال، يجب على اثنين من أقرانهما استخدام نفس التتابع.
إذا اخترت ذلك، يمكنك أيضًا كتابة المرحل الخاص بك لاستخدامه في tunnel باستخدام أدوات بسيطة مثل sertain. فقط تأكد من أن خدمة الترحيل الخاصة بك تحتوي على نفس واجهة برمجة التطبيقات مثل خادم الأنابيب. إذا كان رمز التتابع الخاص بك مفتوح المصدر، فنحن نرحب بك لتقديمه في المناقشات.
gsocket ; ipfs p2p مع تمكين مرحل الدائرة؛ الذهاب الأنابيب المزدوجة؛ Pipeto.me ; الوصلة الصاعدة ; localhost.run ; نجروك ; النفق المحلي sshreach.me ( نسخة تجريبية مجانية لفترة محدودة فقط ) ; أكثر
ملحوظات:
tunnel والأنابيب، يمكنك ببساطة نشر مثيل الترحيل الخاص بك، ومشاركة عنوان URL العام الخاص به مع أقرانك مرة واحدة وإلى الأبد، export نفس TUNNEL_RELAY داخل .bashrc ، وستكون جاهزًا للبدء. كما تتوفر العديد من خوادم الأنابيب العامة للتكرار.IPFS (تم):
سيكون الاتصال بـ IPFS أسهل بكثير:
tunnel -k <secret> ipfs للكشف tunnel -k <secret> <IPFS_peerID> للاتصال.
سيؤدي ذلك إلى تشغيل البرنامج الخفي IPFS من تلقاء نفسه، في حالة عدم الاتصال بالإنترنت. سيتصل الأمر الأخير بشكل متكرر بالنظير المحدد على فترات زمنية مدتها 30 ثانية. سيتم استخدام معرف IPFS-peer-ID كمعرف العقدة، لذلك لن يحتاج النظراء بعد الآن إلى مشاركة معرفات العقد الخاصة بهم بشكل منفصل. قد يتم تمرير مسارات IPFS غير الافتراضية باستخدام الخيار -r . أو IPFS_PATH .
سش:
سيكون إنشاء نفق SSH بين المنفذ المحلي ومنفذ النظير أمرًا سهلاً كما يلي:
tunnel -k <secret> ssh لكشف &
tunnel -sk <secret> -b <local-port> <peerID>:<peer-port> للإنشاء.
لاحظ أنه أثناء الاتصال، لم يعد الشخص بحاجة إلى تقديم اسم تسجيل دخول. يتم أخذ ${USER} الخاص بعقدة الخدمة كاسم تسجيل الدخول افتراضيًا. ومع ذلك، إذا لزم الأمر، يمكن دائمًا تمرير اسم تسجيل دخول غير افتراضي باستخدام متغير أو خيار البيئة.
جي بي جي:
لا تحتوي الأجهزة الافتراضية، مثل تلك التي تستخدمها السحابات السحابية والدينامو، على عناوين أجهزة ثابتة وفريدة من نوعها. وبالتالي يستمر معرف العقدة في التغير من جلسة إلى أخرى لمثل هذا الجهاز الافتراضي. سيكون tunnel المستقبلي خيار -g والذي من شأنه تمرير مفتاح GPG الخاص إلى tunnel . سيتم إنشاء معرف العقدة من بصمة هذا المفتاح، على غرار ما يفعله IPFS. وهذا من شأنه أيضًا أن يجعل tunnel أكثر أمانًا.
الأرجون 2:
الخيار [ -a ] لاستخدام argon2 لتجزئة TUNNEL_KEY قبل الاستخدام، بحيث لا يكون السر الأضعف عرضة للخطر.
يرجى الإبلاغ عن الأخطاء في القضايا. انشر أفكارك وتعليقاتك وأفكارك وحالات الاستخدام وطلبات الميزات في المناقشة. اسمحوا لي أن أعرف كيف ساعدك هذا، إذا كان قد حدث على الإطلاق.
لا تتردد أيضًا في الكتابة لي مباشرة حول أي شيء يتعلق بهذا المشروع.
إذا كان هذا السيناريو الصغير مفيدًا لك، فسيكون النجم مشجعًا للغاية بالنسبة لي.
شكرًا ! ؟
