सवाल लूपबैक को स्थानीय नेटवर्क से सार्वजनिक आईपी पता अग्रेषित करने के लिए - हेयरपिन एनएटी


यह है एक कैननिकल प्रश्न हेयरपिन एनएटी (लूपबैक एनएटी) के बारे में।

इस सवाल का सामान्य रूप है:

हमारे पास क्लाइंट, सर्वर और एनएटी राउटर के साथ नेटवर्क है। सर्वर पर राउटर पर बंदरगाह अग्रेषण है, इसलिए इसकी कुछ सेवाएं बाहरी रूप से उपलब्ध हैं। हमारे पास बाहरी आईपी को इंगित करने वाला DNS है। स्थानीय नेटवर्क क्लाइंट कनेक्ट करने में विफल रहते हैं, लेकिन बाहरी काम करते हैं।

  • यह क्यों विफल रहता है?
  • मैं एक एकीकृत नामकरण योजना कैसे बना सकता हूं (DNS नाम जो स्थानीय और बाहरी दोनों काम करते हैं)?

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


43
2017-08-18 15:16


मूल


यदि आपका उद्देश्य इंटरनेट से एक्सेस का परीक्षण करना है, तो राउटर के मार्गों और / या DNS सेटिंग्स के साथ किसी भी तरह से गड़बड़ करने में कोई बात नहीं है, अंदर से आप यह सत्यापित करेंगे कि राउटर के अंदरूनी भाग काम करता है। मेरा सुझाव है कि आप कहीं बाहर प्रॉक्सी सर्वर का उपयोग करें।


जवाब:


जो आप खोज रहे हैं उसे "हेयरपिन एनएटी" कहा जाता है। बाहरी इंटरफ़ेस को आवंटित आईपी पते के लिए आंतरिक इंटरफ़ेस से अनुरोधों को एनएटीएटेड किया जाना चाहिए जैसे कि वे बाहरी-पक्ष इंटरफ़ेस से आए थे।

मेरे पास कोई फ्रीबीएसडी परिचितता नहीं है, लेकिन ओपनबीएसडी के लिए "पीएफ" मैनुअल पढ़ना (http://www.openbsd.org/faq/pf/rdr.html) डीएमजेड नेटवर्क का उपयोग करते हुए स्प्लिट-क्षितिज डीएनएस के प्रस्तावित समाधान, या टीसीपी प्रॉक्सींग मुझे विश्वास करते हैं कि "पीएफ" हेयरपिन एनएटी का समर्थन नहीं करता है।

मैं विभाजन-क्षितिज DNS के मार्ग पर जा रहा हूं और आंतरिक रूप से यूआरएल में आईपी पते का उपयोग नहीं कर रहा हूं, बल्कि इसके बजाय नामों का उपयोग कर रहा हूं।


14
2017-08-18 15:30



मैं एक ही समस्या को हल करने की कोशिश करते समय इस धागे में भाग गया, और यह सच है कि फ्रीबीएसडी बॉक्स के बाहर हेयरपिन नाट का समर्थन नहीं करता है, फिर भी आंतरिक -> बाहरी -> आंतरिक यातायात को रीडायरेक्ट करने और एनएटी के तरीके हैं। - eggo
उदाहरण के लिए: no nat on $int_if proto tcp from $int_if to $int_net  , nat on $int_if proto tcp from $int_net to $hairpin_int port $hairpin_ports -> $int_if , rdr on $int_if proto tcp from $int_net to $ext_if port $hairpin_ports -> $hairpin_int - eggo


चूंकि इसे ऊंचा किया गया है हेयरपिन नेट पर कैनोलिक सवाल, मैंने सोचा कि इसका शायद एक ऐसा जवाब होना चाहिए जो वर्तमान में स्वीकृत एक से अधिक आम तौर पर मान्य हो, जो (हालांकि उत्कृष्ट) विशेष रूप से फ्रीबीएसडी से संबंधित है।

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

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

इस प्रकार ग्राहक एक पैकेट भेजता है बाहरी आईपी ​​पता, लेकिन एक से जवाब मिलता है अंदर का आईपी ​​पता। यह नहीं पता कि दो पैकेट एक ही वार्तालाप का हिस्सा हैं, इसलिए कोई वार्तालाप नहीं होता है।

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

ग्राहक सोचता है कि यह बाहरी सर्वर से बात कर रहा है। सर्वर सोचता है कि यह गेटवे डिवाइस से बात कर रहा है। सभी पार्टियां खुश हैं। इस बिंदु पर एक आरेख उपयोगी हो सकता है:

enter image description here

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

उचित नेटवर्किंग उपकरणों को आम तौर पर काम करने के लिए कहा जा सकता है, लेकिन - क्योंकि वे अपने व्यवस्थापक के दूसरे अनुमान लगाने के कारोबार में नहीं हैं - उन्हें ऐसा करने के लिए कहा जाना चाहिए। लिनक्स का उपयोग करता है iptables इस प्रकार डीएनएटी करने के लिए:

iptables -t nat -A PREROUTING  -p tcp --dport 80 -j DNAT --to-destination 192.168.3.11

जो HTTP पोर्ट के लिए एक आंतरिक सर्वर पर सरल डीएनएटी सक्षम करेगा 192.168.3.11। लेकिन हेयरपिन एनएटी को सक्षम करने के लिए, किसी को भी एक नियम की आवश्यकता होगी जैसे कि:

iptables -t nat -A POSTROUTING -d 192.168.3.11 -p tcp --dport 80 -j MASQUERADE

ध्यान दें कि सही तरीके से काम करने के लिए, और सेटिंग्स में निर्भर करने के लिए ऐसे नियमों को प्रासंगिक श्रृंखलाओं में सही जगह पर होना चाहिए filter श्रृंखला, नाट किए गए यातायात को प्रवाह करने की अनुमति देने के लिए अतिरिक्त नियमों की आवश्यकता हो सकती है। ऐसी सभी चर्चाएं इस उत्तर के दायरे से बाहर हैं।

लेकिन जैसा कि अन्य ने कहा है, बालों को ठीक करने में सक्षम एनएटी समस्या को संभालने का सबसे अच्छा तरीका नहीं है। सबसे अच्छा है विभाजित क्षितिज डीएनएस, जहां आपका संगठन मूल लुकअप के लिए अलग-अलग उत्तरों की सेवा करता है, इस पर निर्भर करता है कि अनुरोधक क्लाइंट कहां है, या तो आंतरिक बनाम बाहरी उपयोगकर्ताओं के लिए अलग-अलग भौतिक सर्वर, या अनुरोध करने वाले क्लाइंट के पते के अनुसार अलग-अलग प्रतिक्रिया देने के लिए DNS सर्वर को कॉन्फ़िगर करके।


46
2017-11-27 12:20



मैं गेटवे और सर्वर के बीच आदान-प्रदान किए गए पैकेट पर पते के बारे में कुछ सोच रहा हूं। यदि सर्वर ने क्लाइंट आईपी के रूप में राउटर के सार्वजनिक आईपी पते को देखा तो क्या यह अधिक सुसंगत नहीं होगा? तकनीकी रूप से दोनों काम कर सकते हैं, लेकिन अन्य सर्वरों को कैसे देखते हैं, इसके साथ लगातार बने रहने के लिए, इसे सार्वजनिक आईपी का उपयोग करना होगा। - kasperd
मैं मान रहा हूं कि आप अंतिम मामले, "उचित हेयरपिन एनएटी" का जिक्र कर रहे हैं। महत्वपूर्ण बात यह है कि इनबाउंड पैकेट पर स्रोत पते को फिर से लिखना इस तरह से है कि यह राउटर पर वापस जाता है, जो तब डीएनएटी और एसएनएटी दोनों को उलट सकता है और इस प्रकार समस्या से बच सकता है। ऐसा करने के लिए राउटर का उपयोग करने वाले इसके कई पते में से कौन सा स्वाद का एक बिंदु है, और यदि आप इसे कर रहे हैं iptables, निश्चित रूप से कुछ है जिसे आप कॉन्फ़िगर कर सकते हैं यदि आप चुनते हैं। - MadHatter
कई व्यवस्थापक, स्वयं शामिल हैं, विभाजित क्षितिज डीएनएस पर एक इलाज है जो बीमारी से भी बदतर है। यदि एक अतिरिक्त एसएनएटी को बीमारी कहा जा सकता है। एक स्प्लिट-व्यू DNS इंसानों को भ्रमित करता है जबकि यह राउटर के जीवन को आसान बनाता है। इस विषय को एक अलग सर्वरफॉल्ट प्रश्न / उत्तर द्वारा बेहतर तरीके से संभाला जाएगा। - kubanczyk
मेरा जवाब हेयरपिन एनएटी के बारे में बहुत कुछ है। मैं एक कैनोनिकल "स्प्लिट-क्षितिज डीएनएस" प्रश्न खोलने के पेशेवरों और विपक्ष को देख सकता हूं: पेशेवरों में एसएचडीएनएस के उपयोग और मुद्दों के लिए समर्पित एक प्रश्न शामिल है, लेकिन विपक्ष यह है कि इस प्रश्न में पहले से ही बहुत से अन्य प्रश्न हैं जो संबंधित हैं यह इसमें विलय हो गया, ताकि आपके प्रश्न के साथ भी हो। अगर यह मैं था, तो मैं मेटा पर मुद्दा उठाऊंगा, और सर्वसम्मति की तलाश करूंगा। यदि ऐसा कोई प्रश्न लिखा गया है, तो मैं आपके उत्तर को पढ़ने के लिए तत्पर हूं! - MadHatter
@MadHatter मुझे iptables कमांड कहां लिखना चाहिए? ग्राहक या गेटवे या सर्वर पर? - Rock Balbao


यहां समस्या यह है कि आपका राउटर आपके आंतरिक ग्राहक का पता नहीं लगाता है। इस प्रकार, टीसीपी हैंडशेक विफल रहता है।

आइए निम्नलिखित आईपी मान लें

  • ग्राहक: 1 9 .168.1.3
  • सर्वर: 1 9 2.168.1.2
  • राउटर आंतरिक: 1 9 2.168.1
  • राउटर बाहरी: 123.123.123.1

यहां क्या हो रहा है:

  1. क्लाइंट (1 9 2.168.1.3) आपके बाहरी आईपी, पोर्ट 80 (123.123.123.1:80) में टीसीपी-एसईएन भेजता है
  2. राउटर बंदरगाह अग्रेषण नियम देखता है और बाद में पैकेट को सर्वर (1 9 2.168.1.2:80) स्रोत स्रोत को बदलने के बिना (1 9 2.168.1.3)
  3. क्लाइंट बाहरी आईपी से एक एसईएन-एसीके के लिए इंतजार कर रहा है
  4. सर्वर सीधे अपने उत्तर क्लाइंट को भेजता है, क्योंकि यह एक ही सबनेट पर है। यह राउटर को पैकेट नहीं भेजता है, जो एनएटी को उलट देगा।
  5. ग्राहक 123.123.123.1 के बजाय 1 9 2.168.1.2 से एक SYN-ACK प्राप्त करता है। और इसे छोड़ देता है।
  6. ग्राहक अभी भी 123.123.123.1 से एक एसईएन-एसीके के लिए इंतजार कर रहा है और समय समाप्त हो गया है।

8
2017-10-10 11:32





हार्डकोडिंग आईपी पते के बजाय हर जगह विभाजित क्षितिज डीएनएस का उपयोग क्यों न करें? आप ext.yourdomain बाहर पर 217.x.x.x की ओर इशारा करते हैं, और उसके बाद 192.x.x.x को इंगित करते हैं।


4
2017-08-20 08:42



यदि आपके पास कोई पल है, तो क्या आप स्प्लिट-होरिजन डीएनएस, यह कैसे काम करता है, और बड़ी कमी के बारे में विस्तार कर सकते हैं। यह अब एक कैननिकल सवाल है और यह एक और पूर्ण जवाब होना अच्छा लगेगा। - Chris S


हाल ही में एक समान प्रश्न का उत्तर दिया: सिस्को स्थिर एनएटी लैन पक्ष पर काम नहीं कर रहा है और सिर्फ एहसास हुआ कि यह एक कैनोनिकल प्रश्न है। तो मुझे यहां समाधान का सारांश देने की अनुमति दें।

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

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

(2) लैन होस्ट पर: सार्वजनिक आईपी पते के लिए एक होस्ट रूट जोड़ें, उदाहरण के लिए, विंडोज होस्ट के लिए निम्न आदेश का उपयोग करें: मार्ग -पी 203.0.113.130 मास्क 255.255.255.255 192.168.1.11 जोड़ें (आप रूट वितरित करने के लिए डीएचसीपी "स्थिर मार्ग" विकल्प का भी उपयोग कर सकते हैं)। या, यदि क्लाइंट और इंटरनेट-फेस राउटर के बीच (ए) एल 3 स्विच (एसएस) / राउटर (एस) है, तो इस (इन) इंटरमीडिएट स्विच (एसएस) / राउटर पर होस्ट होस्ट को कॉन्फ़िगर करें, नहीं ग्राहकों पर

टीसीपी तीन-तरफा हैंडशेक से संबंधित लोगों के लिए: यह प्रस्तावित कॉन्फ़िगरेशन में ठीक काम करेगा।

कृपया प्रतिक्रिया दें (कम से कम, वोट)।


2
2017-11-03 11:14



आवश्यकता # 2 यह BYOD नेटवर्क पर अच्छी तरह से काम नहीं करता है ... - Michael


मैं इसी तरह की समस्याओं वाले लोगों के लिए क्षितिज को विस्तारित करने के लिए अपने प्रश्नों का उत्तर देता हूं।

मैं अपने आईएसपी से संपर्क कर रहा हूं और उनसे मेरी समस्याओं को हल करने के लिए कहा। उन्होंने मुझे जो पेशकश की थी वह सिर्फ सर्वर के लिए एक और सार्वजनिक आईपी पता है, अब मेरे पास फ्रीबीएसडी के वैन पक्ष पर स्थानीय यातायात है और हमने विशिष्ट पाइप बनाये हैं सर्वर के सार्वजनिक आईपी के लिए तेजी से थ्रूपुट स्थानीय स्थानीय यातायात


1
2017-08-20 08:37



यह समाधान एक लागू करता है परिधि नेटवर्क या डीएमजेड और हेअरपिन एनएटी और स्प्लिट-होरिजन डीएनएस दोनों के लिए एक अच्छा विकल्प है। - Chris S


यदि यह मूल डी-लिंक राउटर है (यानी, वर्जिन मीडिया से रेव डी / फर्मवेयर संस्करण 1.00 वीजी नहीं), तो आप इसके आसपास काम करने के लिए सेटिंग्स को समायोजित करने में सक्षम होना चाहिए। (हालांकि, मैं कई अन्य कारणों से डीडी-डब्लूआरटी के पिछले पोस्टर के सुझाव से सहमत हूं!)

  1. राउटर के वेब इंटरफ़ेस में लॉग इन करें
  2. शीर्ष पर उन्नत टैब पर क्लिक करें
  3. बाईं ओर फ़ायरवॉल सेटिंग्स टैब पर क्लिक करें
  4. दबाएं एंडपॉइंट स्वतंत्र रेडियो बटन के तहत टीसीपी एंडपॉइंट फ़िल्टरिंगजैसा कि नीचे स्क्रीनशॉट में दिखाया गया है (या देखें राउटर एमुलेटर डी-लिंक की वेबसाइट पर)
  5. परिवर्तनों को सुरक्षित करें; हो गया

D-Link router web UI screenshot

यह स्क्रीनशॉट रेव सी मॉडल से है; आपका थोड़ा अलग हो सकता है।


1
2018-03-11 02:37





चूंकि मैंने यह प्रश्न भी पूछा (देखें मैं अपने बाहरी आईपी का उपयोग करके अंदर से फ़ायरवॉल के पीछे नेटवर्क सेवा को कैसे एक्सेस करूं?) और यहां पुनर्निर्देशित किया गया था लेकिन यहां दिए गए उत्तरों ने एक प्रदान नहीं किया था उपाय (जेनेरिक के विपरीत स्पष्टीकरण) मुझे अपना लिनक्स प्रदान करने दें (iptables विशिष्ट) सभी को प्रयोग के कुछ घंटों को बचाने के लिए यहां समाधान। यह फ़ाइल में है iptables-restore प्रारूप और सीधे iptables में पढ़ा जा सकता है (पाठ्यक्रम के आईपी पते संपादित करने के बाद)। यह एक वेब सर्वर (पोर्ट 80) के लिए है और केवल आईपीवी 4 के लिए है - आईपीवी 6 के लिए नियम और एसएसएल (पोर्ट 443) के लिए समान हैं।


# Port forwarding for VM / Container access with „hairpin NAT“.
*nat
:PREROUTING ACCEPT [3:205]
:INPUT ACCEPT [59:670]
:OUTPUT ACCEPT [16:172]
:POSTROUTING ACCEPT [20:257]

# This was simple port forwarding - access works from outside but not from inside
#-A PREROUTING  -4 -p tcp -i eth0 --dport 80 -j DNAT --to web.local:80

# This is real hairpin NAT which allows „web.local“ to access itself via the VM hosts external IP.
# First we need to masquerade any traffic going out the external interface:
-A POSTROUTING -o eth0 -j MASQUERADE

# Then we need to reroute incoming traffic on the public IP to the local IP:
-A PREROUTING  -4 -p tcp -d web.public.com --dport  80 -j DNAT --to web.local:80

# And finally we need to tell the router that the source IP of any traffic
# coming from the LAN must be source-rewritten when going to the web server:
-A POSTROUTING -4 -p tcp -s lan.local/24 -d web.local --dport  80 -j SNAT --to-source web.public.com:80

COMMIT

बदलने के lan.local , web.local तथा web.public.com आपके स्थानीय नेटवर्क (उदाहरण के लिए 10.0.x.0 / 24), आपके वेबसर्वर का स्थानीय आईपी (उदा। 10.0.1.2), और आपके राउटर का सार्वजनिक आईपी (उदाहरण के लिए 4.5.6.7)। -4 सिर्फ उसी फ़ाइल में आईपीवी 6 और आईपीवी 4 नियमों की अनुमति देने के लिए है (ऐसी लाइनें अनदेखा करती हैं ip6tables)। साथ ही, आईपीवी 6 पते को [ब्रैकेट्स] में रखना याद रखें जब वे पोर्ट घोषणाएं शामिल करते हैं, उदा। [fe0a:bd52::2]:80

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


0
2018-03-24 06:02



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


मैं यहां एक उत्तर जोड़ूंगा क्योंकि यहां टिप्पणियों ने मेरी विशेष समस्या का समाधान नहीं किया है। मुझे संदेह है कि ऐसा इसलिए है क्योंकि मैंने एक बुरा लिनक्स कर्नेल बग मारा। सेटअप है:

internet <--> modem 1.1.1.1/30 <--> switch <---> LAN 10.1.1.0/24
                                      ^
        +----------------------+      |
        |              /--eth0 o <----/
        |              |       |           
        | 10.1.1.1/24 br0      |           v (antenna)
        |  1.1.1.2/30  |       |           |
        |              \-wlan0 o ----------/
        +----------------------+ 

जटिल दिखने वाली तस्वीर के बावजूद अन्य टिप्पणियों में शामिल स्थितियों में एकमात्र प्रासंगिक परिवर्तन सॉफ्टवेयर पुल, बीआर 0 के अतिरिक्त है। यह वहां है क्योंकि गेटवे बॉक्स भी लैन के लिए वायरलेस एक्सेस पॉइंट है।

हमारा गेटवे बॉक्स अभी भी लैन पर मशीनों के लिए एनएटी कर्तव्यों का प्रदर्शन कर रहा है। क्योंकि इसमें केवल 1 ईथरनेट बंदरगाह है, इसे हेयरपिन एनएटी करने के लिए मजबूर होना पड़ता है। मुझे संदेह है कि इसे सिर्फ अन्य टिप्पणियों में दिए गए iptables नियमों के साथ काम करना चाहिए, लेकिन कम से कम लिनक्स कर्नेल 4.9 पर यह नहीं है। 4.9 के तहत हमारा गेटवे बॉक्स इंटरनेट तक पहुंच सकता है, लैन पर मशीनें एनएटी के माध्यम से इसे एक्सेस करने का प्रयास नहीं कर सकती हैं।

tcpdump eth0 पर आने वाले आने वाले पैकेट के जवाब दिखाता है, लेकिन वे इसे br0 से बाहर नहीं बनाते हैं। इस कमांड को चलाने से यह पता चलता है कि:

ebtables -t brouter -A BROUTING -d 01:00:00:00:00:00/01:00:00:00:00:00 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-dst 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-src 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 -j DROP

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

आप इसका उपयोग कर समस्या को ठीक करने के लिए प्रेरित हो सकते हैं:

brctl hairpin br0 eth0 on
brctl hairpin br0 wlan0 on

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

  1. गेटवे तक लैन में पिंग टाइम्स लगभग 10 सेकंड अंतराल पर दोगुना हो गया, 0.1ms से ऊपर, 0.2ms, 0.4ms, 0.8ms, 2ms और तब तक जब तक गेटवे बॉक्स लैन से पहुंच योग्य नहीं था। यह एक पैकेट तूफान की तरह पिघल गया, लेकिन एसटीपी हर जगह स्विच किया गया था।
  2. सभी वायरलेस एक्सेस पॉइंट्स की मृत्यु के कुछ देर बाद नहीं।
  3. वायरलेस के साथ क्या हो रहा था इसका निदान करने का प्रयास करते समय, सभी आईपी फोन रिबूट किए गए।
  4. उसके बाद लंबे समय तक, वायर्ड मशीनों ने लैन के साथ सभी संपर्क खो दिए।

इमारत में हर मशीन को रीबूट करना एकमात्र तरीका था। एक अपवाद हार्डवेयर स्विच था, जिसे रीबूट नहीं किया जा सका। उन्हें बिजली चक्रवात होना था।


0
2018-06-22 05:45





पीएफ का उपयोग कर फ्रीबीएसडी में यह आसान है (आपके pf.conf फ़ाइल में):

extif = "tun0"
intif = "em0"
{other rules}...
nat on $intif from any to 192.168.20.8 port 80 -> ($extif)

1 9 2.168.20.8 आंतरिक वेब सर्वर होगा।


-2
2018-06-25 04:20