iodine

هذه أداة برمجية تتيح لك تمرير بيانات IPv4 عبر خادم DNS. ويمكن أن تكون مفيدة في حالات مختلفة يكون فيها الوصول إلى الإنترنت مقيدًا بجدار ناري، بينما تُسمح استعلامات DNS.

التجميع

لا يحتوي iodine على سكربت configure. توجد ميزتان اختياريتان لنظام Linux (دعم SELinux وsystemd) سيتم تفعيلهما تلقائيًا إذا وُجدت ملفات الرأس ذات الصلة في /usr/include. (انظر السكربت في ./src/osflags)

شغّل make لتجميع ثنائيات الخادم والعميل. شغّل make install لنسخ الثنائيات وصفحة الدليل (manpage) إلى دليل الوجهة. شغّل make test لتجميع اختبارات الوحدة وتشغيلها. (يتطلب مكتبة check)

بدء سريع

جرّبه داخل شبكتك المحلية 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.
جرّب اختبار الاتصال (ping) بين الطرفين عبر النفق.
انتهيت! :)

لاستخدامه فعليًا عبر خادم أسماء وسيط (relaying nameserver)، انظر أدناه.

طريقة الاستخدام

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

جانب الخادم

لاستخدام هذا النفق، تحتاج إلى التحكم في نطاق حقيقي (مثل mydomain.com)، وخادم بعنوان IP عام لتشغيل iodined عليه. إذا كان هذا الخادم يشغّل بالفعل برنامج DNS، فغيّر منفذ الاستماع الخاص به ثم استخدم خيار -b الخاص بـ iodined للسماح لـ iodined بإعادة توجيه استعلامات DNS. (لاحظ أن هذا الإجراء غير مستحسن في بيئات الإنتاج، لأن إعادة توجيه DNS الخاصة بـ iodined ليست شفافة تمامًا، فعلى سبيل المثال لن يعمل نقل النطاقات (zone transfers).) بدلاً من ذلك، يمكنك إعادة توجيه النطاق الفرعي من خادم DNS الخاص بك إلى iodined الذي يجب أن يعمل عندها على منفذ مختلف (-p).

ثم فوّض نطاقًا فرعيًا (مثل t1.mydomain.com) إلى خادم iodined. إذا كنت تستخدم BIND لنطاقك، أضف سطرين مثل هذين إلى ملف المنطقة (zone file):

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")، وسيبدأ أيضًا في الاستماع لاستعلامات 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 (UDP 53) لأي جهاز كمبيوتر. سيكتشف 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.

معلومات متنوعة

IPv6

البيانات داخل النفق هي IPv4 فقط.

يستمع الخادم إلى كل من IPv4 وIPv6 للطلبات الواردة افتراضيًا. استخدم الخيارين -4 أو -6 للاستماع على بروتوكول واحد فقط. سيتم محاولة استخدام الوضع الخام (raw mode) على نفس البروتوكول المستخدم لتسجيل الدخول.

يمكن للعميل استخدام خوادم أسماء 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. للقيام بذلك، أضف أولاً مسار مضيف (host route) إلى خادم الأسماء المستخدم من قبل iodine عبر الواجهة السلكية/اللاسلكية مع البوابة الافتراضية (default gateway) كبوابة. ثم استبدل البوابة الافتراضية بعنوان IP لخادم iodined داخل نفق DNS، وقم بتكوين الخادم للقيام بـ NAT.

ومع ذلك، لاحظ أن حركة البيانات عبر النفق غير مشفرة إطلاقًا، ويمكن قراءتها وتغييرها من قبل أطراف خارجية بسهولة نسبية. لتحقيق أقصى درجات الأمان، شغّل VPN عبر نفق DNS (= نفق مزدوج)، أو استخدم وصول shell الآمن (SSH)، ربما مع إعادة توجيه المنافذ (port forwarding). يمكن أيضًا استخدام الأخير لتصفح الويب، عندما تشغّل وكيل ويب (مثل 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

يجب أن يبدو الرد كنص مشوّه في كل هذه الحالات.

Mac OS X

على نظام Mac OS X 10.6 والإصدارات الأحدث، يدعم iodine أجهزة utun الأصلية المدمجة في نظام التشغيل - استخدم -d utunX.

معلومات تشغيلية

عادةً ما يتم اكتشاف حجم جزء استجابة DNS (fragment size) تلقائيًا للحصول على أقصى عرض نطاق ترددي. لإجبار قيمة محددة (وتسريع الأمور)، استخدم الخيار -m.

عادةً ما تُستخدم أسماء نطاقات DNS حتى أقصى طول لها، وهو 255 حرفًا. وُجد أن بعض خوادم DNS الوسيطة تجيب على الاستعلامات كاملة الطول بشكل غير موثوق إلى حد ما، معطيةً نتائج متباينة بشدة (وسيئة في الغالب) للاكتشاف التلقائي لحجم الجزء عند المحاولات المتكررة. في هذه الحالات، استخدم المفتاح -M لتقليل طول اسم نطاق DNS إلى 200 حرفًا على سبيل المثال، مما يجعل خوادم DNS الوسيطة هذه أكثر استقرارًا بكثير. هذا مفيد أيضًا مع بعض خوادم DNS الوسيطة "المعطِّلة للأداء" التي تحشر الاستجابة بنسختين كاملتين من الاستعلام، تاركةً مساحة صغيرة جدًا لبيانات الاتجاه الهابط (downstream) (وهي أيضًا غير قادرة على EDNS0). يمكن لمفتاح -M مقايضة بعض عرض النطاق الترددي للاتجاه الصاعد (upstream) بعرض نطاق للاتجاه الهابط. لاحظ أن القيمة الدنيا لـ -M هي حوالي 100، لأن البروتوكول يمكنه تقسيم الحزم (بحد أقصى 1200 بايت) إلى 16 جزءًا فقط، مما يتطلب ما لا يقل عن 75 بايتًا من البيانات الحقيقية لكل جزء.

تُرسل بيانات الاتجاه الصاعد مضغوطة بـ gzip ومشفرة بـ Base32؛ أو Base64 إذا كان الخادم الوسيط يدعم الأحرف المختلطة (mixed case) و+ في أسماء النطاقات؛ أو Base64u إذا كان _ مدعومًا بدلاً من ذلك؛ أو Base128 إذا كانت الأحرف ذات القيم البايتية العالية مدعومة. يتم اكتشاف ترميز الاتجاه الصاعد تلقائيًا. يسمح بروتوكول DNS باستعلام واحد لكل حزمة، ويمكن أن يصل طول الاستعلام الواحد إلى 256 حرفًا كحد أقصى. يمكن أن يصل طول كل جزء من اسم النطاق إلى 63 حرفًا كحد أقصى. لذا يجب أن يكون اسم نطاقك ونطاقك الفرعي قصيرين قدر الإمكان للسماح بأقصى إنتاجية للاتجاه الصاعد.

يتم دعم عدة أنواع من طلبات DNS، مع توقع أن يوفر النوعان NULL وPRIVATE أكبر عرض نطاق ترددي للاتجاه الهابط. يستخدم النوع PRIVATE القيمة 65399 في نطاق الاستخدام الخاص (private-use range). الأنواع الأخرى المتاحة هي TXT، SRV، MX، CNAME وA (يعيد CNAME)، بترتيب تنازلي لعرض النطاق الترددي. عادةً ما يتم اكتشاف "أفضل" نوع طلب واستخدامه تلقائيًا. ومع ذلك، قد تفرض خوادم DNS الوسيطة قيودًا على NULL وTXT على سبيل المثال، مما يجعل SRV أو MX الخيار الأفضل فعليًا. هذا لا يتم اكتشافه تلقائيًا، ولكن يمكن فرضه باستخدام الخيار -T. يُنصح بتجربة بدائل مختلفة خاصةً عندما يوفر نوع الطلب المكتشف تلقائيًا حجم جزء هابط أقل من 200 بايت.

لاحظ أن استعلامات SRV وMX وA (التي تعيد CNAME) قد/ستؤدي إلى عمليات بحث إضافية من قبل خوادم الأسماء "الذكية" المخزنة مؤقتًا (caching nameservers) للحصول على عنوان IP فعلي، مما قد يؤدي إلى التباطؤ أو الفشل التام.

يمكن ترميز استجابات DNS للاستعلامات غير NULL/PRIVATE بنفس مجموعة برامج الترميز (codecs) المستخدمة لبيانات الاتجاه الصاعد. عادةً ما يتم اكتشاف ذلك تلقائيًا أيضًا، لكن لا تُجرى اختبارات شاملة بالكامل، لذلك قد لا تُلاحظ بعض المشكلات عند اختيار برامج ترميز أكثر تقدمًا. في هذه الحالة، سترى حالات فشل/تلف في الاكتشاف التلقائي لحجم الجزء. على وجه الخصوص، وُجد أن العديد من خوادم DNS الوسيطة تحوّل الردود التي تعيد أسماء المضيفين (SRV، MX، CNAME، A) إلى أحرف صغيرة (lowercase) فقط عندما يتجاوز اسم المضيف حوالي 180 حرفًا. في هذه الحالات والحالات المماثلة، استخدم الخيار -O لتجربة برامج ترميز أخرى للاتجاه الهابط؛ يجب أن يعمل Base32 دائمًا.

الوضع الطبيعي الآن هو أن الخادم لا يجيب على طلب DNS حتى يصل طلب DNS التالي، أي أن يكون "كسولًا" (lazy). بهذه الطريقة، سيكون لدى الخادم دائمًا طلب DNS جاهز عندما يتعين إرسال بيانات هابطة جديدة. يعمل هذا على تحسين الأداء (التفاعلي) وزمن الاستجابة (latency) بشكل كبير، ويسمح بإبطاء طلبات ping الخاملة (quiescent) إلى فترات 4 ثوانٍ افتراضيًا، وربما أبطأ بكثير. في الواقع، أصبح الغرض الرئيسي من طلبات ping الآن هو إجبار الرد على ping السابقة، ومنع انتهاء مهلة خادم DNS (عادةً ما لا يقل عن 5-10 ثوانٍ وفقًا لـ RFC1035). بعض خوادم DNS أكثر نفاد صبر وستعطي أخطاء SERVFAIL (انتهاء المهلة) في الفترات التي لا توجد فيها حركة بيانات عبر النفق. يجب أن تصل جميع البيانات في هذه الحالات على أي حال، لكن iodine سيقلل فترة ping إلى ثانية واحدة على أي حال (-I1) لتقليل عدد رسائل الخطأ. قد لا يساعد هذا مع خوادم DNS الوسيطة شديدة نفاد الصبر مثل dnsadvantage.com (ultradns)، التي تنتهي مهلتها في ثانية واحدة أو أقل. ومع ذلك ستظل البيانات تصل، ويمكنك تجاهل أخطاء SERVFAIL.

إذا كنت تعمل على شبكة محلية دون أي خادم DNS في المنتصف، جرّب -I 50 (يغلق iodine وiodined الاتصال بعد 60 ثانية من الصمت). المرة الوحيدة التي ستلاحظ فيها التباطؤ هي عندما تضيع حزم ردود DNS؛ عندها يضطر خادم iodined إلى انتظار ping جديد لإعادة إرسال البيانات. يمكنك تسريع ذلك بتوليد بعض حركة المرور في الاتجاه الصاعد (ضغطة مفتاح، ping). إذا حدث ذلك كثيرًا، افحص شبكتك بحثًا عن الاختناقات و/أو شغّل مع -I1.

سيتسبب التأخير في الإجابة في الوضع الكسول في قيام بعض خوادم DNS الوسيطة التجارية "بمستوى الناقل" (carrier grade) بإعادة إرسال نفس استعلام DNS إلى خادم iodined بشكل متكرر. إذا كان خادم DNS الوسيط مُنفَّذًا فعليًا كمجموعة من الخوادم المتوازية، فقد تصل الطلبات المكررة حتى من مصادر متعددة. سيكون هذا التأثير مرئيًا فقط في حركة مرور الشبكة عند خادم iodined، ولن يؤثر على اتصال العميل. سيلاحظ Iodined هذه التكرارات، وسيرسل نفس الإجابة (عندما يحين وقتها) إلى كل من الاستعلام الأصلي وأحدث تكرار. بعد ذلك، يتم تخزين الإجابة الكاملة مؤقتًا لفترة قصيرة. أما التكرارات المتأخرة التي تصل إلى الخادم حتى في وقت لاحق، فتحصل على رد سيتجاهله عميل iodine (إذا وصل إليه على الإطلاق).

إذا واجهت مشكلات، فحاول فحص حركة المرور بأدوات مراقبة الشبكة مثل tcpdump أو ethereal/wireshark، وتأكد من أن خادم DNS الوسيط لم يخزن الاستجابة في ذاكرة التخزين المؤقت (cache). قد تعني رسالة الخطأ المخزنة مؤقتًا أنك بدأت تشغيل العميل قبل الخادم. يمكن لخيار -D (و-DD) على الخادم أيضًا إظهار الاستعلامات المستلمة والمرسلة.

نصائح وحيل

إذا كان المنفذ 53 مشغولاً على واجهة معينة بواسطة تطبيق لا يستخدمه، فاستخدم -p على iodined لتحديد منفذ بديل (مثل -p 5353) واستخدم على سبيل المثال iptables (على Linux) لإعادة توجيه حركة المرور:

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to :5353

(أرسلها Tom Schouten)

سيرفض Iodined البيانات من العملاء الذين لم يكونوا نشطين (بيانات/pings) لأكثر من 60 ثانية. وبالمثل، سيخرج iodine عندما لا يتم استلام أي بيانات هابطة لمدة 60 ثانية. في حالة انقطاع طويل للشبكة أو ما شابه ذلك، ما عليك سوى إعادة تشغيل iodine (إعادة تسجيل الدخول)، ربما عدة مرات حتى تستعيد عنوان IP القديم الخاص بك. بمجرد أن يتم ذلك، انتظر قليلاً، وسترى في النهاية حركة مرور TCP عبر النفق تستأنف التدفق من حيث توقفت قبل الانقطاع.

مع إدخال قائمة انتظار الحزم الهابطة (downstream packet queue) في الخادم، زاد استخدامه للذاكرة بعدة ميغابايتات في التكوين الافتراضي. للاستخدام في البيئات منخفضة الذاكرة (مثل التشغيل على راوتر DSL الخاص بك)، يمكنك تقليل USERS وإلغاء تعريف OUTPACKETQ_LEN في user.h دون أي عواقب سيئة، بافتراض أن عميلًا واحدًا على الأكثر سيكون متصلاً في أي وقت. لا يزال يُنصح بقيمة DNSCACHE_LEN صغيرة، ويفضل 2 أو أكثر، ومع ذلك يمكنك أيضًا إلغاء تعريفها لتوفير بضعة كيلوبايتات إضافية.

يمكن لخادم iodine واحد التعامل مع نطاقات متعددة. قم بإعداد سجلات NS مختلفة على نفس النطاق تشير جميعها إلى نفس المضيف، واستخدم حرف بدل (wildcard) في بداية وسيطة النطاق الأعلى (مثال *.mydomain.com). سيقبل iodine حركة مرور النفق لجميع النطاقات المطابقة لهذا النمط. يجب أن يكون حرف البدل في بداية وسيطة النطاق الأعلى متبوعًا بنقطة.

الأداء

يعرض هذا القسم بعض قياسات الأداء في شكل جدول. للعرض بشكل صحيح، استخدم خطًا ثابت العرض مثل Courier.

أُجريت القياسات في البروتوكول 00000502 في الوضع الكسول؛ ترميز الاتجاه الصاعد دائمًا Base128؛ iodine -M255؛ iodined -m1130. لم تكن ظروف الشبكة مواتية للغاية؛ النتائج ليست مقاييس مرجعية (benchmarks) وإنما مؤشر واقعي للأداء الفعلي الذي يمكن توقعه في مواقف مماثلة.

تم قياس إنتاجية الاتجاه الصاعد/الهابط باستخدام scp لنقل ملف تمت قراءته مسبقًا من /dev/urandom (أي غير قابل للضغط)، وقياس الحجم باستخدام ls -l ; sleep 30 ; ls -l على اتصال منفصل غير معبَّر عبر النفق (non-tunneled). نظرًا لحجم كتلة scp الكبير البالغ 16 كيلوبايت، يعطي هذا دقة قدرها 4.3 كيلوبت/ثانية، وهو ما يفسر سبب تساوي بعض القيم تمامًا. تم قياس أوقات الرحلة ذهابًا وإيابًا (round-trip) لـ ping باستخدام ping -c100، والمعروض هو متوسط rtt ومتوسط الانحراف (الذي يشير إلى التشتت حول المتوسط)، بالمللي ثانية.

السيناريو 1: `Laptop -> Wifi AP -> Home server -> DSL provider -> Datacenter`

 iodine    DNS "relay"        bind9           DNS cache        iodined

                        downstr.  upstream downstr.  ping-up       ping-down
                        fragsize   kbit/s   kbit/s  avg +/-mdev   avg +/-mdev
-----------------------------------------------------------------------------

iodine -> Wifi AP :53
  -Tnull (= -Oraw)           982    43.6    131.0   28.0    4.6   26.8    3.4

iodine -> Home server :53
  -Tnull (= -Oraw)          1174    48.0    305.8   26.6    5.0   26.9    8.4

iodine -> DSL provider :53
  -Tnull (= -Oraw)          1174    56.7    367.0   20.6    3.1   21.2    4.4
  -Ttxt -Obase32             730    56.7    174.7*
  -Ttxt -Obase64             874    56.7    174.7
  -Ttxt -Obase128           1018    56.7    174.7
  -Ttxt -Oraw               1162    56.7    358.2
  -Tsrv -Obase128            910    56.7    174.7
  -Tcname -Obase32           151    56.7     43.6
  -Tcname -Obase128          212    56.7     52.4

iodine -> DSL provider :53
  wired (no Wifi) -Tnull    1174    74.2    585.4   20.2    5.6   19.6    3.4

 [174.7* : these all have 2frag/packet]

السيناريو 2: `Laptop -> Wifi+vpn / wired -> Home server`

 iodine                            iodined

                        downstr.  upstream downstr.  ping-up       ping-down
                        fragsize   kbit/s   kbit/s  avg +/-mdev   avg +/-mdev
-----------------------------------------------------------------------------

wifi + openvpn  -Tnull      1186   166.0   1022.3    6.3    1.3    6.6    1.6

wired  -Tnull               1186   677.2   2464.1    1.3    0.2    1.3    0.1

ملاحظات

يرتبط الأداء ارتباطًا وثيقًا بأوقات ping المنخفضة، حيث يتطلب iodine تأكيدًا لكل جزء من البيانات قبل الانتقال إلى الجزء التالي. قد يؤدي السماح بأجزاء متعددة قيد التنفيذ (in-flight) مثل TCP إلى زيادة الأداء، لكنه قد يتسبب على الأرجح في حمل زائد خطير على خوادم DNS الوسيطة. يعمل البروتوكول الحالي على توسيع نطاق الأداء مع استجابة DNS، نظرًا لأن خوادم DNS تتعامل في المتوسط مع طلب DNS واحد على الأكثر لكل عميل.

قابلية النقل

تم اختبار iodine على Linux (arm، ia64، x86، AMD64 وSPARC64)، وFreeBSD (ia64، x86)، وOpenBSD (x86)، وNetBSD (x86)، وMacOS X (ppc وx86، مع http://tuntaposx.sourceforge.net/)، وWindows (مع برنامج تشغيل OpenVPN TAP32، انظر ملف readme الخاص بـ win32). يجب أن يكون من السهل نقله إلى أنظمة أخرى شبيهة بـ Unix تدعم TUN/TAP tunneling. أخبرنا إذا نجحت في تشغيله على منصات أخرى.

الاسم

اختير اسم iodine لأنه يبدأ بـ IOD (IP Over DNS) ولأن العدد الذري لليود (iodine) هو 53، وهو مصادفةً رقم منفذ DNS.

شكر وتقدير

إلى kuxien لاختبار FreeBSD وOS X
إلى poplix لمراجعة الكود

المؤلفون والترخيص

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

يُقدَّم هذا البرنامج "كما هو" (AS IS) ويتنصل المؤلف من جميع الضمانات المتعلقة بهذا البرنامج بما في ذلك جميع الضمانات الضمنية الخاصة بالصلاحية للتسويق (MERCHANTABILITY) والملاءمة لغرض معين (FITNESS). لا يكون المؤلف مسؤولاً بأي حال من الأحوال عن أي أضرار خاصة أو مباشرة أو غير مباشرة أو تبعية، أو أي أضرار مهما كانت ناتجة عن فقدان الاستخدام أو البيانات أو الأرباح، سواء في دعوى تعاقدية أو إهمال أو أي إجراء آخر، تنشأ عن أو تتعلق باستخدام هذا البرنامج أو أدائه.

iodine

الأكثر شعبية