مرّر بيانات IPv4 عبر خوادم DNS لتجاوز قيود جدار الحماية وتوفير وصول شبكة خفي لاختبار الاختراق.
هذا برنامج يتيح لك أنفاق بيانات IPv4 عبر خادم DNS. يمكن أن يكون مفيدًا في حالات مختلفة حيث يكون الوصول إلى الإنترنت محجوبًا بجدار ناري، لكن استعلامات DNS مسموح بها.
لترجمة iodine تحتاج إلى meson.
نفّذ الأوامر التالية للترجمة داخل دليل build:
meson setup build
cd build
ninja
للبناء وتشغيل الاختبارات تحتاج إلى مكتبة check. ابدأها بتشغيل
ninja test داخل دليل البناء.
جرّبه داخل شبكتك المحلية (LAN) الخاصة بك! اتبع هذه الخطوات البسيطة:
./iodined -f 10.0.0.1 test.com.
إذا كنت تستخدم شبكة 10.0.0.0 بالفعل، فاستخدم شبكة داخلية أخرى مثل
172.16.0.0../iodine -f -r 192.168.0.1 test.com.
استبدل 192.168.0.1 بعنوان IP الخاص بخادمك.10.0.0.2 ولدى الخادم 10.0.0.1.لاستخدامه فعليًا عبر خادم أسماء مُمرِّر (relaying nameserver)، انظر أدناه.
ملاحظة: يجب أن يتحدث الخادم والعميل البروتوكول نفسه بالضبط. في معظم الحالات، يعني هذا تشغيل إصدار iodine نفسه. لسوء الحظ، فإن تنفيذ التوافق البروتوكولي للخلف والأمام عادةً غير ممكن.
لاستخدام هذا النفق، تحتاج إلى التحكم في نطاق حقيقي (مثل mydomain.com)،
وخادم بعنوان IP عام لتشغيل iodined عليه. إذا كان هذا الخادم
يشغّل برنامج DNS بالفعل، فغيّر منفذ الاستماع الخاص به ثم استخدم خيار
-b الخاص بـ iodined للسماح لـ iodined بإعادة توجيه طلبات DNS. (لاحظ أن هذا الإجراء
غير مُستحسن في بيئات الإنتاج، لأن إعادة التوجيه DNS الخاصة بـ iodined
ليست شفافة تمامًا، على سبيل المثال لن تعمل عمليات نقل المناطق (zone transfers).)
بدلاً من ذلك يمكنك إعادة توجيه النطاق الفرعي من خادم DNS الخاص بك إلى iodined
والذي يجب حينها أن يعمل على منفذ مختلف (-p).
بعد ذلك، فوّض نطاقًا فرعيًا (لنقل، t1.mydomain.com) إلى خادم iodined.
إذا كنت تستخدم BIND لنطاقك، فأضف سطرين مثل هذين إلى ملف المنطقة:
t1 IN NS t1ns.mydomain.com. ; note the dot!
t1ns IN A 10.15.213.99
سطر NS هو كل ما تحتاجه لتوجيه الاستعلامات الخاصة بالنطاق الفرعي t1
إلى خادم t1ns. نستخدم اسمًا قصيرًا للنطاق الفرعي، للحفاظ على أكبر قدر ممكن
من المساحة المتاحة لحركة البيانات. في نهاية سطر NS
يوجد اسم خادم iodined الخاص بك. يمكن أن يكون هذا أي اسم، يشير إلى أي مكان،
لكن في هذه الحالة يُحفظ بسهولة في ملف المنطقة نفسه. يجب أن يكون اسمًا
(وليس عنوان IP)، ويجب أن يكون لذلك الاسم نفسه سجل A
(وليس CNAME).
إذا كان خادم iodined الخاص بك لديه IP ديناميكي، فاستخدم مزوّد DNS ديناميكي. ببساطة
وجّه سطر NS إليه، واحذف سطر A:
t1 IN NS myname.mydyndnsprovider.com. ; note the dot!
ثم أعد تحميل أو أعد تشغيل برنامج خادم الأسماء الخاص بك. الآن أي استعلامات DNS
للنطاقات المنتهية بـ t1.mydomain.com ستُرسل إلى خادم iodined الخاص بك.
أخيرًا شغّل iodined على خادمك. الوسيطة الأولى هي عنوان IP
داخل النفق، والذي يمكن أن يكون من أي نطاق لا تستخدمه بعد (على
سبيل المثال 192.168.99.1)، والوسيطة الثانية هي النطاق المُخصَّص (في هذه
الحالة t1.mydomain.com). استخدام خيار -f سيبقي iodined يعمل في
المقدمة (foreground)، وهو ما يساعد عند الاختبار. سيفتح iodined واجهة افتراضية
("tun device")، وسيبدأ أيضًا في الاستماع لطلبات DNS على منفذ UDP رقم 53.
إما أن تدخل كلمة مرور على سطر الأوامر (-P pass) أو بعد أن يكون الخادم قد
بدأ. الآن كل شيء جاهز للعميل.
إذا كانت هناك احتمالية لاستخدامك نفق iodine من بيئات غير متوقعة،
فشغّل iodined مع خيار -c.
سطر الأوامر الناتج في حالة المثال هذه:
./iodined -f -c -P secretpassword 192.168.99.1 t1.mydomain.com
كل الإعداد قد اكتمل، فقط شغّل iodine. يأخذ وسيطة واحدة أو اثنتين،
الأولى هي خادم DNS المحلي المُمرِّر (اختياري) والثانية هي النطاق
الذي استخدمته (t1.mydomain.com). إذا لم تحدد الوسيطة الأولى،
فسيتم الرجوع إلى إعداد DNS الحالي للنظام.
إذا كان يُسمح باستعلامات DNS لأي حاسوب، يمكنك مباشرةً إعطاء عنوان خادم iodined
كوسيط أول (في المثال: t1ns.mydomain.com أو
10.15.213.99). في هذه الحالة، قد يحدث أيضًا أن يُسمح بـ_أي_ حركة مرور
إلى منفذ DNS (53 UDP) لأي حاسوب. سيكتشف Iodine ذلك، وسيتحول
إلى نفق UDP خام إن أمكن. لفرض نفق DNS في جميع الحالات، استخدم
الخيار -r (مفيد بشكل خاص عند الاختبار داخل شبكتك الخاصة).
ستحصل واجهة النفق الخاصة بالعميل على عنوان IP قريب من عنوان الخادم (في هذه
الحالة 192.168.99.2 أو .3 إلخ) و MTU مناسب. أدخل نفس كلمة المرور كما
على الخادم إما كخيار سطر أوامر أو بعد أن يبدأ العميل.
سيؤدي استخدام الخيار -f إلى إبقاء عميل iodine قيد التشغيل في المقدمة.
سطر الأوامر الناتج في هذه الحالة المثالية، وإضافة -r تفرض نفق DNS حتى لو كان نفق UDP الخام ممكنًا:
./iodine -f -P secretpassword t1.mydomain.com
من أي من الجانبين، يجب أن تكون الآن قادرًا على عمل ping لعنوان IP على الطرف
الآخر من النفق. في هذه الحالة، ping 192.168.99.1 من عميل iodine، و
192.168.99.2 من خادم iodine.
البيانات داخل النفق هي IPv4 فقط.
يستمع الخادم إلى كل من IPv4 و IPv6 للطلبات الواردة افتراضيًا.
استخدم الخيارين -4 أو -6 للاستماع على بروتوكول واحد فقط. ستُجرَّب الوضعية الخام
على نفس البروتوكول المستخدم لتسجيل الدخول.
يمكن للعميل استخدام خوادم أسماء IPv4 أو IPv6 للاتصال بـ iodined. ستترجم
خوادم الأسماء المرحّلة بين البروتوكولات تلقائيًا إذا لزم الأمر. استخدم
الخيارين -4 أو -6 لإجبار العميل على استخدام إصدار IP محدد لاستعلامات
DNS الخاصة به.
إذا كان خادمك يستمع على IPv6 وكان يمكن الوصول إليه، فأضف سجل AAAA له في إعداد DNS الخاص بك. توسيع المثال أعلاه سيبدو هكذا:
t1 IN NS t1ns.mydomain.com. ; note the dot!
t1ns IN A 10.15.213.99
t1ns IN AAAA 2001:db8::1001:99
من الممكن توجيه كل حركة المرور عبر نفق DNS. للقيام بذلك، أضف أولًا مسار مضيف إلى خادم الأسماء المستخدم بواسطة iodine عبر واجهة السلكية/اللاسلكية مع البوابة الافتراضية كبوابة. ثم استبدل البوابة الافتراضية بعنوان IP لخادم iodined داخل نفق DNS، وقم بتكوين الخادم للقيام بـ NAT.
ومع ذلك، لاحظ أن حركة المرور البياناتية المنقولة عبر النفق غير مشفرة على الإطلاق، ويمكن قراءتها وتغييرها من قبل أطراف خارجية بسهولة نسبيًا. لأقصى درجة من الأمان، شغّل VPN عبر نفق DNS (=نفق مزدوج)، أو استخدم وصول secure shell (SSH)، ربما مع إعادة توجيه المنافذ. يمكن استخدام الأخير أيضًا لتصفح الويب، عندما تشغّل وكيل ويب (مثل Privoxy) على خادمك.
يرد خادم iodined على طلبات NS المرسلة للنطاقات الفرعية لنطاق النفق.
إذا كان نطاقك الفرعي iodined هو t1.mydomain.com، فأرسل طلب NS لـ
foo123.t1.mydomain.com لمعرفة ما إذا كان التفويض يعمل.
dig أداة جيدة لهذا:
% dig -t NS foo123.t1.mydomain.com
ns.io.citronna.de.
أيضًا، سيجيب خادم iodined على الطلبات التي تبدأ بـ 'z' لأي من أنواع الطلبات المدعومة، على سبيل المثال:
dig -t TXT z456.t1.mydomain.com
dig -t SRV z456.t1.mydomain.com
dig -t CNAME z456.t1.mydomain.com
يجب أن تبدو الردود كنص مشوّه في كل هذه الحالات.
على macOS 10.6 وما بعده، يدعم iodine أجهزة utun الأصلية المدمجة في
نظام التشغيل - استخدم -d utunX.
عادةً ما يُفحص حجم جزء استجابة DNS تلقائيًا للحصول على أقصى عرض نطاق.
لفرض قيمة محددة (وتسريع الأمور)، استخدم الخيار -m.
عادةً ما تُستخدم أسماء مضيفي DNS حتى طولها الأقصى، 255 حرفًا.
وقد وُجدت بعض مرحّلات DNS التي تستجيب للاستعلامات كاملة الطول بشكل
غير موثوق، مما يعطي نتائج متباينة بشكل واسع (وسيئة للغاية في الغالب) لفحص
حجم القطع التلقائي عند المحاولات المتكررة. في هذه الحالات، استخدم مفتاح -M
لتقليل طول اسم مضيف DNS إلى، على سبيل المثال، 200 حرف، مما يجعل
مرحّلات DNS هذه أكثر استقرارًا بكثير. هذا مفيد أيضًا مع بعض مرحّلات DNS
«المُزيلة للتحسين» التي تحشو الاستجابة بنسختين كاملتين من الاستعلام، تاركةً
مساحة صغيرة جدًا للبيانات المتدفقة لأسفل (وهي أيضًا غير قادرة على EDNS0). يمكن
لمفتاح -M أن يقايض بعض عرض النطاق الترددي المتدفق لأعلى مقابل عرض النطاق الترددي المتدفق لأسفل. لاحظ أن
الحد الأدنى لقيمة -M هو حوالي 100، لأن البروتوكول يمكنه تقسيم الحزم (بحد أقصى 1200
بايت) إلى 16 قطعة فقط، مما يتطلب 75 بايتًا على الأقل من البيانات الحقيقية لكل
قطعة.