स्थानीय नेटवर्क से फॉरवर्ड पब्लिक आईपी एड्रेस को लूपबैक - हेयरपिन NAT

Question

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

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

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

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

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

Comments

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

Answer 1

जिसे आप ढूंढ रहे हैं उसे "हेयरपिन NAT" कहा जाता है। बाहरी इंटरफ़ेस को दिए गए IP पते के लिए आंतरिक इंटरफ़ेस से अनुरोधों को नैट-आउट नहीं किया जाना चाहिए, क्योंकि वे बाहरी-साइड इंटरफ़ेस से आए थे।

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

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

Comments

मैं उसी समस्या को हल करने की कोशिश करते हुए इस धागे के पार चला गया, और जब यह सच है कि FreeBSD बॉक्स के बाहर हेयरपिन नेट का समर्थन नहीं करता है, तो आंतरिक - बाहरी -> आंतरिक ट्रैफ़िक को पुनर्निर्देशित और NAT करने के तरीके हैं।

— क्रिमसन-एग्रेट

उदाहरण के लिए: 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

— लाल-सफ़ेद बगुला

Answer 2

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

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

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

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

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

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

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

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

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

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

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

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

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

Comments

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

— कास्परड

मैं मान रहा हूँ कि आप पिछले केस की बात कर रहे हैं, "उचित हेयरपिन NAT"। महत्वपूर्ण बात इनबाउंड पैकेट पर स्रोत पते को इस तरह से फिर से लिखना है कि यह राउटर पर वापस जाता है, जो तब DNAT और SNAT दोनों को उलट सकता है और इस तरह समस्या से बच सकता है। ऐसा करने के लिए राउटर का उपयोग करने वाले इसके कई पते स्वाद के अधिक बिंदु हैं, और यदि आप ऐसा कर रहे हैं iptables, तो निश्चित रूप से ऐसा कुछ है जिसे आप चुनते हैं तो आप कॉन्फ़िगर कर सकते हैं।

— मध्याह्न

कई एडमीन, खुद को शामिल करते हैं, विभाजन-क्षितिज डीएनएस को एक इलाज मानते हैं जो बीमारी से भी बदतर है। यदि एक अतिरिक्त एसएनएटी को एक बीमारी कहा जा सकता है। एक विभाजन-दृश्य DNS मनुष्यों को भ्रमित करता है जबकि यह राउटर के जीवन को आसान बनाता है। इस विषय को एक अलग सर्वरफॉल्ट प्रश्न / उत्तर द्वारा बेहतर ढंग से संभाला जाएगा।

— kubanczyk

मेरा जवाब हेयरपिन NAT के बारे में बहुत है। मैं एक विहित "स्प्लिट-क्षितिज DNS" प्रश्न को खोलने के पेशेवरों और विपक्षों को देख सकता हूं: पेशेवरों में SHDNS के उपयोगों और मुद्दों के लिए समर्पित एक प्रश्न शामिल है, लेकिन यह अभिप्राय यह है कि इस प्रश्न में पहले से ही बहुत सारे अन्य प्रश्न हैं जो संबंधित हैं यह इसमें विलीन हो गया, ताकि आपके प्रश्न के साथ भी ऐसा हो सके। अगर यह मैं होता, तो मैं इस मुद्दे को मेटा पर उठाता, और सर्वसम्मति चाहता। यदि ऐसा कोई प्रश्न लिखा जाता है, तो मैं आपके उत्तर को पढ़ने के लिए उत्सुक हूं!

— मध्याह्न

@ मैथैटर मुझे iptables कमांड कहाँ लिखना चाहिए? क्लाइंट या गेटवे या सर्वर पर?

— रॉकी बाल्बोआ

Answer 3

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

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

• ग्राहक: 192.168.1.3
• सर्वर: 192.168.1.2
• राउटर आंतरिक: 192.168.1
• राउटर बाहरी: 123.123.123.1

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

1. क्लाइंट (192.168.1.3) आपके बाहरी IP, पोर्ट 80 पर TCP-SYN भेजता है (123.123.123.1:80)
2. राउटर पोर्ट फॉरवर्डिंग रूल देखता है और पैकेट को सर्वर (192.168.1.2:80) के बिना सोर्स आईपी (192.168.1.3) में बदल देता है।
3. क्लाइंट बाहरी IP से SYN-ACK की प्रतीक्षा करता है
4. सर्वर अपना जवाब क्लाइंट को सीधे भेज देता है, क्योंकि यह उसी सबनेट पर है। यह पैकेट को राउटर में नहीं भेजता है, जो NAT को उलट देगा।
5. क्लाइंट 123.123.123.1 के बजाय 192.168.1.2 से SYN-ACK प्राप्त करता है। और इसे त्याग देता है।
6. क्लाइंट अभी भी 123.123.123.1 से SYN-ACK की प्रतीक्षा करता है और समय समाप्त होता है।

Answer 4

हर जगह आईपी एड्रेस को हार्डकोड करने के बजाय स्प्लिट क्षितिज डीएनएस का उपयोग क्यों न करें? आप बाहर पर 217.xxx की ओर इशारा करते हुए ext.yourdomain करते होंगे, और फिर 192.xxx अंदर की तरफ।

Comments

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

— क्रिस एस

Answer 5

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

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

यह स्क्रीनशॉट Rev. C मॉडल से है; तुम्हारा थोड़ा अलग हो सकता है।

Answer 6

हाल ही में इसी तरह के एक सवाल का जवाब दिया: सिस्को स्थैतिक NAT लैन की ओर से काम नहीं कर रहा है और सिर्फ एहसास हुआ कि यह एक कैनोनिकल प्रश्न है। इसलिए मुझे यहां समाधान का सारांश प्रस्तुत करने की अनुमति दें।

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

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

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

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

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

Comments

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

— माइकल

Answer 7

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

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

Comments

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

— क्रिस एस

Answer 8

तकनीकी दृष्टि से इस समस्या का सबसे अच्छा समाधान अपने नेटवर्क पर IPv6 को सक्षम करना है। जब IPv6 सक्षम होता है तो आपको अपने डोमेन के लिए AAAA रिकॉर्ड बनाने की आवश्यकता होती है। मौजूदा A रिकॉर्ड को राउटर के बाहरी IPv4 की ओर रखें । सर्वर के IPv6 पते की ओर इशारा करते हुए AAAA रिकॉर्ड बनाएं ।

IPv6 में NAT से बचने के लिए पर्याप्त पते हैं, इसलिए आपको IPv6 के लिए हेयरपिन NAT की आवश्यकता नहीं होगी। और जब आप IPv6 को सक्षम कर लेते हैं और AAAA रिकॉर्ड बनाते हैं तो RFC 8305 का समर्थन करने वाला कोई भी ग्राहक IPv6 से पहले IPv6 का प्रयास करेगा। इसका मतलब है कि आपको IPv4 के लिए हेयरपिन NAT की जरूरत नहीं है, क्योंकि क्लाइंट इसका उपयोग नहीं करेंगे।

आउटगोइंग कनेक्शन के लिए आपको अपने मौजूदा IPv4 NAT की आवश्यकता होगी और आने वाले कनेक्शन के लिए पोर्ट फॉरवर्डिंग तब तक होगी जब तक कि दुनिया के अधिकांश IPv6 सक्षम नहीं हो जाते।

यह तेज भी है।

IPv6 का उपयोग करने से आपको हेयरपिन NAT की तुलना में बेहतर प्रदर्शन मिलेगा।

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

IPv6 के साथ आप NAT से बचते हैं, इसके बजाय पैकेट को क्लाइंट और सर्वर के बीच स्विच के माध्यम से सीधे भेजा जाता है। इसका मतलब यह है कि एक राउंडट्रिप पर आप स्विच के माध्यम से पास की संख्या को 4 से घटाते हैं, और आप राउटर के माध्यम से 2 यात्राओं से बचते हैं और राउटर के 4 अनुवादों ने प्रदर्शन किया होगा। यह बेहतर प्रदर्शन के लिए अनुवाद करता है।

यह तब भी सच है जब आप राउटर के समान बॉक्स में निर्मित स्विच का उपयोग करते हैं।

क्या होगा अगर ISP के पास IPv6 नहीं है?

यदि आप एक ISP का उपयोग कर रहे हैं जो IPv6 का समर्थन नहीं करता है तो मैं सवाल करूंगा कि क्या आपको उस नेटवर्क पर सर्वर होस्ट करना चाहिए। ये मेरे सुझाव हैं कि अगर ISP IPv6 का समर्थन नहीं करता है तो क्या करना चाहिए।

पहले आईएसपी को बताएं कि आपको आईपीवी 6 की आवश्यकता है । और शायद उन्हें याद दिला दें कि IPv6 प्रोटोकॉल लगभग 20 वर्षों से है, इसलिए वे इसका समर्थन करने में लंबे समय से सफल रहे हैं। यदि यह ISP के लिए आपको गंभीरता से लेने के लिए पर्याप्त नहीं है तो अन्य ISP की तलाश शुरू करें।

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

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

सर्वर को एक होस्टिंग सुविधा में ले जाना आपके क्लाइंट को IPv6 नहीं देने वाला है, लेकिन सर्वर को स्थानांतरित करने का मतलब है कि आपको इस तक पहुँचने के लिए हेयरपिन NAT की आवश्यकता नहीं है।

आपको क्या नहीं करना चाहिए

यदि आपके पास IPv6 ट्रैफ़िक को रूट करने का कोई तरीका नहीं है, तो IPv6 चालू न करें और AAAA रिकॉर्ड बनाएं। यदि आपका ISP IPv6 का समर्थन नहीं करता है, लेकिन आप वैसे भी अपने LAN पर IPv6 को सक्षम करने का विकल्प चुनते हैं (शायद RFC 4193 पतों का उपयोग करके) और AAAA रिकॉर्ड बनाएं जो आपके LAN पर सर्वर तक पहुँचने वाले आपके LAN पर क्लाइंट्स के लिए काम करेगा। लेकिन आपके LAN और बाहरी दुनिया के बीच संचार पहले IPv6 (जो काम नहीं करेगा) की कोशिश करेगा, और आप IPv4 पर वापस गिरने पर भरोसा करेंगे जो थोड़ा धीमा है या सबसे कम नहीं होता है।

Answer 9

चूँकि मैंने यह प्रश्न भी पूछा था (देखें कि मैं एक नेटवर्क सेवा का उपयोग कैसे करता हूँ, इसके बाहरी अनुप्रयोग का उपयोग करने से अंदर से एक फ़ायरवॉल के पीछे नेटेड? ) और यहाँ पुनर्निर्देशित किया गया था, लेकिन यहाँ उत्तर एक समाधान नहीं प्रदान करते थे (जेनेरिक स्पष्टीकरण के विपरीत ) चलो मुझे 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)। इसके अलावा, IPv6 पतों को [ब्रैकेट] में रखना याद रखें जब वे पोर्ट घोषणाओं को शामिल करते हैं, जैसे [fe0a:bd52::2]:80।

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

Comments

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

— kubanczyk

Answer 10

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

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 ----------/
        +----------------------+ 

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

हमारे गेटवे बॉक्स अभी भी लैन पर मशीनों के लिए NAT ड्यूटी कर रहे हैं। क्योंकि इसमें केवल 1 ईथरनेट पोर्ट है जिसे हेयरपिन NAT करने के लिए मजबूर किया जाता है। मुझे संदेह है कि इसे यहाँ अन्य टिप्पणियों में दिए गए 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

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

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

brctl hairpin br0 eth0 on
brctl hairpin br0 wlan0 on

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

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

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

Answer 11

जैसा कि यह एक विहित प्रश्न है। अगर आपके पास सोनिकवॉल राउटर है तो मैं जवाब दूंगा।

जानने के लिए अभिव्यक्ति NAT लूपबैक नीति है

यह दस्तावेज़ बताता है कि कैसे एक SonicWall लैन पर एक होस्ट FQDN के सार्वजनिक आईपी पते का उपयोग करके SonicWall LAN पर एक सर्वर तक पहुंच सकता है। एक NSA 4500 (सोनिकओएस एनहांस्ड) नेटवर्क की कल्पना करें जिसमें प्राथमिक LAN सबनेट 10.100.0.0 / 24 है और प्राथमिक वैन आईपी 3.3.2.1 है। मान लें कि आपके पास अपने ग्राहकों के लिए एक वेब साइट है, और इसका होस्टनाम है। आपने पहले से ही आवश्यक नीतियों और नियमों को लिखा है ताकि बाहरी लोग वेब साइट पर पहुंच सकें, लेकिन यह वास्तव में एक निजी साइड सर्वर 10.1.2.2 पर चल रहा है। अब कल्पना करें कि आप 10.100.0.200 के आईपी के साथ निजी तरफ एक लैपटॉप का उपयोग करने वाले व्यक्ति हैं। आप इसके सार्वजनिक नाम का उपयोग करके सर्वर तक पहुंचना चाहते हैं, क्योंकि आप वही काम करते हैं जब आपका लैपटॉप सड़क पर आपके साथ होता है। यदि आप निजी पक्ष पर बैठते हैं, और http://www.example.com का अनुरोध करते हैं>, लूपबैक वह है जो काम करने के लिए संभव बनाता है, भले ही सर्वर वास्तव में स्थानीय आईपी पते पर आपके बगल में हो।

इस कार्यक्षमता की अनुमति देने के लिए आपको NAT लूपबैक नीति बनाने की आवश्यकता होगी, जिसे NAT प्रतिबिंब या हेयरपिन के रूप में भी जाना जाता है।

WAN इंटरफ़ेस के IP पते का उपयोग करके लूपबैक नीति

Login to the SonicWall Management GUI.
Navigate to Manage | Rules | NAT Policies submenu.
Click on the Add button.
Create the following NAT Policy.
Original Source: LAN Subnets (or Firewalled Subnets if you want hosts in other zones to be included)
Translated Source: WAN Interface IP
Original Destination: WAN Interface IP
Translated Destination: (LAN server object)
Original Service: Any
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any

Sonicwall आपके द्वारा संपर्क करने की कोशिश करने वाली बाहरी सेवा को पहचान लेगा, और सर्वर आंतरिक पते को फिट करने के लिए गंतव्य पते को फिर से लिखेगा, इस प्रकार यह कंप्यूटर के लिए पारदर्शी होगा।

Answer 12

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

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

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