यह देखते हुए: इंटरनेट की पूर्ण अनुपस्थिति और प्रमुख वाईफाई हॉट-स्पॉट, जिसमें वे लॉगिन पासवर्ड दर्ज करने का सुझाव देते हैं। या 3 जी, जिसमें कोई इंटरनेट नहीं है (क्योंकि पैसा बाहर भाग गया था), लेकिन प्रदाता का एक पृष्ठ है जिसमें इसे देने का प्रस्ताव है।
टास्क: इंटरनेट (कानूनी?) विधि को डीएनएस के माध्यम से सुरंग में लाने के लिए।
समाधान: linux + आयोडीन + रूटिंग + NAT + स्क्विड, और यह सब एक नेटवर्क मैनेजर द्वारा प्रबंधित किया जाता है।
लेख में: आयोडीन कार्यक्रम का उपयोग करते हुए एक डीएनएस सुरंग के संगठन का विवरण, गठित सुरंग के माध्यम से मार्ग को व्यवस्थित करने की बारीकियों, आयोडीन और नेटवर्क प्रबंधक के लिए एक स्वयं-सहायता सहायक।

गीत: भाग्य ने मुझे साइप्रस के शानदार द्वीप पर लाया, जो अपने पी / पाथोस, फ्रेपे और इंटरनेट के लिए प्रसिद्ध है, जिसके बाद रूसी ओपोस मांस में स्वर्गदूतों की तरह दिखाई देने लगते हैं। विशेष रूप से, इंटरनेट से जुड़ने का प्रयास इस उम्मीद के साथ समाप्त हुआ कि स्थानीय प्रदाता (yta) को दया आएगी, लेकिन इस धोखाधड़ी को समाप्त करके मेरे लिए गंदे ADSL 4Mb / 768kbit तक पहुंच जाएगा केवल € 151 (कनेक्शन) + € 40 प्रति माह (4 मेगाबिट्स के लिए) !> _ <)। प्रतीक्षा को खींचा गया और बढ़ाया गया था (जैसे कि तीसरा सप्ताह पहले ही चला गया था), और पास में ही शानदार प्राइमटेल था, जिसने मुझे इंटरनेट के साथ यहीं और अब € 4 / घंटा (172r / घंटा) के लिए मुश्किल से दिखाई देने वाले वाईफाई के माध्यम से खुश करने की पेशकश की। मैं भी सहमत हूँ, लेकिन पहुँच बिंदु केवल बालकनी पर दिखाई दे रहा था, और अपार्टमेंट में कनेक्शन अस्थिर था और अक्सर खो जाता था। तो केवल एक ही समाधान था (पड़ोसियों के WEP नेटवर्क को हैक करने के अलावा, जो कि बिल्कुल आपराधिक है) - DNS सेवा का दुरुपयोग करने के लिए, जो कि मुफ्त है, अर्थात, कुछ भी नहीं के लिए, कि PrimeTel अपने अपंजीकृत उप-कनेक्टर्स के लिए प्रदान करता है।

जो लोग "हाउटो" में रुचि रखते हैं वे समाधान को बाद में पाठ में पाएंगे, लेकिन अभी के लिए प्रक्रिया के सिद्धांत से शुरू करते हैं।

डीएनएस टनलिंग

यदि हमारे पास हाथ में एक काम करने वाला DNS रिज़ॉल्वर है (जो कि पुनरावृत्ति सक्षम वाला DNS सर्वर है), तो यह phobar.example.com होस्ट के IP पते के लिए हमारे अनुरोध पर जा सकता है। कॉम, उदाहरण के लिए जवाब देने वाले सर्वर के पते का पता लगाएं। com, example.com पर जाएं, पता करें कि फ़ॉबर के लिए कौन जिम्मेदार है, और विवरण के लिए निर्दिष्ट सर्वर के साथ जांचें। यह न केवल आईपी पते (ए और एएएए रिकॉर्ड) को पहचान सकता है, बल्कि अन्य जानकारी का एक गुच्छा भी है जिसे डीएनएस में संग्रहीत किया जा सकता है। विशेष रूप से:

• एमएक्स - में एक विवरण के साथ एक पंक्ति शामिल है, जो foobar.example.com को मेल भेजते हैं
• SRV - जिसमें (नई) सेवाओं के बारे में जानकारी होती है और किन पते पर होती है - उदाहरण के लिए, इसका उपयोग जैबर द्वारा किया जाता है
• TXT - पाठ के रूप में यादृच्छिक जानकारी। बहुधा इसका उपयोग SPF के लिए किया जाता है (यह बताने के लिए नियम कि कौन foobar.example.com डोमेन से मेल भेज सकता है)।

(यहाँ एक 300kb व्याख्यान खो गया है कि DNS क्या है और यह कैसे काम करता है)।
हमारी जरूरतों के लिए, एक साधारण चीज इस प्रकार है: हम रिवाल्वर को foobar.example.com से थोड़ी जानकारी प्राप्त करने के लिए कह सकते हैं। रिज़ॉल्वर जाएगा, पता करें, कैश (यदि हम इसे फिर से अनुरोध करते हैं, तो वह कैश से जवाब देगा) और हमें दे। यदि हर बार हम एक अलग रिकॉर्ड (इस क्षेत्र में एक अलग नाम या एक अलग प्रकार के रिकॉर्ड के लिए) का अनुरोध करते हैं, तो रिज़ॉल्वर आज्ञाकारी रूप से चलेगा और हल करेगा। हर बार। ध्यान दें कि इस प्रक्रिया को तेज करने के लिए, यह जानकारी को कैश करेगा "मुझे इस तरह की और इस तरह की जानकारी के लिए किस पर जाना चाहिए" और प्रक्रिया एक हॉप में जारी रहेगी।

हुर्रे, हमारे पास सर्वर से सूचना प्रसारित करने के लिए एक चैनल है। और वापस? लेकिन हम example.com से सीख सकते हैं। नहीं foobar.example.com, लेकिन, उदाहरण के लिए,

 0ahb282M-J2hbM-> M-nYM-VgdM-OJM-
 CM-> M-nivlm4M-T5M-FM-p1M-t5M-
 एफएम उम-IvLM-एचएम-समुद्री मील दूर-AM-IM-eLAM-
 BM-TM-qM-KM-UDM-NM-uM-] M-WM-
 jM-DdbM-> Mk.QVM-lM-uM -`v
 M-@3kGfM-fqFa.example.com

(यह इंटरनेट पर एक लंबी वेब साइट का पता है, जो अपने दोस्तों को तोड़ने के लिए जारी रखने की सुविधा के लिए एक कॉलम में लिखा गया है)

Resolver example.com पर जाएगा और उससे इस पते के बारे में पूछेगा। और यदि पता एन्कोडेड संदेश है? (क्रिप्टो-पुरुषों ने हलचल शुरू कर दी - एक संदेश नाम में एन्कोडेड!)
और अगर? .. हाँ, बिल्कुल। नाम में एक एन्क्रिप्टेड संदेश है। हमने सर्वर को सूचना प्रसारित करने का एक तरीका पाया। DNS सर्वर या एक नकली सर्वर जो DNS सर्वर होने का दिखावा करता है, लेकिन वास्तव में नामों में एन्क्रिप्टेड संदेशों को सुनता है और अनुरोधों के जवाब में एन्क्रिप्टेड संदेशों के साथ उनका जवाब देता है।

दूसरे शब्दों में, हम DNS रिसॉल्वर के माध्यम से सर्वर से सर्वर और क्लाइंट से डेटा चैनल प्राप्त करते हैं।

आयोडीन की उपयोगिता इसी सिद्धांत पर आधारित है। फिलहाल, मेरी टिप्पणियों के अनुसार, यह उचित मात्रा में अनुकूलन के साथ एकमात्र काम करने वाला एप्लिकेशन है।

आयोडीन की स्थापना

आयोडीन को कॉन्फ़िगर करना तीन महत्वपूर्ण चरणों के लिए नीचे आता है।
एक डोमेन ज़ोन तैयार करें।
सेटिंग्स के साथ सर्वर शुरू करें।
क्लाइंट को सेटिंग्स के साथ चलाएं।

उसके बाद, हमें अभी भी सीखना है कि इस चैनल का उपयोग कैसे किया जाए, लेकिन यह अगला अध्याय है।

तो, चलो कठिन भाग से शुरू करते हैं - DNS की तैयारी।

एक वाक्य में सेट करना: हमें भविष्य के आयोडीन सर्वर पर डोमेन ज़ोन को सौंपने की आवश्यकता है।
सेटिंग विस्तार:
हमें डोमेन नाम को प्रशासित करने के लिए एक्सेस की आवश्यकता है। यदि डोमेन हमारे सर्वर को सौंप दिया गया है - कोई समस्या नहीं है, हम बिन में उपडोमेन को पंजीकृत कर सकते हैं और इसे आयोडीन सर्वर में सौंप सकते हैं। यदि हमारे पास केवल एक "प्रदाता व्यवस्थापक पैनल" है - तो समस्या बहुत अधिक जटिल है - आपको किसी तरह दो उप डोमेन पंजीकृत करने की आवश्यकता है, उनमें से एक पर एनएस को इंगित करता है, दूसरा उपडोमेन को दर्शाता है, जो बदले में, पहले से ही एक रिकॉर्ड है।

उलझन में? चलो फिर से करते हैं। यहाँ मेरे विन्यास बाइंड से एक उदाहरण है:

 मैं एनएस जे में
 j एक 256.257.258.259 में

यह कहता है: i.example.com के पास NS के रूप में j.example.com सर्वर है, जिसका 256.257.258.259 का IP पता है।

एक हब पर एक डोमेन नाम पर नियंत्रण के बिना एक समस्या को हल करने के तरीके पर एक लेख है । लेकिन एक वास्तविक व्यवस्थापक के लिए, कम से कम कुछ डोमेन नाम पर नियंत्रण नहीं होना अजीब होगा, है ना?

दूसरा भाग सर्वर सेटअप है। यह काफी सरल है, हालांकि एक महत्वपूर्ण विवरण है: आप नियमित DNS सर्वर चलाने वाले सर्वर पर आयोडीन नहीं चला सकते हैं । कारण सरल है - इसे बदलने के अधिकार के बिना पोर्ट संख्या 53 / यूडीपी है।

सर्वर शुरू करना (आयोडाइन्ड) सरल है:

iodined 10.99.99.1/24 -c i.example.com (आपको वह नाम निर्दिष्ट करना होगा जिसके लिए हमने NS निर्दिष्ट किया है, और 'A' रिकॉर्ड वाला नाम नहीं। - यदि ऐसा नहीं किया जाता है, तो रिज़ॉल्वर बस आपके आयोडीन तक नहीं पहुंचेगा)। -c आईपी जाँच अक्षम करता है। मैं विवरण में नहीं गया था, लेकिन यह बेहतर है कि इस चीज को काम करने से पहले आपको किसी और के डीएनएस के साथ अकेला छोड़ दिया जाए। शुरुआत में पता सुरंग (टुनटैप) में पता होता है जो सर्वर के पास होगा। ग्राहकों को निम्नलिखित पते (.2, .3, आदि) प्राप्त होंगे।

यदि आयोडीन लॉन्च स्क्रिप्टेड है, तो आप अभी भी एक पासवर्ड जोड़ सकते हैं: iodined -P SECRET 10.99.99.1/24 -c i.example.com । आपको इसे रूट से चलाने की आवश्यकता है ताकि आयोडीन एक सुरंग जोड़ सके। सिद्धांत रूप में, इसे rc.local में जोड़ा जा सकता है, या बस नाम के साथ और उसके बाद चलाया जा सकता है।

महत्वपूर्ण: आयोडीन / आयोडीन युक्त संस्करण मेल खाना चाहिए। कड़ाई से। अन्यथा, कोई कनेक्शन नहीं होगा। यदि डेस्कटॉप पर लिनक्स का एक संस्करण है और सर्वर पर दूसरा (जो कि विशिष्ट है), तो सर्वर पर क्लाइंट से संस्करण को स्थापित करना बेहतर है। बस रिपॉजिटरी से deb'ku डाउनलोड करें और इंस्टॉल करें (लाभ है कोई निर्भरता नहीं है)।

एक ग्राहक शुरू करना भी सीधा है: iodine -P SECRET i.example.com ।

कनेक्शन के बाद, हमें उस पते के साथ एक सुरंग मिलती है जिसके माध्यम से दूरस्थ सर्वर उपलब्ध है (हमारे मामले में - 10.99.99.1)।

आप इसका उपयोग कर सकते हैं।

आप कर सकते हैं।

उपयोग करने के लिए।

और कैसे?

सुरंग के अंत में जीवन

यदि हम दूरस्थ सर्वर पर ssh बनाने की क्षमता के अलावा किसी और चीज में रुचि रखते हैं, तो आपको बाकी सब चीजों का एक गुच्छा करना होगा। इस बिंदु तक उपवास केवल मन की एक कलात्मक व्याख्या थी। लेकिन परिणामी सुरंग के व्यावहारिक उपयोग के लिए हमें गेटवे को बदलने, DNS सर्वर के लिए "सामान्य" मार्ग बनाए रखने और खंडित पैकेट के साथ समस्याओं पर काबू पाने के साथ समस्याओं को हल करने की आवश्यकता है।

यदि मोटे तौर पर, परिणामस्वरूप सुरंग का उपयोग करने के तीन तरीके हैं:

• सर्वर पर रूटिंग और NAT
• मोजे-प्रॉक्सी
• HTTP- प्रॉक्सी (स्क्विड)

हम उन सभी का विश्लेषण करेंगे (और फिर हम चर्चा करेंगे कि उन्हें कैसे कॉन्फ़िगर किया जाए)। रूटिंग के साथ मुख्य समस्या यह है कि नेटवर्क से गुजरने वाले पैकेटों का एमटीयू 1500 बाइट्स से कम है। बहुत कम। आपके प्रदाता के डीएनएस सर्वर के आधार पर, जिसका आप उपयोग करते हैं (नकारात्मक अर्थ में, "उपयोग"), आपको 1344 (आदर्श परिदृश्य) से 740 बाइट्स तक एक एमटीयू मिलता है। दूसरे शब्दों में, पैकेट विखंडन होता है। और पैकेट का विखंडन बहुत बुरा है। इसका मतलब यह है कि पैकेज खोने की संभावना 2-3 गुना बढ़ जाती है, क्योंकि यदि आप पैकेज की पूंछ खो देते हैं, तो आप इसे पूरी तरह से खो देते हैं। प्लस समाधान की सादगी और लालित्य है, साथ ही सभी सॉफ़्टवेयर के लिए शून्य कॉन्फ़िगरेशन भी है। चालू किया और काम किया। और कुछ साइटों पर कुछ बेवकूफ CDN / IDCs खंडित पैकेट को ब्लॉक करते हैं।

दूसरी ओर, हमारे पास सुरंग के माध्यम से एक दूरस्थ सर्वर (जिस पर iodined) के साथ एक टीसीपी सत्र स्थापित करने का अवसर है, जिस स्थिति में पैकेट सुरंग MTU आकार के साथ जाएंगे - कोई विखंडन नहीं। यदि हम अन्य टीसीपी कनेक्शनों को इस सुरंग में (प्रवाह स्तर पर, यानी सॉकेट्स पर) गुणा करते हैं, तो हम इस आकार के बाहरी दुनिया के पैकेटों के साथ संवाद कर पाएंगे जो हमें सूट करते हैं। हालाँकि, यहाँ हम एक और सेटअप की प्रतीक्षा कर रहे हैं। चैनल खराब होने पर TCP बहुत ही नापसंद है। इसमें क्या व्यक्त किया गया है? अब टीसीपी एक चैनल पर अचानक घाटे और रिट्रीट के साथ चलता है, कम यह भेजता है (यह मानते हुए कि पैकेट "भीड़ के कारण" खो जाते हैं)। नतीजतन, मल्टीप्लेक्स चैनल की गति धीरे-धीरे गिरती है, गिरती है, गिरती है ... यदि एसएसएल के माध्यम से टनलिंग होती है, तो उस पर एन्क्रिप्शन ओवरहेड भी लगाया जाता है। लगभग दस मिनट के बाद, खराब डीएनएस के साथ, टीसीपी सेगमेंट को व्यक्तिगत रूप से tcpdump / wirehark पर जांचा जा सकता है। एक और मुद्दा देर से उत्तरों के साथ अचानक देरी है, जो कई बार डुबकी लगाता है (मुझे टीसीपी इतनी अच्छी तरह से पता नहीं है कि यह खराब है या खराब है)। हालाँकि, मैं सेगमेंट को टीसीपी में भेजने के लिए समय-सीमा बदलने के लिए कर्नेल सेटिंग्स नहीं ढूँढ सका (कच्चे में परिभाषित एक को छोड़कर, लेकिन मैंने अपने कर्नेल को डीएनएस-सुरंग के तहत पुनर्निर्माण करने के लिए प्रबंधित नहीं किया - इंटरनेट जुड़ा था, और इस मुद्दे को विकसित करने में रुचि थोड़ी गायब हो गई। )। ध्यान दें कि यह एकमात्र तरीका है कि आप इसका उपयोग कर सकते हैं यदि यह बेहतर है कि रिमोट सर्वर पर कोई बड़ा बदलाव न करें। इस मामले में, हम सर्वर के साथ कमांड ssh -CD 1080 10.99.99.1 , 127.0.0.1:1080 पर ब्राउज़र में मोजे-प्रॉक्सी रजिस्टर करते हैं और इंटरनेट तक पहुंच रखते हैं। ब्राउज़र से। केवल। शेष सॉफ्टवेयर उसी के अनुसार कॉन्फ़िगर किया गया है।

सिद्धांत रूप में, कुछ कार्यक्रमों के लिए, टॉक्स की उपयोगिता मदद कर सकती है, जिससे आवेदन से मोज़े-प्रॉक्सी तक ट्रैफ़िक को जबरन लपेटा जा सके। यह इस तरह से उपयोग किया जाता है: /etc/tsocks.conf (127.0.0.1, पोर्ट 1080, आई रिमाइंड यू) में सही प्रॉक्सी एड्रेस रजिस्टर करें, और फिर tsocks my_net_appication app-arguments ।

एक और, अधिक दिलचस्प तरीका है: हम सर्वर पर iodined के साथ स्क्वीड बढ़ा सकते हैं, इसे आयोडाइंड इंटरफ़ेस (या बिल्कुल - लेकिन सुरंग के पते पर acl के साथ) सुनने के लिए कहें और क्लाइंट और सर्वर के बीच अनएन्क्रिप्टेड कनेक्शन का उपयोग करें। इस प्रकार, हम पहले अनफ़ैग्मेंटेड पैकेट प्राप्त करते हैं, और दूसरी बात, हमारे पास कई टीसीपी सत्र हैं जो डीएनएस सर्वर के अल्पकालिक अंतराल के कारण गिरावट की संभावना कम हैं।

दो डाउनसाइड हैं: सबसे पहले, हमारे पास संपीड़न नहीं है (ssh ट्रैफ़िक को पुनः प्राप्त कर सकता है, अर्थात, HTTP में सभी प्रेषित हेडर उत्कृष्ट बनते हैं), और दूसरी बात, ssl पास "जैसा है" या बिल्कुल भी पास नहीं होता है।

सुरंग की शुरुआत में जीवन: आयोडीन-एमएन-हेल्पर

एक अन्य समस्या सुरंग में डिफ़ॉल्ट गेटवे को कॉन्फ़िगर करना है। चूंकि स्क्वीड http-only है, इसलिए NAT के माध्यम से बाकी सब चीजों के लिए रूटिंग (IMAP मेल, Jabber, आदि) किए जाने की आवश्यकता है।

समस्या डिफ़ॉल्ट गेटवे का संगठन है। समस्या का सार यह है कि यदि हमारे dns सर्वर हमें दिए गए सेगमेंट में नहीं हैं (उदाहरण के लिए, हमें 5.10.10.10/24 दिया गया था, और DNS सर्वर 5.11.11.22 और 5.11.12.33 पर था), तो यदि हम डिफ़ॉल्ट गेटवे को बदलते हैं, तो हम खो देंगे DNS सर्वर के साथ संचार।

वर्तमान DNS सर्वर ढूँढना भी बहुत उबाऊ है। कुछ पीड़ा के बाद, मैंने एक सहायक स्क्रिप्ट लिखी: github.com/amarao/iodine-nm-helper

यह बहुत अपूर्ण है, और आगे के सुधारों का स्वागत है। लेकिन यह आयोडीन-क्लाइंट-स्टार्ट स्क्रिप्ट (आयोडीन के साथ पैकेज के साथ संलग्न) की तुलना में अधिक सुविधाजनक है, जो DNS समस्याओं को हल करने का तरीका नहीं जानता है।

NetworkManger का उपयोग करने के लिए स्क्रिप्ट डिज़ाइन की गई है। दुर्भाग्य से, मैंने डीएचसीपी पट्टे को अपडेट करने के बाद स्क्रिप्ट के बार-बार स्व-पुनरारंभ को मास्टर नहीं किया, इसलिए हर बार पट्टे को अपडेट किया जाता है, ब्रेकिंग को रूट किया जाता है और स्क्रिप्ट को फिर से शुरू करने की आवश्यकता होती है।

प्रदर्शन और कॉल की गुणवत्ता

मुफ्त के माननीय प्रेमियों, मैं निराश करने की जल्दबाजी करता हूं। वास्तविक परिस्थितियों में (प्रयोगशाला के बाहर) डीएनएस सुरंग बहुत धीमी हैं और सामान्य इंटरनेट का विकल्प नहीं हैं। यहां तक ​​कि टेली 2 से किनारा, जहां तक ​​ब्रेक लगाना भी तेज है। गिथब को खोलते समय फायरबग से एक तस्वीर नीचे दी गई है। निहारना और एक आंसू बहाना - ये लोडिंग के मिनट हैं, सब कुछ बस यही है।



गति बेहद असमान रूप से बदलती है। मैंने कुछ समय यह अध्ययन करने में बिताया है कि सुरंगों के माध्यम से काम करते समय tcp के साथ क्या हो रहा है - विशिष्ट व्यवहार के कारण, कई रिट्रांसमीट और डुप्लिकेट ack हैं, अर्थात, tcp अत्यंत असमान विलंबता के अनुकूल नहीं हो सकता, जब कोई पैकेट कुछ सेकंड के लिए "सुस्त" हो सकता है और यह कई दसियों / सैकड़ों मिलीसेकंड ले सकता है।

न्यूनतम "कुछ नहीं के बजाय कुछ" के रूप में इसका इस्तेमाल किया जा सकता है। उदाहरण के लिए, डाउनलोड के चरम पर (उम ... आकार में 1.6MB की एक विशाल फ़ाइल), मैंने 8kb / s तक की गति देखी, लेकिन यह जल्दी शून्य हो गया, और इस प्रक्रिया को कई बार फिर से शुरू करना पड़ा। यदि अगले कुछ दिनों में अच्छी साइट मुझे कनेक्ट नहीं करती है, तो मैं इस क़ीमती "रिट्रांसमिशन टाइमआउट" को खोजने के लिए टीसीपी के विकलों में थोड़ी गहराई तक खुदाई करूँगा।

Dhcp के साथ समस्या। प्रेटेल के पास डीएचसीपी के लिए एक छोटा पट्टा है। उसी समय, जब पट्टे को अपडेट करते हैं, तो मार्गों का स्वत: अद्यतन भी होता है, अर्थात्, हमारा डिफ़ॉल्ट गेटवे पैमटेलोवस्की द्वारा प्रतिस्थापित किया जाता है। मेरे सिर को खरोंचने के बाद, मैंने फैसला किया कि नेटवर्क 0.0.0.0/0 (उफ़, फिर से शून्य से विभाजित) का मार्ग कूलर होगा। उसी समय, डीएचसीपी के लिए गायब होने वाले मार्गों की समस्या बनी हुई है, जिसका समाधान मैं अभी तक नहीं आया हूं (विभिन्न नेटवर्क से पते जारी किए गए हैं, प्रत्येक ऐसे नेटवर्क का अपना प्रवेश द्वार है, इसलिए किसी के पास रूट अच्छे नहीं हैं, लेकिन मैंने किसी अन्य नेटवर्क के नेटवर्क पर एक पते को हथियाने के लिए अनैतिक और स्थैतिक माना) नेटवर्क का उपयोग)।

तो सवाल, आम तौर पर बोल रहा है, खुला है।

वैधता का सवाल

शायद सबसे कठिन। औपचारिक रूप से, मुझे वह मिलता है जो मुझे इसके लिए कई, कई, कई यूरो का भुगतान किए बिना नहीं मिलना चाहिए था। दूसरी ओर, वाईफाई ऑपरेटर हॉटस्पॉट ने स्वेच्छा से और होशपूर्वक अपने DNS सर्वर तक पहुंच खोली। मैं वास्तव में सेवा का उपयोग कैसे करता हूं, यह पहले से ही मेरी समस्या है, यह महत्वपूर्ण है कि मैं किसी भी प्रकार की हैकिंग को अंजाम न दूं (उदाहरण के लिए, पासवर्ड अनुमान लगाना पहले से ही एक स्पष्ट आपराधिक अपराध है, कंप्यूटर सिस्टम के लिए अनधिकृत पहुंच)।

मेरा मानना ​​है कि यह मुद्दा ग्रे ज़ोन में है (यानी अदालत में वकील के कौशल पर निर्भर करता है)। वास्तविक जीवन में, कोई भी परवाह नहीं करता है। अधिक सटीक रूप से, ऑपरेटर को परवाह नहीं हो सकती है कि उसका DNS सर्वर खराब हो गया है, लेकिन जब तक यह काम करता है - कोई समस्या नहीं है। आयोडीन से पता चलता है कि शानदार गति के प्रकाश में, सैकड़ों किलोवाट यातायात के "नुकसान" पर गंभीरता से चर्चा करना भी संभव नहीं है। सिद्धांत रूप में, इस मामले में ऑपरेटर के लिए सबसे अप्रिय है वाईफाई नेटवर्क पर डीएनएस और सहज यातायात पर लोड।

सेटिंग्स

(आगे सभी के लिए उबाऊ होगा जो धुन देंगे)।

सर्वर पर:
sysctl net.ipv4.ip_forward = 1
iptables -t nat -A POSTROUTING -s 10.99.99.0/24 -j MASQUERADE
iodined -P SECRET 10.99.99.1/24 -c i.example.com

ग्राहक पर:
vim /etc/iodine-nm-helper.conf (सेटिंग जोड़ें)
./iodine-nm-helper
(स्क्रिप्ट सुरंग के माध्यम से मार्ग को सही करेगी)

फ़ायरफ़ॉक्स में, सुरंग सर्वर के आईपी के माध्यम से http प्रॉक्सी सेट करें।

स्क्वीड विन्यास:

acl अच्छा src 10.99.99 / 24
http_access अच्छी लोकलहोस्ट की अनुमति देता है
http_access सभी को अस्वीकार करते हैं