यूडीपी छेद पंचिंग टाइमआउट

Question

मुझे एक यूडीपी प्रोटोकॉल को लागू करने की आवश्यकता है। आने वाले पैकेट के लिए पीसी को एक समर्पित यूडीपी पोर्ट पर सुनना है। यह पैकेट (उत्तर) भी भेजता है। एप्लिकेशन विंडोज एक्सपी, 7, 8, पर चलता है ....

विंडोज फ़ायरवॉल आने वाले पैकेट को अवरुद्ध करता है। यह यूडीपी छेद पंचिंग द्वारा बाधित किया जा सकता है। तो मुझे कुछ ऐसा भेजना है जो चोट नहीं पहुंचाए। लेकिन मैं जितना संभव हो उतना परेशान करना चाहता हूं।

• फ़ायरवॉल छेद बंद होने तक मैं टाइमआउट कैसे निर्धारित कर सकता हूं?
• क्या मुझे पता चल सकता है कि फ़ायरवॉल ने फ़ायरवॉल बंद कर दिया है ताकि मुझे पैकेट खोलने के लिए फिर से भेजना पड़े? निश्चित रूप से जब फ़ायरवॉल बंद हो जाता है तो मुझे कुछ भी प्राप्त नहीं होगा लेकिन इसके अन्य कारण भी हो सकते हैं।

Answer 1

मेरे अपने प्रश्न का उत्तर देने के लिए: टाइमआउट निर्धारित करने का कोई तरीका नहीं है। आपको यूडीपी कनेक्शन के लिए विंडोज 7 फ़ायरवॉल का उपयोग करने के लिए कौन सा टाइमआउट प्रयोग करना होगा। वर्तमान अनुभव चार सेकंड टाइमआउट दिखाता है लेकिन यह भिन्न हो सकता है।

छेद पंचिंग के लिए कुछ सामान्य टिप्स:

1. नेटवर्क में किसी भी अन्य मेजबान परेशान न करें। एक ऐसी सामग्री के साथ एक पैकेट भेजें जो चोट नहीं पहुंचाता है।
2. उस होस्ट को भेजना जरूरी नहीं है जिसे आप अपनी प्रतिक्रिया के प्रेषक बनना चाहते हैं।
3. यूडीपी पोर्ट को भेजना जरूरी नहीं है जिसे आप प्रेषक बनना चाहते हैं। किसी भी यूडीपी पोर्ट को भेजें। एक विवाद बंदरगाह (9) है जिसे आप जो भी भेजते हैं उसे अनदेखा करना चाहिए।
4. सुनिश्चित करें कि आप वास्तव में पैकेट भेज चुके हैं। यदि आप किसी ऐसे होस्ट को भेजने का प्रयास करते हैं जो पिछली बार नहीं देखी गई है, तो आईपी स्टैक एमएसी पता प्राप्त करने के लिए एआरपी प्रोटोकॉल का उपयोग करेगा। यदि आईपी स्टैक को एआरपी प्रतिक्रिया नहीं मिलती है, तो यह भेज नहीं सकती है और आईपी पैकेट नहीं है और कोई छेद पेंच नहीं किया जाता है। नेटवर्क प्रसारण पते पर भेजकर इस समस्या को बाधित किया जा सकता है।
5. सुनिश्चित करें कि आप सही एडाप्टर के प्रसारण पते का उपयोग करके वांछित नेटवर्क पर छेद पंच करें।

Answer 2

छेद पंचिंग पर कुछ टिप्स:

1. सबसे फायरवॉल पर (मैं Windows फ़ायरवॉल मान के रूप में अच्छी तरह से) छेद पंचिंग केवल किसी विशिष्ट IP कनेक्ट करने के लिए अनुमति देता है। होल पंचिंग ट्रिक्सवॉल/एनएटीएस को यह सोचने में ट्रिक्स करता है कि आप किसी विशेष आईपी से संचार कर रहे हैं ताकि यह उस आईपी से वापस आने वाले पैकेट को अनुमति दे सके। यदि आप किसी भी आईपी को सुनना चाहते हैं, तो आप पुल कंप्यूटर के बिना छेद पंचिंग का उपयोग नहीं कर सकते हैं जो कनेक्शन को समन्वयित कर सकता है।
2. फ़ायरवॉल और/या एनएटी के बीच समय भिन्न हो सकता है। आपको केवल सॉफ्टवेयर फ़ायरवॉल (जैसे विंडोज फ़ायरवॉल) के बारे में चिंता करने की ज़रूरत नहीं है, लेकिन यदि हार्डवेयर समय फ़ायरवॉल और/या एनएटी डिवाइस है, तो आपको उस समय के बारे में चिंता करने की ज़रूरत है। एक मूल्य हार्डकोडिंग तब तक काम नहीं करेगा जब तक कि आपके पास एक बहुत ही विशिष्ट नेटवर्क और सॉफ़्टवेयर सेटअप न हो। यह पता लगाना कि फायरवॉल ने छेद को एक महान विचार की तरह बंद कर दिया है, सिवाय इसके कि अधिकांश फ़ायरवॉल/एनएटी के पास यह पता लगाने का कोई तरीका नहीं है कि उन्होंने छेद बंद कर दिया है और जहां तक ​​मुझे पता है, आपके लिए कोई अच्छा तरीका नहीं है इसे पहचानने के लिए कार्यक्रम।
3. छेद पंचिंग करने के लिए, आपको ऐसे पैकेट भेजने होंगे जिन्हें कोई फ़ंक्शन नहीं है। वे आम तौर पर एक एनओपी (कोई विकल्प नहीं) या KEEP_ALIVE पैकेट होते हैं जिसका कोई उद्देश्य नहीं होता है और यदि कोई प्रोग्राम प्राप्त करता है, तो यह केवल इसे छोड़ देता है।

मेरा सुझाव एक KEEP_ALIVE पैकेट को लागू करना है जो क्लाइंट प्रोग्राम अनदेखा करता है, और सर्वर को समय-समय पर फ़ायरवॉल को खोलने के लिए क्लाइंट को KEEP_ALIVE पैकेट भेजना होता है। यह मानता है कि आप क्लाइंट के आईपी को जानते हैं ताकि आप इसे KEEP_ALIVE पैकेट भेज सकें। यदि आप पहले से ही ग्राहक के आईपी को नहीं जानते हैं, तो आपको या तो सार्वजनिक रूप से सुलभ पुल कंप्यूटर स्थापित करना होगा या आपके सर्वर प्रोग्राम के लिए फ़ायरवॉल अक्षम करना होगा। विंडोज फ़ायरवॉल में एक COM API या netsh आदेश हैं जिनका उपयोग आप अपने प्रोग्राम को कनेक्शन सुनने के लिए अनुमति देने के लिए कर सकते हैं। हार्डवेयर फ़ायरवॉल/एनएटी के लिए, आप यूपीएनपी का उपयोग करने का प्रयास कर सकते हैं। यदि यह काम नहीं करता है, तो आप सबसे अच्छे से अनुरोध कर सकते हैं कि उपयोगकर्ता आपके प्रोग्राम के लिए एक विशिष्ट पोर्ट खोलता है।

Answer 3

यहां बताया गया है कि मैं इस मापा जाता netcat साथ,: या मेरे यूनिक्स मेजबान (मैक ओएस एक्स डार्विन), कोई फ़ायरवॉल (पर एक Windows मशीन जहां Windows फ़ायरवॉल netcat "nc" के लिए निष्पादन योग्य अनुमति देता है पर

WINHOST=10.116.140.69 
mkfifo f 
nc -u -p 2222 $WINHOST 6666 < f | \ 
(while read secs; do for sec in $secs; do echo sleep $sec 1>&2; sleep $sec; echo SLEPT $sec; echo SLEPT $sec 1>&2; done; done) > f 

मेरे Windows मेजबान (विंडोज 7 प्रोफेशनल SP1 64-बिट) पर, Windows फ़ायरवॉल, cygwin खोल प्रदान करने के लिए स्थापित और:) UDP पोर्ट पर सुनने, मैं चर देरी दूरस्थ क्लाइंट द्वारा आपूर्ति के साथ एक यूडीपी सर्वर चलाते नेटकैट, मैं एक यूडीपी क्लाइंट को इंटरैक्टिव रूप से चलाता हूं:

UNIXHOST=192.168.181.1 
nc -u -p 6666 $UNIXHOST 2222 

आपको साइगविन का उपयोग करने की आवश्यकता नहीं है; एक विंडोज नेटकैट ठीक काम करना चाहिए, लेकिन कमांड लाइन अलग-अलग हो सकती है।

फिर उस क्लाइंट में मैं परीक्षण अंतराल की एक श्रृंखला टाइप करता हूं, सर्वर का जवाब देने के बाद सोते हुए देखता हूं कि क्लाइंट प्रतिक्रिया प्राप्त करता है या नहीं। ये काम किया: 1, 2, 10, 60, 120, 180 के फिर इस विफल रहा है: 240 के बीच 180 और 240

उदाहरण 1 एक द्विआधारी खोज के साथ आगे बढ़ें: ग्राहक पक्ष पर, मैं टाइप करें:

10 
60 
120 
180 
240 

और 180 कार्य तक अनुरोध-प्रतिक्रिया देरी का निरीक्षण करें, 240 नहीं है।

उदाहरण 2: ग्राहक पक्ष पर, मैं टाइप करें:

180 
181 
182 
182 

और अप करने के लिए 181 कार्यों में से उस अनुरोध-प्रतिक्रिया देरी का निरीक्षण, 182 नहीं करता है।

उदाहरण 3: ग्राहक पक्ष पर, मैं टाइप (सभी एक ही लाइन पर):

180 180 180 181 181 181 182 182 182 183 183 183 

जो ग्राहक से एक UDP प्रश्न उत्पन्न करता है, तो प्रतिक्रियाओं की एक श्रृंखला, 180 के द्वारा अलग 181, 182, या 183 सेकंड अंतराल। यह देखा गया कि 181 तक की प्रतिक्रिया-प्रतिक्रिया देरी ने काम किया, और इसके अलावा, 181 सेकेंड तक अंतराल पर लगातार प्रतिक्रियाएं (नए अनुरोध किए बिना) भी काम किया।

तो फायरवॉल छेद में निष्क्रियता टाइमर होता है, चाहे प्रारंभिक प्रतिक्रिया में निष्क्रियता में देरी हो या बाद में अतिरिक्त ट्रैफ़िक में। कई मशीनों पर

परिणाम:

• कि विंडोज 7 प्रोफेशनल SP1 64-बिट डेस्कटॉप पर, यूडीपी प्रतिक्रिया छेद 181 सेकंड के लिए खुला है। यह संभव है कि मैं दो प्रणालियों के बीच नेटवर्क फ़ायरवॉल को भी माप रहा हूं, क्योंकि वे अलग-अलग नेटवर्क पर हैं - लेकिन मुझे लगता है कि उन्हें फ़ायरवॉल नहीं किया जाता है। किसी भी घटना में, विंडोज फ़ायरवॉल छेद इस प्रणाली पर कम से कम 181 सेकंड है।
• एक और विंडोज 7 व्यावसायिक एसपी 1 64-बिट लैपटॉप, एक ही नेटवर्क सेगमेंट (इसलिए निश्चित रूप से कोई हस्तक्षेप नहीं है), यूडीपी प्रतिक्रिया छेद 64 सेकंड के लिए खुला है।

मुझे अन्य ओएस स्तरों और फ़ायरवॉल कॉन्फ़िगरेशन पर अन्य विंडोज मशीनों पर समान माप देखने में दिलचस्पी होगी।