अच्छे दिन, सहकर्मियों।
कुछ समय पहले मुझे एक विषय में दिलचस्पी हो गई। खोज ने बहुत सारी सामग्री प्राप्त की, जिसके अध्ययन के दौरान कई प्रश्न उठे और मैं अभ्यास में कुछ सैद्धांतिक बिंदुओं की जांच करना चाहता था। कोई रुचि रखता है - कृपया।
उन लोगों के लिए जो इस विषय में नहीं हैं कि सममितीय NAT क्या है।
जिसमें एक साधारण योजना पर विचार करें
host1, host2 - उपयोगकर्ता NATs के पीछे होस्ट करता है
NAT1, NAT2 - NAT प्रदान करने वाले एज डिवाइस
जब host1 एक निश्चित real_IP के साथ एक आउटगोइंग कनेक्शन (TCP या UDP) शुरू करता है, NAT1 डिवाइस अपने स्वयं के साथ अपने आउटगोइंग पैकेट में स्रोत IP की जगह लेता है (वैकल्पिक रूप से अपने स्वयं के साथ, लेकिन हम इसे सरलता और स्पष्टता के लिए स्वीकार करेंगे), और यह सामान्य रूप से PORT_SRC के साथ यादृच्छिक PORT_SRC1 की जगह भी लेता है।
host1 ____ PORT_SRC, PORT_DST ---> NAT1 डिवाइस PORT_SRC1, PORT_DST ----> real_IPतो, NAT सममित होगा यदि real_IP होस्ट को NAT1 डिवाइस द्वारा अग्रेषित किया जाएगा यदि और केवल अगर इस प्रतिक्रिया पैकेट में स्रोत IP ही असली_IP है, तो स्रोत पोर्ट PORT_DST होगा, और गंतव्य पोर्ट PORT_SRC1 होगा। यही है, real_IP अपने पते से जवाब देगा, उसी बंदरगाह से जहां कनेक्शन था, और उसी बंदरगाह से जहां NAT1 डिवाइस से आउटगोइंग कनेक्शन था। यह नोटिस करना मुश्किल नहीं है कि शब्द "समरूपता" यहां एक अच्छा विचार नहीं था।
हमारे पास क्या है जब कार्य सममित एनएआर के माध्यम से "तोड़ने" और मेजबानों को सीधे इसके साथ संवाद करने की अनुमति है?
सामान्य मामले में, हमारे पास निम्नलिखित सरल किन्नर हैं।
host1 ----> NAT1 SRC1_random, DST1_required ---->
<- DST2_as_a इच्छा, SRC2_random NAT2
<- host2SRC1_random - NAT1 द्वारा NAT प्रतिस्थापन के बाद स्रोत बंदरगाह;
DST1 वांछित के रूप में - NAT1 के माध्यम से host1 के साथ स्थापित आउटगोइंग कनेक्शन के लिए गंतव्य बंदरगाह हमारे द्वारा चुना जा सकता है;
DST2_wanted - NAT2 से NAT1 के माध्यम से host2 से भेजे गए पैकेट के लिए गंतव्य बंदरगाह का चयन हमारे द्वारा किया जा सकता है;
SRC2_random - NAT के बाद स्रोत पोर्ट NAT2 द्वारा खराब कर दिया गया है।
यदि आप इस आरेख को करीब से देखते हैं, तो "ब्रेकडाउन" के लिए कठिनाइयां स्पष्ट हैं। काम करने के लिए ट्रैफ़िक एक्सचेंज के लिए, यह किया जाना चाहिए: SRC1_random = DST2_by_ इच्छा और DST1_by_require = SRC2_by मौका।
डिवाइस होस्ट 1 और होस्ट 2 एसआरसी 1 यादृच्छिक और एसआरसी 2 यादृच्छिक को नियंत्रित नहीं कर सकते। सामान्य तौर पर, वे वास्तव में यादृच्छिक होंगे, साथ ही यह गंतव्य आईपी और गंतव्य बंदरगाह पर निर्भर करता है। इस विषय पर खोज करके पाई गई सामग्रियों के द्रव्यमान ने इस सरल तथ्य को नजरअंदाज कर दिया, यह मानते हुए कि एक साधारण STUN सर्वर इन अज्ञात को पहचानने के लिए पर्याप्त है।
हाँ की तरह। अगर हम NAT का उपयोग करते हुए संगठित होते हैं, तो iptables कहते हैं, तो फॉर्म का निर्माण
-t nat -A POSTROUTING -j MASQUERADE
या
-t nat -A POSTROUTING -j SNAT -to-source
केवल स्रोत IP की जगह लेगा, आउटगोइंग पोर्ट क्लाइंट पर ही रहेगा। इस प्रकार, कार्य बहुत सरल हो गया है और इस NAT बायपास तकनीक के लिए मध्यस्थ की भूमिका का वर्णन करने वाले बहुत सारे लेख सिर पर कील ठोकने लगते हैं।
लेकिन यह एक विशेष और सरल मामला है।
समान iptables के लिए, इन निर्माणों को प्रतिस्थापित किया जा सकता है
-t nat -A POSTROUTING -j MASQUERADE ... --random
या
-t nat -A POSTROUTING -j SNAT --to-source ... --random
और स्थिति कम मजेदार हो जाएगी। NAT रूपांतरण के दौरान आउटबाउंड पोर्ट को बेतरतीब ढंग से चुना जाएगा।
कुल, ऊपर दिए गए आरेखों पर सावधानीपूर्वक नज़र रखने के बाद, हमें निम्नलिखित समस्याएं हैं।
SRC1 यादृच्छिक और SRC2 यादृच्छिक के बारे में न तो host1 और host2 को पता है, वे उन्हें केवल अप्रत्यक्ष रूप से प्रभावित कर सकते हैं, उदाहरण के लिए, अपने आउटगोइंग पैकेट के लिए स्रोत पोर्ट को बदलने या डेटा भेजने के बीच पर्याप्त मध्यांतर के साथ ताकि NAT उपकरणों पर अनुवाद के लिए प्रविष्टियों के आउटडेटेड और रीसेट होने का समय हो। ।
Host2 को, अन्य चीजों के अलावा, इच्छा के अनुसार DST1 का पता लगाना चाहिए (सामान्य तौर पर, पोर्ट पर पहले से सहमति दी जा सकती है, लेकिन हम सबसे खराब स्थिति पर विचार करेंगे)।
एक मध्यस्थ की आवश्यकता के लंबे स्पष्टीकरण में जाने के बिना, मैं तुरंत एक्सचेंज में सभी प्रतिभागियों के लिए कार्यों की अनुमानित एल्गोरिथ्म को रेखांकित करूंगा।
1. एक मध्यस्थ की सख्त जरूरत होती है, जिसके साथ host1 और host2 मुक्त दो-तरफा यातायात प्रवाह के साथ पूर्ण नियंत्रण कनेक्शन स्थापित करते हैं। ऐसे नियंत्रण सत्रों के आरंभकर्ता NAT के पीछे मेजबान होते हैं। एक मध्यस्थ मेजबान को समाप्त करने के लिए अपने सफेद आईपी के बारे में जानकारी वितरित करता है।
2. मान लीजिए कि host1 टारगेट कनेक्शन / क्लाइंट का सर्जक होगा, और host2 के लिए कनेक्शन इनकमिंग होगा, यानी यह एक सर्वर की तरह काम करेगा।
3. Host1 ने NAT2 के वास्तविक पते पर पैकेट भेजना शुरू कर दिया, DST1_will को मनमाने ढंग से चुनना।
4. नियंत्रण कनेक्शन पर Host1 चयनित DST1_preference के मध्यस्थ को सूचित करता है और NAT1 को निरंतर प्रसारण बनाए रखने के लिए समान मापदंडों (स्रोत पोर्ट, गंतव्य पोर्ट) के साथ पैकेट भेजना जारी रखता है ताकि SRC1 यादृच्छिक बदल न जाए। शिपमेंट के बीच देरी को प्रयोगात्मक रूप से निर्धारित किया जा सकता है, कार्य की तुच्छता के कारण, मैं इसे पेंट नहीं करता हूं और इसे इस पाठ में शामिल नहीं करता हूं।
5. दलाल NAT1 को स्कैन करता है, स्रोत IP को NAT2 के पते से प्रतिस्थापित करता है, स्रोत पोर्ट DST1_as को वांछित प्रदान करता है और गंतव्य बंदरगाह को 1024 (या 65535 की संपूर्ण सीमा) से छाँटता है। यह सब आवश्यक है, क्योंकि हमने पहले निर्णय लिया था कि NAT व्यर्थ में सममित नहीं है।
जब गणना के परिणामस्वरूप (यदि हम इस समय NAT1 द्वारा प्रतिबंधित नहीं हैं), तो हम अंततः गंतव्य पोर्ट SRC1_random के साथ एक पैकेट भेजते हैं, फिर ऐसा पैकेट, अगर कुछ विशेष रूप से मुश्किल सुरक्षा तंत्र जो NAT कार्यात्मक के दायरे से परे है, host1 को पास किया जाएगा । वह नियंत्रण चैनल पर पता लगाता है और आगे मध्यस्थ को सूचित करेगा, और वह अनुमानित मूल्य SRC1_random को याद रखेगा।
6. होस्ट 2 SRC1_random को कंट्रोल चैनल पर मध्यस्थ रिपोर्ट।
7. होस्ट 2 पैकेट को बाहरी पते NAT1 पर भेजना शुरू करता है, इन पैकेटों में गंतव्य पोर्ट DST2_of_desire = SRC1_random होना चाहिए। उसे यह तब तक करना होगा जब तक NAT2 डिवाइस द्वारा चयनित SRC2_random DST1_of_will से मेल नहीं खाता।
जब यह लंबे समय से प्रतीक्षित संयोग होता है, तो दो विकल्प संभव हैं।
पहला वाला। ऐसा पैकेट host1 तक पहुंचेगा, यह मध्यस्थ को इस बारे में सूचित करेगा, मध्यस्थ host2 को सूचित करेगा, और "खुश" सत्र जारी रहेगा।
दूसरा वाला। Host2, "swotting" के साथ एक बार फिर NAT1 को नाराज़ नहीं करना चाहता था, अपने आउटगोइंग पैकेट्स में IP-ttl को इस तरह बदल दिया कि वे NAT2 से गुज़रें, लेकिन NAT1 तक नहीं पहुंचे। उसी समय, NAT2 में अनुवाद तैयार किए जाते हैं, पैकेट NAT1 तक नहीं पहुंचते हैं, लेकिन जब प्रतिष्ठित अनुवाद बनाया जाता है, तो पैकेट host1 से होता है (और हम यह नहीं भूले हैं कि यह इसके अनुवाद का समर्थन करता है जैसा कि पहले वर्णित है, अर्थात्, यह "NAT2 पर" निरंतर मापदंडों के साथ है) host2 तक पहुंच जाएगा, और यह बदले में मध्यस्थ और इतने पर सूचित करेगा।
जैसा कि आप देख सकते हैं, सामान्य मामले में, सममित एनएआर को तोड़ना इतना सरल और तेज़ कार्य नहीं है। विभिन्न कार्यान्वयन पर (iptables को याद रखें), इसे महत्वपूर्ण रूप से सरल बनाया जा सकता है और गारंटीकृत सफलता के साथ एक प्रक्रिया में बदल सकता है, लेकिन, मैं दोहराता हूं, सामान्य मामले में नहीं।
वर्णित एल्गोरिथ्म के सबसे अड़चन क्या हैं?
1. पैराग्राफ में स्पूफिंग की आवश्यकता 5. मध्यस्थ के पास नेटवर्क तक पहुंचने का एक तरीका होना चाहिए जो इसे अनुमति देगा और प्रदाता से कोई समस्या नहीं होगी।
2. चरण 5 में बंदरगाहों की एक बड़ी रेंज को स्कैन करना। मुझे फिर से "सही" NAT के मामले में दोहराएं, host1 के लिए यह असंभव है कि वह मध्यस्थ के साथ एक संबंध स्थापित करे और यह मान ले कि NAT2 के संबंध में यादृच्छिक SRC1_ समान होगा, बाकी सभी समान हो रहे हैं। गंतव्य पता बदलने से SRC1_random बदल जाएगा। स्कैन, ज़ाहिर है, जल्दी और आक्रामक तरीके से किया जा सकता है, आप अधिक सावधान हो सकते हैं, लेकिन लंबे समय तक। किसी भी मामले में, यह एक कमजोर बिंदु है।
3. अनुच्छेद 7 से कार्य अनिश्चित काल तक हो सकते हैं। बस इस पल ने मेरी जिज्ञासा और कोशिश करने की इच्छा जगा दी।
4. और निश्चित रूप से, कोई व्यक्ति जो इतने सारे पत्र पढ़ने से थक गया है, कह सकता है: "यह आवश्यक है, एक मध्यस्थ के माध्यम से सभी लक्षित ट्रैफ़िक को चलाएं और बस!" यहां बहस करना मुश्किल है, निश्चित रूप से, मैं इस पाठ द्वारा लिए गए समय के लिए उनसे माफी मांगता हूं।
अब अभ्यास करना है। शायद मैं उन लोगों को निराश करूंगा जो विषय में रुचि रखते थे, लेकिन मैंने एक मध्यस्थ नहीं लिखा :) tcpdump ने अपनी भूमिका सही जगह और सही समय पर निभाई, साथ ही साथ लेखक की आंखें और हाथ भी :) लेकिन मुझे अभी भी कुछ दिलचस्प परिणाम नहीं मिले।
So. हमारे पास 3 जी = होस्ट 1 के साथ एक विंडोज वर्कस्टेशन है। मॉडेम कनेक्शन पर, ग्रे एड्रेस 10.140.80.130 जारी किया गया था। यह NAT के पीछे host1 का आंतरिक पता है।
इस राउटर के ठीक पीछे एक सफेद पता xx.xx.xx.xx और host2 के साथ AT AR-750s राउटर है।
हम इच्छा के अनुसार एक मनमाना DST1 चुनते हैं, मेरे मामले में यह 21393 के बराबर था।
हम होस्ट 1 से 10 सेकंड की आवृत्ति के साथ शुरू करते हैं, जो यूडीपी पैकेट को xx.xx.xx.xx: 21393 पर भेजते हैं।
दुर्भावनापूर्ण स्कैन के चरण को छोड़ते हुए, हम होस्ट 21 में पोर्ट 21393 के बारे में "गुप्त रूप से" जानकारी लाते हैं, साथ ही "झाँकते" यह जानकारी भी लेते हैं कि SRC1 मोबाइल ऑपरेटर के NAT ऑपरेटर के लिए यादृच्छिक है, हमारे पास 45499 (अच्छी तरह से, IP) है, जिसमें से हम NAT-it-eater हैं too = yy.yy.yy.yy)।
Host2 से, हम yy.yy.yy.yy पर "धमाका" करना शुरू करते हैं: 45499 और हमारे भाग्यशाली होने की प्रतीक्षा करें और हमारे आउटगोइंग पैकेट को NAT के बराबर स्रोत पोर्ट 21393 के बराबर प्राप्त होगा। मैंने ttl में गड़बड़ नहीं की, मैंने host1 और host2 पर स्निफर्स द्वारा ब्रेकडाउन का पता लगाया। । होस्ट 2 से पैकेट जनरेशन की गति ~ 5 पैकेट प्रति सेकंड थी। उसी समय, NAT2 राउटर थोड़ा बाहरी (उपयोगकर्ताओं को सुना होगा) ट्रैफ़िक से भरा हुआ था।
पहला "ब्रेकडाउन" प्रयोग शुरू होने के लगभग 8 घंटे बाद हुआ। फिर कुछ और हुआ, क्योंकि पूरे खेत को रात भर काम करने के लिए छोड़ दिया गया था। बाद वाले कई बार तेजी से होने लगे, यहां आप "बाहरी" यातायात के प्रभाव के बारे में कल्पना कर सकते हैं।
यह "ब्रेकडाउन" जैसा दिखता था। निष्कर्ष चयनात्मक है, जिसमें आवश्यक संयोग के साथ केवल "खुश" पैकेज शामिल हैं।
ट्रैफ़िक संग्रह के "मुश्किल" बिंदु पर स्निफ़र आउटपुट, जिसमें यह (ट्रैफ़िक) NAT के बाद AR-750 राउटर के बाहरी इंटरफ़ेस पर दिखाई देता है
02: 19: 05.060809 IP xx.xx.xx.xx.21393> yy.yy.yy.yy.45499: UDP, लंबाई 0
05: 07: 00.178149 आईपी xx.xx.xx.xx.21393> yy.yy.yy.yy.45499: UDP, लंबाई 0
06: 28: 35.355623 आईपी xx.xx.xx.xx.21393> yy.yy.yy.yy.45499: UDP, लंबाई 0
07: 16: 29.764069 आईपी xx.xx.xx.xx.21393> yy.yy.yy.yy.45499: UDP, लंबाई 0
11: 28: 06.899109 आईपी xx.xx.xx.xx.21393> yy.yy.yy.yy.45499: UDP, लंबाई 0
होस्ट 1 पर स्निफर आउटपुट, जिसमें ब्रेकडाउन का "पता लगाया गया" (समय सिंक्रनाइज़ नहीं है, इसलिए होस्ट 2 ट्रैफ़िक के डंप से टाइमस्टैम्प और प्रिंटआउट के बीच कुछ विसंगति है)।
02: 18: 20.480468 आईपी xx.xx.xx.xx.21393> 10.140.80.130.2429: यूडीपी, लंबाई 0
05: 06: 15.496093 आईपी xx.xx.xx.xx.21393> 10.140.80.130.2429: यूडीपी, लंबाई 0
06: 27: 50.464843 आईपी xx.xx.xx.xx.21393> 10.140.80.130.2429: यूडीपी, लंबाई 0
07: 15: 44.839843 आईपी xx.xx.xx.xx.21393> 10.140.80.130.2429: यूडीपी, लंबाई 0
11: 27: 21.589843 आईपी xx.xx.xx.xx.21393> 10.140.80.130.2429: यूडीपी, लंबाई 0
सीधे host2 पर एक डंप का परिणाम भी था, जिसमें यह स्पष्ट था कि बिंदु 4 से पैकेट जो NAT1 को अपरिवर्तित अनुवाद का समर्थन करते थे, होस्ट 2 तक पहुंचने लगे, लेकिन मैंने इसे बोया।
यहाँ एक नहीं-ईमानदार प्रयोग है। लेकिन उन्होंने दिखाया कि पैरा 7 में अपेक्षाकृत कम खोज आवृत्ति के साथ, वांछित परिणाम अपेक्षाकृत उचित समय में प्राप्त किया जा सकता है। यह अधिक आक्रामक हलचल के साथ और भी अधिक उचित बन सकता है। बेशक, "औद्योगिक" आवेदन आकर्षित नहीं करता है, लेकिन ... लेकिन यह संभव है। वर्णित एल्गोरिथ्म और प्रयोग त्वरण-अनुकूलन-बहु-थ्रेडेड दृष्टिकोण और पसंद के विषय पर विचार के लिए भोजन प्रदान करता है।
UPD: मैं यह उल्लेख करना भूल गया कि पैकेटों को host2 से सोर्स पोर्ट में बदलाव के साथ भेजा गया था, ताकि NAT2 के लिए सोर्स पोर्ट भी बदल जाए, अनुवाद के लिए NAT2 के मरने की प्रतीक्षा करना बहुत महंगा है।