yarrick/iodineDNS सर्वरों के माध्यम से IPv4 डेटा को टनल करके फ़ायरवॉल प्रतिबंधों को बायपास करें और पेनेट्रेशन टेस्टिंग हेतु गुप्त नेटवर्क एक्सेस प्रदान करें।
यह एक सॉफ़्टवेयर है जो आपको DNS सर्वर के माध्यम से IPv4 डेटा को टनल करने देता है। यह उन विभिन्न स्थितियों में उपयोगी हो सकता है जहाँ इंटरनेट एक्सेस फ़ायरवॉल किया गया है, लेकिन DNS क्वेरी की अनुमति है।
Iodine में कोई configure स्क्रिप्ट नहीं है। Linux के लिए दो वैकल्पिक सुविधाएँ
हैं (SELinux और systemd समर्थन) जो स्वचालित रूप से सक्षम होंगी यदि प्रासंगिक
हेडर फ़ाइलें /usr/include में मिलती हैं।
(./src/osflags पर स्क्रिप्ट देखें)
सर्वर और क्लाइंट बाइनरी को संकलित करने के लिए make चलाएँ।
बाइनरी और मैनपेज को गंतव्य निर्देशिका में कॉपी करने के लिए make install चलाएँ।
यूनिट परीक्षणों को संकलित और चलाने के लिए 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 है।वास्तव में इसे रिले करने वाले नेमसर्वर के माध्यम से उपयोग करने के लिए, नीचे देखें।
नोट: सर्वर और क्लाइंट के लिए बिल्कुल समान प्रोटोकॉल का उपयोग करना आवश्यक है। अधिकांश मामलों में, इसका अर्थ है समान iodine संस्करण चलाना। दुर्भाग्य से, पश्चगामी और अग्रगामी प्रोटोकॉल संगतता लागू करना आमतौर पर संभव नहीं है।
इस टनल का उपयोग करने के लिए, आपको एक वास्तविक डोमेन (जैसे mydomain.com) पर नियंत्रण
चाहिए, और iodined चलाने के लिए सार्वजनिक IP पते वाला एक सर्वर चाहिए। यदि यह सर्वर
पहले से DNS प्रोग्राम चलाता है, तो उसका listening पोर्ट बदलें और फिर iodined को
DNS अनुरोधों को आगे भेजने देने के लिए iodined के -b विकल्प का उपयोग करें। (ध्यान दें कि
production वातावरण में यह प्रक्रिया अनुशंसित नहीं है, क्योंकि iodined का DNS फ़ॉरवर्डिंग
पूरी तरह से पारदर्शी नहीं है, उदाहरण के लिए zone transfers काम नहीं करेंगे।)
वैकल्पिक रूप से आप अपने DNS सर्वर से सबडोमेन को iodined पर फ़ॉरवर्ड कर सकते हैं,
जिसे तब एक अलग पोर्ट (-p) पर चलना चाहिए।
फिर, एक सबडोमेन (मान लीजिए, t1.mydomain.com) को iodined सर्वर को सौंपें।
यदि आप अपने डोमेन के लिए BIND का उपयोग करते हैं, तो zone फ़ाइल में इस प्रकार की दो पंक्तियाँ जोड़ें:
t1 IN NS t1ns.mydomain.com. ; note the dot!
t1ns IN A 10.15.213.99
t1 सबडोमेन के लिए क्वेरी को t1ns सर्वर पर रूट करने के लिए केवल NS पंक्ति की
आवश्यकता है। हम सबडोमेन के लिए एक छोटा नाम उपयोग करते हैं, ताकि डेटा ट्रैफ़िक के लिए
अधिक से अधिक स्थान उपलब्ध रहे। NS पंक्ति के अंत में आपके iodined सर्वर का नाम
होता है। यह कोई भी नाम हो सकता है, कहीं भी इंगित करता हुआ, लेकिन इस मामले में इसे
आसानी से उसी zone फ़ाइल में रखा जा सकता है। यह एक नाम होना चाहिए (IP पता नहीं),
और उस नाम में स्वयं एक A रिकॉर्ड होना चाहिए (CNAME नहीं)।
यदि आपके iodined सर्वर के पास dynamic IP है, तो dynamic DNS प्रदाता का उपयोग करें।
बस NS पंक्ति को उसकी ओर इंगित करें, और A पंक्ति को छोड़ दें:
t1 IN NS myname.mydyndnsprovider.com. ; note the dot!
फिर अपने नेमसर्वर प्रोग्राम को reload या restart करें। अब t1.mydomain.com पर
समाप्त होने वाले डोमेन के लिए कोई भी DNS क्वेरी आपके iodined सर्वर को भेजी जाएगी।
अंत में अपने सर्वर पर iodined प्रारंभ करें। पहला तर्क टनल के अंदर का IP पता है,
जो किसी भी ऐसी रेंज से हो सकता है जिसका आप अभी उपयोग नहीं करते हैं (उदाहरण के लिए
192.168.99.1), और दूसरा तर्क निर्धारित डोमेन है (इस मामले में t1.mydomain.com)।
-f विकल्प का उपयोग करने से iodined फ़ोरग्राउंड में चलता रहेगा, जो परीक्षण करते समय
सहायक होता है। iodined एक वर्चुअल इंटरफ़ेस ("tun device") खोलेगा, और UDP पोर्ट 53 पर
DNS क्वेरी के लिए सुनना भी शुरू कर देगा। या तो कमांडलाइन पर पासवर्ड दर्ज करें
(-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 इसे पहचान लेगा, और संभव होने पर raw UDP
टनलिंग पर स्विच कर देगा। किसी भी स्थिति में DNS टनलिंग को बाध्य करने के लिए,
-r विकल्प का उपयोग करें (विशेष रूप से अपने स्वयं के नेटवर्क में परीक्षण करते समय उपयोगी)।
क्लाइंट का टनल इंटरफ़ेस सर्वर के IP के करीब एक IP प्राप्त करेगा (इस मामले में
192.168.99.2 या .3 आदि) और एक उपयुक्त MTU। सर्वर वाला वही पासवर्ड या तो
कमांडलाइन विकल्प के रूप में या क्लाइंट प्रारंभ होने के बाद दर्ज करें। -f विकल्प
का उपयोग करने से iodine क्लाइंट फ़ोरग्राउंड में चलता रहेगा।
इस उदाहरण स्थिति में परिणामी कमांडलाइन, -r जोड़ने पर DNS टनलिंग बाध्य होती है भले ही raw UDP टनलिंग संभव हो:
./iodine -f -P secretpassword t1.mydomain.com
अब आपको किसी भी ओर से टनल के दूसरे छोर पर IP पते को पिंग करने में सक्षम होना चाहिए।
इस मामले में, iodine क्लाइंट से ping 192.168.99.1, और iodine सर्वर से 192.168.99.2।
टनल के अंदर डेटा केवल IPv4 है।
सर्वर डिफ़ॉल्ट रूप से आने वाले अनुरोधों के लिए IPv4 और IPv6 दोनों पर सुनता है।
केवल एक प्रोटोकॉल पर सुनने के लिए -4 या -6 विकल्पों का उपयोग करें। Raw मोड
उसी प्रोटोकॉल पर प्रयास किया जाएगा जिसका उपयोग लॉगिन के लिए किया गया था।
क्लाइंट iodined से जुड़ने के लिए IPv4 या IPv6 नेमसर्वर का उपयोग कर सकता है। रिले
नेमसर्वर आवश्यकता पड़ने पर प्रोटोकॉल के बीच स्वचालित रूप से रूपांतरण करेंगे।
क्लाइंट को उसकी DNS क्वेरी के लिए एक विशिष्ट IP संस्करण का उपयोग करने के लिए बाध्य
करने हेतु -4 या -6 विकल्पों का उपयोग करें।
यदि आपका सर्वर IPv6 पर सुन रहा है और पहुँच योग्य है, तो अपनी DNS सेटिंग में उसके लिए एक AAAA रिकॉर्ड जोड़ें। उपरोक्त उदाहरण को बढ़ाने पर यह इस प्रकार दिखेगा:
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 द्वारा उपयोग किए जाने वाले नेमसर्वर के लिए एक host route जोड़ें। फिर डिफ़ॉल्ट गेटवे को DNS टनल के अंदर iodined सर्वर के IP पते से बदलें, और सर्वर को NAT करने के लिए कॉन्फ़िगर करें।
हालाँकि, ध्यान दें कि टनल किया गया डेटा ट्रैफ़िक बिल्कुल भी एन्क्रिप्टेड नहीं है, और इसे बाहरी पक्षों द्वारा अपेक्षाकृत आसानी से पढ़ा और बदला जा सकता है। अधिकतम सुरक्षा के लिए, DNS टनल के माध्यम से एक VPN चलाएँ (=डबल टनलिंग), या सिक्योर शेल (SSH) एक्सेस का उपयोग करें, संभवतः पोर्ट फ़ॉरवर्डिंग के साथ। बाद वाला वेब ब्राउज़िंग के लिए भी उपयोगी हो सकता है, जब आप अपने सर्वर पर एक वेब प्रॉक्सी (उदाहरण के लिए Privoxy) चलाते हैं।
iodined सर्वर टनल डोमेन के सबडोमेन के लिए भेजे गए NS अनुरोधों का उत्तर देता है।
यदि आपका iodined सबडोमेन t1.mydomain.com है, तो यह देखने के लिए कि delegation
काम करता है या नहीं, foo123.t1.mydomain.com के लिए एक NS अनुरोध भेजें।
इसके लिए 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
इन सभी मामलों में उत्तर अव्यवस्थित (garbled) पाठ जैसा दिखना चाहिए।
Mac OS X 10.6 और उसके बाद के संस्करणों पर, iodine OS में निर्मित नेटिव utun
डिवाइसों का समर्थन करता है - -d utunX का उपयोग करें।
DNS-प्रतिक्रिया फ्रैगमेंट आकार सामान्यतः अधिकतम बैंडविड्थ प्राप्त करने के लिए
स्वतः जाँचा (autoprobe) जाता है। किसी विशिष्ट मान को बाध्य करने (और चीज़ों को
तेज़ करने) के लिए, -m विकल्प का उपयोग करें।
DNS होस्टनाम सामान्यतः अपनी अधिकतम लंबाई, 255 वर्णों तक उपयोग किए जाते हैं।
कुछ DNS रिले ऐसे पाए गए हैं जो पूर्ण-लंबाई वाली क्वेरी का उत्तर काफी
अविश्वसनीय रूप से देते हैं, बार-बार प्रयास करने पर फ्रैगमेंट आकार autoprobe के
अत्यधिक भिन्न (और अधिकतर बहुत खराब) परिणाम देते हैं। इन मामलों में, DNS होस्टनाम
की लंबाई घटाकर, उदाहरण के लिए 200 वर्ण करने के लिए -M स्विच का उपयोग करें,
जिससे ये DNS रिले अधिक स्थिर हो जाते हैं। यह कुछ "de-optimizing" DNS रिले पर भी
उपयोगी है जो प्रतिक्रिया में क्वेरी की दो पूरी प्रतियाँ भर देते हैं, जिससे
डाउनस्ट्रीम डेटा के लिए बहुत कम स्थान बचता है (EDNS0 में भी सक्षम नहीं)। -M
स्विच कुछ अपस्ट्रीम बैंडविड्थ को डाउनस्ट्रीम बैंडविड्थ के लिए विनिमय कर सकता है।
ध्यान दें कि न्यूनतम -M मान लगभग 100 है, क्योंकि प्रोटोकॉल पैकेट (अधिकतम 1200
बाइट्स) को केवल 16 फ्रैगमेंट में विभाजित कर सकता है, जिसके लिए प्रति फ्रैगमेंट
कम से कम 75 वास्तविक डेटा बाइट्स की आवश्यकता होती है।
अपस्ट्रीम डेटा gzipped भेजा जाता है और Base32 के साथ एन्कोड किया जाता है; या Base64
यदि रिले सर्वर डोमेन नामों में मिश्रित केस और + का समर्थन करता है; या Base64u
यदि इसके बजाय _ समर्थित है; या Base128 यदि उच्च-बाइट-मान वर्ण समर्थित हैं।
यह अपस्ट्रीम एन्कोडिंग स्वतः पहचानी जाती है। DNS प्रोटोकॉल प्रति पैकेट एक क्वेरी
की अनुमति देता है, और एक क्वेरी अधिकतम 256 वर्णों की हो सकती है। प्रत्येक डोमेन
नाम भाग अधिकतम 63 वर्णों का हो सकता है। इसलिए अधिकतम अपस्ट्रीम थ्रूपुट की अनुमति
देने के लिए आपका डोमेन नाम और सबडोमेन जितना संभव हो उतना छोटा होना चाहिए।
कई DNS अनुरोध प्रकार समर्थित हैं, जिनमें NULL और PRIVATE प्रकारों से सबसे
अधिक डाउनस्ट्रीम बैंडविड्थ मिलने की उम्मीद है। PRIVATE प्रकार निजी-उपयोग सीमा
में मान 65399 का उपयोग करता है। अन्य उपलब्ध प्रकार हैं TXT, SRV, MX,
CNAME और A (CNAME लौटाता है), घटते बैंडविड्थ क्रम में। सामान्यतः
"सर्वोत्तम" अनुरोध प्रकार स्वतः पहचाना और उपयोग किया जाता है। हालाँकि, DNS रिले
उदाहरण के लिए NULL और TXT पर सीमाएँ लगा सकते हैं, जिससे SRV या MX वास्तव में
सबसे अच्छा विकल्प बन जाते हैं। यह स्वतः पहचाना नहीं जाता है, लेकिन -T विकल्प
का उपयोग करके बाध्य किया जा सकता है। विभिन्न विकल्पों को आज़माना उचित है,
विशेष रूप से जब स्वतः पहचाना गया अनुरोध प्रकार 200 बाइट्स से कम का डाउनस्ट्रीम
फ्रैगमेंट आकार प्रदान करता है।
ध्यान दें कि SRV, MX और A (CNAME लौटाने वाली) क्वेरी वास्तविक IP पता
प्राप्त करने के लिए "स्मार्ट" कैशिंग नेमसर्वर द्वारा अतिरिक्त लुकअप का कारण बन
सकती हैं/बनेंगी, जो या तो धीमा कर सकती हैं या पूरी तरह विफल हो सकती हैं।
गैर-NULL/PRIVATE क्वेरी के लिए DNS प्रतिक्रियाओं को अपस्ट्रीम डेटा के समान
कोडेक सेट के साथ एन्कोड किया जा सकता है। यह सामान्यतः भी स्वतः पहचाना जाता है,
लेकिन पूरी तरह से व्यापक परीक्षण नहीं किए जाते हैं, इसलिए अधिक उन्नत कोडेक चुनने
पर कुछ समस्याएँ ध्यान में नहीं आ सकती हैं। उस स्थिति में, आपको फ्रैगमेंट आकार
autoprobe में विफलताएँ/भ्रष्टाचार दिखाई देंगे। विशेष रूप से, कई DNS रिले ऐसे
पाए गए हैं जो होस्टनाम लौटाने वाले उत्तरों (SRV, MX, CNAME, A) को केवल
तब lowercase में बदलते हैं जब वह होस्टनाम लगभग 180 वर्णों से अधिक होता है। इन
और समान मामलों में, अन्य डाउनस्ट्रीम कोडेक आज़माने के लिए -O विकल्प का उपयोग
करें; Base32 को हमेशा काम करना चाहिए।
अब सामान्य संचालन यह है कि सर्वर अगला DNS अनुरोध आने तक DNS अनुरोध का उत्तर
नहीं देता, जिसे "lazy" (आलसी) होना कहा जाता है। इस तरह, जब नया डाउनस्ट्रीम
डेटा भेजना होता है तो सर्वर के पास हमेशा एक DNS अनुरोध तैयार रहता है। यह
(इंटरैक्टिव) प्रदर्शन और विलंबता में काफी सुधार करता है, और निष्क्रिय पिंग
अनुरोधों को डिफ़ॉल्ट रूप से 4 सेकंड के अंतराल तक धीमा करने की अनुमति देता है,
और संभवतः बहुत धीमा। वास्तव में, अब पिंग का मुख्य उद्देश्य पिछले पिंग का उत्तर
प्राप्त करना है, और DNS सर्वर टाइमआउट को रोकना है (आमतौर पर RFC1035 के अनुसार
कम से कम 5-10 सेकंड)। कुछ DNS सर्वर अधिक अधीर होते हैं और बिना टनल किए डेटा
ट्रैफ़िक की अवधि में SERVFAIL त्रुटियाँ (टाइमआउट) देंगे। इन मामलों में सभी डेटा
को अभी भी पार पहुँचना चाहिए, लेकिन iodine त्रुटि संदेशों की संख्या कम करने के
लिए वैसे भी पिंग अंतराल को 1 सेकंड (-I1) तक घटा देगा। यह dnsadvantage.com
(ultradns) जैसे बहुत अधीर DNS रिले के लिए मदद नहीं कर सकता है, जो 1 सेकंड या
उससे भी कम में टाइमआउट कर देते हैं। फिर भी डेटा पार पहुँच जाएगा, और आप SERVFAIL
त्रुटियों को अनदेखा कर सकते हैं।
यदि आप बीच में बिना किसी DNS सर्वर के स्थानीय नेटवर्क पर चल रहे हैं, तो -I 50
आज़माएँ (iodine और iodined 60 सेकंड की शांति के बाद कनेक्शन बंद कर देते हैं)।
एकमात्र समय जब आपको मंदी दिखेगी, वह तब है जब DNS उत्तर पैकेट गायब हो जाते हैं;
तब iodined सर्वर को डेटा फिर से भेजने के लिए एक नए पिंग की प्रतीक्षा करनी पड़ती
है। आप कुछ अपस्ट्रीम ट्रैफ़िक (कीप्रेस, पिंग) उत्पन्न करके इसे तेज़ कर सकते हैं।
यदि ऐसा अक्सर होता है, तो अपने नेटवर्क में बाधाओं की जाँच करें और/या -I1 के
साथ चलाएँ।
lazy मोड में विलंबित उत्तर देने से कुछ "carrier grade" वाणिज्यिक DNS रिले
iodined सर्वर को बार-बार वही DNS क्वेरी पुनः भेजेंगे। यदि DNS रिले वास्तव में
समानांतर सर्वरों के पूल के रूप में लागू किया गया है, तो डुप्लिकेट अनुरोध कई
स्रोतों से भी आ सकते हैं। यह प्रभाव केवल iodined सर्वर पर नेटवर्क ट्रैफ़िक में
दिखाई देगा, और क्लाइंट के कनेक्शन को प्रभावित नहीं करेगा। Iodined इन डुप्लिकेट्स
को नोटिस करेगा, और वही उत्तर (जब उसका समय आता है) मूल क्वेरी और नवीनतम डुप्लिकेट
दोनों को भेजेगा। उसके बाद, पूरा उत्तर थोड़ी देर के लिए कैश किया जाता है। विलंबित
डुप्लिकेट जो सर्वर पर और भी बाद में पहुँचते हैं, उन्हें एक उत्तर मिलता है जिसे
iodine क्लाइंट अनदेखा कर देगा (यदि वह कभी वहाँ पहुँचता है)।
यदि आपको समस्याएँ हैं, तो tcpdump या ethereal/wireshark जैसे नेटवर्क मॉनिटरिंग
टूल से ट्रैफ़िक का निरीक्षण करने का प्रयास करें, और सुनिश्चित करें कि रिले करने
वाले DNS सर्वर ने प्रतिक्रिया को कैश नहीं किया है। कैश की गई त्रुटि संदेश का अर्थ
हो सकता है कि आपने सर्वर से पहले क्लाइंट प्रारंभ किया था। सर्वर पर -D (और -DD)
विकल्प प्राप्त और भेजी गई क्वेरी भी दिखा सकता है।
यदि आपका पोर्ट 53 किसी विशिष्ट इंटरफ़ेस पर किसी ऐसे एप्लिकेशन द्वारा उपयोग किया
जा रहा है जो उसका उपयोग नहीं करता है, तो iodined पर -p का उपयोग करके एक वैकल्पिक
पोर्ट निर्दिष्ट करें (जैसे -p 5353) और ट्रैफ़िक को फ़ॉरवर्ड करने के लिए उदाहरण
के लिए iptables (Linux पर) का उपयोग करें:
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to :5353
(Tom Schouten द्वारा भेजा गया)
Iodined उन क्लाइंट्स से डेटा अस्वीकार कर देगा जो 60 सेकंड से अधिक समय से सक्रिय (डेटा/पिंग) नहीं हैं। इसी तरह, iodine तब बाहर निकल जाएगा जब 60 सेकंड तक कोई डाउनस्ट्रीम डेटा प्राप्त नहीं हुआ हो। लंबे नेटवर्क आउटेज या इसी तरह की स्थिति में, बस iodine को पुनः प्रारंभ करें (re-login), संभवतः कई बार जब तक आपको अपना पुराना IP पता वापस नहीं मिल जाता। एक बार ऐसा हो जाने पर, बस थोड़ी देर प्रतीक्षा करें, और आप अंततः टनल किए गए TCP ट्रैफ़िक को आउटेज से पहले जहाँ से रुका था वहीं से बहता हुआ देखेंगे।
सर्वर में डाउनस्ट्रीम पैकेट कतार की शुरुआत के साथ, इसकी मेमोरी उपयोग डिफ़ॉल्ट कॉन्फ़िगरेशन में कई मेगाबाइट बढ़ गया है। कम-मेमोरी वातावरण में उपयोग के लिए (जैसे अपने DSL राउटर पर चलाना), आप बिना किसी हानिकारक परिणाम के user.h में USERS घटा सकते हैं और OUTPACKETQ_LEN को undefine कर सकते हैं, यह मानते हुए कि किसी भी समय अधिकतम एक क्लाइंट जुड़ा होगा। एक छोटा DNSCACHE_LEN अभी भी सुझाया जाता है, अधिमानतः 2 या अधिक, हालाँकि कुछ और किलोबाइट बचाने के लिए आप इसे भी undefine कर सकते हैं।
एक iodine सर्वर कई डोमेन संभाल सकता है। एक ही डोमेन पर अलग-अलग NS रिकॉर्ड सेट
करें जो सभी एक ही होस्ट की ओर इंगित करें, और topdomain तर्क की शुरुआत में एक
वाइल्डकार्ड उपयोग करें (उदाहरण *.mydomain.com)। iodine उस पैटर्न से मेल खाने
वाले सभी डोमेन के लिए टनल ट्रैफ़िक स्वीकार करेगा। वाइल्डकार्ड topdomain तर्क की
शुरुआत में होना चाहिए और उसके बाद एक डॉट होना चाहिए।
यह अनुभाग कुछ प्रदर्शन मापों को तालिकाबद्ध करता है। ठीक से देखने के लिए, Courier जैसे फिक्स्ड-चौड़ाई वाले फ़ॉन्ट का उपयोग करें।
माप प्रोटोकॉल 00000502 में lazy मोड में किए गए थे; अपस्ट्रीम एन्कोडिंग हमेशा
Base128; iodine -M255; iodined -m1130। नेटवर्क स्थितियाँ अत्यधिक अनुकूल नहीं
थीं; परिणाम बेंचमार्क नहीं हैं बल्कि वास्तविक-विश्व प्रदर्शन का एक यथार्थवादी
संकेत हैं जिसकी समान स्थितियों में अपेक्षा की जा सकती है।
अपस्ट्रीम/डाउनस्ट्रीम थ्रूपुट को /dev/urandom से पहले पढ़ी गई फ़ाइल को scp
करके मापा गया (अर्थात असम्पीड्य), और एक अलग गैर-टनल कनेक्शन पर ls -l ; sleep 30 ; ls -l
के साथ आकार मापा गया। 16 kB के बड़े scp ब्लॉक आकार को देखते हुए, यह 4.3 kbit/s
का रिज़ॉल्यूशन देता है, जो बताता है कि कुछ मान बिल्कुल समान क्यों हैं। पिंग
राउंड-ट्रिप समय ping -c100 के साथ मापा गया, प्रस्तुत हैं औसत rtt और माध्य
विचलन (औसत के आसपास फैलाव दर्शाता है), मिलीसेकंड में।
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]
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
प्रदर्शन कम पिंग समय से दृढ़ता से जुड़ा हुआ है, क्योंकि iodine को अगले फ्रैगमेंट पर जाने से पहले प्रत्येक डेटा फ्रैगमेंट के लिए पुष्टि की आवश्यकता होती है। TCP की तरह कई फ्रैगमेंट को in-flight अनुमति देना संभवतः प्रदर्शन बढ़ा सकता है, लेकिन यह मध्यवर्ती 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 ड्राइवर के साथ, win32 readme फ़ाइल देखें) पर किया गया है। इसे TUN/TAP टनलिंग समर्थन वाले अन्य unix-जैसे सिस्टम पर पोर्ट करना आसान होना चाहिए। यदि आप इसे अन्य प्लेटफ़ॉर्म पर चलाने में सफल होते हैं तो हमें बताएं।
iodine नाम इसलिए चुना गया क्योंकि यह IOD (IP Over DNS) से शुरू होता है और क्योंकि आयोडीन की परमाणु संख्या 53 है, जो संयोगवश DNS पोर्ट नंबर है।
कॉपीराइट (c) 2006-2014 Erik Ekman [email protected], 2006-2009 Bjorn Andersson [email protected]। साथ ही Anne Bezemer द्वारा प्रमुख योगदान।
इस सॉफ़्टवेयर का किसी भी उद्देश्य के लिए, शुल्क सहित या बिना शुल्क, उपयोग, प्रतिलिपि, संशोधन और/या वितरण करने की अनुमति इसके द्वारा प्रदान की जाती है, बशर्ते कि उपरोक्त कॉपीराइट सूचना और यह अनुमति सूचना सभी प्रतियों में मौजूद रहें।
यह सॉफ़्टवेयर "जैसा है" (AS IS) प्रदान किया जाता है और लेखक इस सॉफ़्टवेयर के संबंध में सभी वारंटियों को अस्वीकार करता है, जिसमें व्यापारिकता और उपयुक्तता की सभी निहित वारंटियाँ शामिल हैं। किसी भी स्थिति में लेखक किसी भी विशेष, प्रत्यक्ष, अप्रत्यक्ष, या परिणामी क्षति, या उपयोग, डेटा या लाभ की हानि से उत्पन्न होने वाली किसी भी प्रकार की क्षति के लिए उत्तरदायी नहीं होगा, चाहे वह अनुबंध के कार्य, लापरवाही या अन्य टॉर्ट कार्य में हो, जो इस सॉफ़्टवेयर के उपयोग या प्रदर्शन से उत्पन्न या संबंधित हो।
MD5 कार्यान्वयन L. Peter Deutsch द्वारा (लाइसेंस और स्रोत src/md5.[ch] में)
कॉपीराइट (C) 1999, 2000, 2002 Aladdin Enterprises. सर्वाधिकार सुरक्षित।