I2P नेटवर्क क्लाइंट विकसित करने की मूल बातें। भाग २

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


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

लहसुन डेटा ट्रांसफर

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

गंतव्य बिंदुओं के बीच डेटा स्थानांतरित करने के लिए, I2NP लहसुन - "लहसुन" संदेश का उपयोग किया जाता है। संदेश स्वयं प्रेषित होते हैं और राउटर के बीच एन्क्रिप्ट किए जाते हैं, इसके लिए एन्क्रिप्शन कुंजी की एक अलग जोड़ी का उपयोग करते हुए, जिनमें से सार्वजनिक कुंजी लीज़सेट को प्रेषित की जाती है। यह कुंजी राउटर की सार्वजनिक कुंजी के साथ मेल नहीं खाती है, और बाद के विपरीत, यह प्रत्येक शुरुआत में एक नया उत्पन्न होता है। संदेश के अंदर "लहसुन" होते हैं, जिनमें से प्रत्येक में I2NP संदेश होता है और इसकी डिलीवरी के लिए निर्देश (4 प्रकार):

• स्थानीय। संदेश राउटर के लिए ही है। आमतौर पर किसी की लीजसेट।
• गंतव्य बिंदु। संदेश राउटर से जुड़े गंतव्य के लिए अभिप्रेत है। यह गंतव्य तक डेटा भेजने का एकमात्र तरीका है।
• सुरंग। संदेश को निर्दिष्ट राउटर पर शुरू करने के लिए निर्दिष्ट इनकमिंग सुरंग में भेजने का इरादा है। लहसुन की डिलीवरी की पुष्टि करने के लिए उपयोग किया जाता है।
• मर्चेंटाइज़र। संदेश दूसरे राउटर को भेजने का इरादा है। सुरक्षा के दृष्टिकोण से बेहद खतरनाक है, यदि निर्दिष्ट राउटर अपने स्वयं के या विश्वसनीय से अलग है। व्यवहार में, मिले नहीं।

एक नियम के रूप में, "लहसुन" में दो "लहसुन" शामिल हैं। सबसे पहले डिलीवरीस्टैटस I2NP संदेश "लहसुन" के संदेश संख्या के साथ है और प्रेषक के राउटर की आने वाली सुरंगों में से एक को डिलीवरी करता है। गंतव्य के लिए सभी "लहसुन" के वितरण की पुष्टि करने के लिए उपयोग किया जाता है। दूसरा एक I2NP डेटा संदेश है जिसमें स्वयं प्रेषित डेटा है, जो गंतव्य तक पहुँचाया गया है। कभी-कभी एक तीसरा "लहसुन" होता है - प्रेषक का गंतव्य स्थल (मार्च नहीं)। हमारे उदाहरण में, यह वासिया के रिटर्न एड्रेस का लीजसेट है। यह "लहसुन" दो मामलों में मौजूद है: पहले संदेश में और जब लीजसेट बदलता है। यह इसलिए किया जाता है कि राउटर को पता होगा कि प्रेषक को प्रतिक्रिया कैसे भेजनी है, अन्यथा आपको फ्लडफिल राउटर से उपयुक्त लीसेटसेट का अनुरोध करना होगा, जो कि वहां सबसे अधिक अनुपस्थित रहेगा, जैसे कि वासिया का वापसी पता और वास्या की गुप्त वेबसाइट, इसके विपरीत, वहां मौजूद होगा।
सवाल उठता है कि फ्लिबुस्टा को कैसे पता चलता है कि इसका जवाब वास्या को भेजा जाना चाहिए, न कि पेट्या या किसी और को जो उसी क्षण उससे संपर्क कर रहा है। यहां तक ​​कि अगर यह पता था कि "लहसुन" वसाया से आया है, जो निश्चित रूप से नहीं है, तो यह बहुत मदद नहीं करेगा, क्योंकि वास्या के राउटर की वेबसाइट भी है और संभवतः, बहुत अधिक । यह पता चला है कि यह जानकारी डेटा संदेश में प्रेषित डेटा के भीतर समाहित होनी चाहिए, जो पूरे सिस्टम के असफल डिजाइन को इंगित करता है, क्योंकि यह एक-दूसरे से अलग-अलग स्तरों के प्रोटोकॉल को अलग करने की अनुमति नहीं देता है। दूसरे शब्दों में, गंतव्य पता इस डेटा को प्रसारित करने के लिए डेटा में और प्रोटोकॉल में दोनों मौजूद होना चाहिए।

I2CP प्रोटोकॉल डेटा

प्रारंभ में, I2CP प्रोटोकॉल को विशेष रूप से विभिन्न अनुप्रयोगों और राउटर के बीच आदान-प्रदान के लिए विकसित किया गया था - इसके संदेश I2P नेटवर्क को स्वयं नहीं भेजे जाने चाहिए। हालाँकि, SendMessageMessage और MessagePayloadMessage संदेशों की सामग्री I2NP डेटा संदेशों के अंदर नेटवर्क पर प्रसारित होती हैं, और व्यू हेडर को बदलने के लिए एक विशेष तरीके से gzip-संग्रहीत डेटा होते हैं।

0x1F 0x8B 0x08 - गज़िप उपसर्ग
गज़िप के झंडे के 1 बाइट
2 बाइट्स टीसीपी या यूडीपी प्रेषक पोर्ट
रिसीवर के 2 बाइट्स टीसीपी या यूडीपी पोर्ट
अतिरिक्त गज़िप के झंडे के 1 बाइट
प्रोटोकॉल प्रकार के 1 बाइट: 6 - स्ट्रीमिंग, 17 - डेटाग्राम, 18 - कच्चे

इस प्रकार, लहसुन के माध्यम से प्रसारित प्रत्येक डेटा संदेश हमेशा 0x1F 0x8B 0x08 के साथ शुरू होगा और सबसे पहले इसे gzip द्वारा अनपैक किया गया है और, प्रोटोकॉल के प्रकार के आधार पर, इसे संबंधित कार्यान्वयन द्वारा संसाधित किया जाता है।

स्ट्रीमिंग प्रोटोकॉल

स्ट्रीम प्रोटोकॉल टीसीपी प्रोटोकॉल के समान है और डेटा ट्रांसमिशन के अनुक्रम की गारंटी देता है। संदेशों में एक हेडर और डेटा होता है। संदेश का प्रकार ध्वज क्षेत्र द्वारा निर्धारित किया जाता है, टीसीपी के समान, कनेक्शन स्थापित करने और डिस्कनेक्ट करने के लिए SYN / FIN ध्वज हैं। टीसीपी के विपरीत, 255 एनएके तक भी मौजूद हो सकते हैं - उन्हें पुनः भेजने की आवश्यकता के साथ छूटे हुए संदेशों की संख्या, जो पैकेट प्रोटोकॉल के लिए अधिक विशिष्ट है और एक अधिक जटिल कार्यान्वयन की आवश्यकता है। इसमें मानक टीसीपी क्षेत्र भी शामिल हैं: प्रेषक और रिसीवर के 4-बाइट पोर्ट, स्ट्रीम, अनुक्रम संख्या और एक्सपोज़र नंबर।
जब कोई कनेक्शन स्थापित होता है, तो संदेशों का आदान-प्रदान SYNCHRONIZE ध्वज सेट के साथ किया जाता है, और FROM_INCLUDED और SIGNATURE_INCLUDED ध्वज सेट होने चाहिए। पहले का अर्थ है कि हेडर में पूर्ण 387-बाइट I2P पता है, और दूसरा कि पूरा संदेश प्रेषक के I2P निजी कुंजी के साथ हस्ताक्षरित है। इस तरह, पार्टियां एक-दूसरे के I2P पते को पहचानती हैं, और हस्ताक्षर का सत्यापन सुनिश्चित करता है कि ये पते असली हैं। दूसरे शब्दों में, Vasya, Flibusta के पते से जुड़ने के बाद, कनेक्शन स्थापित होने के बाद, वह यह सुनिश्चित कर सकती है कि यह Flibusta है, और Flibusta को Vasya का पता पता होगा।
इस प्रकार, धारा प्रोटोकॉल इंटरफ़ेस को साधारण सॉकेट्स के रूप में लागू किया जा सकता है, जो न्यूनतम परिवर्तनों के साथ नेटवर्क अनुप्रयोगों में I2P के उपयोग की अनुमति देता है।