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

نفق

يحتوي هذا الريبو على العميل والخادم الذي يسمح لك بتمرير حركة مرور TCP وUDP عبر بروتوكولات الشبكة الأخرى.

الأنفاق المدعومة حاليًا هي:

  • DNS (خادم موثوق أو اتصال مباشر)
  • TLS (المصادقة المتبادلة)
  • برنامج التعاون الفني

الأداة الرئيسية مكتوبة بلغة Rust والاختبارات الشاملة مكتوبة بلغة Python.

تثبيت

الخيار 1: صور عامل الإرساء للعميل والخادم 

docker pull ghcr.io/dlemel8/tunneler-server:latest
docker pull ghcr.io/dlemel8/tunneler-client:latest

الخيار 2: ترجمة من التعليمات البرمجية المصدر 

cargo --version || curl --proto ' =https ' --tlsv1.2 -sSf https://sh.rustup.rs | sh
cargo build --release

يوجد أيضًا ملف عامل إرساء إذا كنت تفضل إنشاء صورة عامل إرساء محلي

الاستخدام

الخيار 1: صور عامل الإرساء للعميل والخادم 

docker run -e LOCAL_PORT=45301 
           -e REMOTE_PORT=5201 
           -e REMOTE_ADDRESS=localhost 
           -e TUNNELED_TYPE=udp 
           --rm -p 45301:45301 ghcr.io/dlemel8/tunneler-server:latest tcp

الخيار 2: ثنائي مترجم محليا 

./target/release/client 
  --tunneled-type tcp 
  --remote-address 1.1.1.1 
  --remote-port 53 
  --log-level debug 
  dns 
  --read-timeout-in-milliseconds 100 
  --idle-client-timeout-in-milliseconds 30000

قم بتشغيل صورة عامل الإرساء أو الملف الثنائي المترجم باستخدام --help لمزيد من المعلومات

اختبار

تشغيل اختبارات الوحدة 

cargo test --all-targets

تشغيل الاختبارات الشاملة 

python3 -m pip install -r e2e_tests/requirements.txt
PYTHONPATH=. python3 -m pytest -v

أمثلة

يحتوي هذا الريبو على بعض أمثلة نشر الخادم باستخدام Docker Compose:

  • اختبار السرعة - خادم iperf3 مكشوف عبر جميع الأنفاق المدعومة، مما يسمح لك بمقارنة سرعة الأنفاق.
  • DNS المعتمد - تم الكشف عن خادم Redis عبر نفق DNS على المنفذ UDP/53. نظرًا لأن النفق لا يتحقق من العملاء، فإن مصادقة Redis مطلوبة.
  • خط الأنابيب - تم كشف خادم Redis عبر نفق TLS والذي تم كشفه بنفسه عبر نفق DNS. نظرًا لأن النفق يقوم بالتحقق من العملاء، فلن يتم استخدام مصادقة Redis.

يمكنك تشغيل كل مثال محليًا أو نشره باستخدام Terraform وAnsible. رؤية المزيد من المعلومات هنا.

بنيان

Architecture يحتوي كل ملف قابل للتنفيذ على مكونين يتواصلان عبر قناة تدفقات العميل (مجموعة من وحدات البايت للقارئ والكاتب):

  • يقوم مستمع العميل بربط مأخذ توصيل وتحويل حركة المرور الواردة والصادرة إلى دفق جديد.
  • يقوم Client Tunneler بترجمة قارئ الدفق والكاتب إلى بروتوكول النفق.
  • يقوم Server Untunneler بربط مأخذ توصيل وفقًا لبروتوكول النفق وترجمة حركة المرور عبر النفق إلى الدفق الأصلي.
  • يقوم Server Forwarder بتحويل كاتب الدفق والقارئ مرة أخرى إلى حركة المرور.

يتم تحويل حركة المرور المستندة إلى TCP بشكل تافه إلى دفق. يعتمد تحويل حركة المرور المستند إلى UDP على بروتوكول النفق.

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

البروتوكولات

UDP النفقي

من أجل تحويل حركة مرور UDP إلى دفق، يسبق رأس بحجم 2 بايت (في النهاية الكبيرة) كل حمولة حزمة.

يستخدم مستمع UDP عنوان نظير الحزمة الواردة كمفتاح لذاكرة التخزين المؤقت للعملاء.

نفق DNS

لدينا بعض التحديات هنا:

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

لحل هذه التحديات، تبدأ كل جلسة عميل بإنشاء معرف عميل عشوائي (4 أحرف أبجدية رقمية). يقرأ العميل البيانات إلى النفق ويقوم بتشغيلها عبر سلسلة من أجهزة التشفير:

  • يتم ترميز البيانات بالنظام السداسي.
  • تم إلحاق معرف العميل.
  • يتم إلحاق لاحقة العميل. في حالة تشغيل الخادم على خادم DNS المعتمد الخاص بك، تكون اللاحقة ".<مجالك>".

يتم بعد ذلك استخدام البيانات المشفرة كاسم لاستعلام DNS TXT.

إذا كنت تمتلك خادم DNS موثوقًا، فيمكن للعميل إرسال الطلب إلى محلل DNS المتكرر. سيحصل Resolver على عنوان IP الخاص بك من مسجل اسم النطاق الخاص بك ويعيد توجيه الطلب إلى عنوان IP الخاص بك. هناك خيار آخر (أسرع ولكن أكثر وضوحًا لأي محلل لحركة المرور) وهو تكوين العميل لإرسال الطلب مباشرة إلى IP الخاص بك (على المنفذ UDP/53 أو أي خادم منفذ آخر يستمع إليه).

يقوم الخادم بفك تشفير البيانات (متجاهلاً أي حركة مرور غير خاصة بالعميل) ويستخدم معرف العميل كمفتاح لذاكرة التخزين المؤقت للعملاء.

من أجل التعامل مع استجابات الخادم الكبيرة وإقرارات TCP الفارغة، يتم استخدام مهلة القراءة في كل من العميل والخادم. إذا انتهت مهلة القراءة، سيتم إرسال رسالة فارغة. يستخدم كل من العميل والخادم مهلة الخمول لإيقاف إعادة توجيه الموارد المحلية وتنظيفها.

نفق TLS

لتنفيذ المصادقة المتبادلة، نستخدم مرجعًا مصدقًا خاصًا:

  • يتم إنشاء شهادة CA موقعة ذاتيًا من مفتاح خاص.
  • يتم إنشاء المفتاح الخاص للخادم بشكل عشوائي ويتم استخدام الجزء العام منه في شهادة موقعة بواسطة شهادة CA.
  • يتم إنشاء المفتاح الخاص للعميل بشكل عشوائي ويتم استخدام الجزء العام منه في شهادة موقعة بواسطة شهادة CA.

تم تكوين كل من العميل والخادم لاستخدام المفتاح والشهادة في مصافحة TLS. يتم استخدام شهادة CA كشهادة جذر.

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

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