NAT हेयरपिन की अनुमति देने के लिए अधिक संगठन अंदर-अंदर NAT या इसी तरह के समाधान का उपयोग क्यों नहीं करते हैं?


22

आंतरिक इंटरफ़ेस पर कंप्यूटर से एएसए या इसी तरह के डिवाइस के बाहरी सर्वर पर एक वेब सर्वर तक पहुंचने पर NAT के अंदर-अंदर NAT नैट लूपबैक हेयरपिन NAT मुद्दों को हल करता है। यह DNS व्यवस्थापक को डुप्लिकेट आंतरिक DNS ज़ोन को बनाए रखने से रोकता है जिनके पास अपने सर्वर के लिए संबंधित RFC1918 पते हैं जो सार्वजनिक पते पर NATED हैं। मैं एक नेटवर्क इंजीनियर नहीं हूं, इसलिए मुझे कुछ याद आ रहा है, लेकिन यह कॉन्फ़िगर करने और लागू करने के लिए एक नो-ब्रेनर की तरह लगता है। असममित मार्ग एक मुद्दा हो सकता है लेकिन आसानी से कम हो जाता है।

मेरे अनुभव में, नेटवर्क व्यवस्थापक / इंजीनियर पसंद करते हैं कि सिस्टम के लोग एनएटी हेयरपिन को ठीक से संभालने के लिए अपने फायरवॉल को कॉन्फ़िगर करने के बजाय केवल विभाजन-डीएनएस चलाते हैं। ऐसा क्यों है?


शायद इसलिए कि DNS दृश्य समस्या निवारण के लिए आसान हैं?
निकडब्ल्यू

2
संभवतः, लेकिन AD डोमेन नियंत्रकों (एक सामान्य परिदृश्य) पर DNS का उपयोग करते समय दृश्य मौजूद नहीं हैं।
एमडीमैरा

2
आपको अपने AD क्षेत्र को इंटरनेट पर प्रकाशित करने की आवश्यकता क्यों होगी? यदि आपका AD ad.example.comया समान है (जैसा होना चाहिए!), तो यह समस्या सभी सार्वजनिक example.comDNS प्रविष्टियों के लिए मौजूद होगी और आंतरिक रूप से कुछ भी प्रकाशित नहीं किया जाता है। बेशक, यदि आपने अपने AD को अपनी सार्वजनिक उपस्थिति के रूप में नामित किया है, तो आपको विभाजन-DNS का उपयोग करना होगा , लेकिन यह एक सर्वोत्तम अभ्यास AD डिज़ाइन नहीं है।
एमडीमैरा

5
यदि ग्राहक उनके बीच कभी नहीं जाते हैं तो मैं यह जोड़ना चाहूंगा कि DNS दृश्य केवल समस्या निवारण के लिए आसान हैं । जब ग्राहक बाहरी रूप से कैश्ड आंतरिक परिणाम लेते हैं तो चीजें अजीब तरह से गलत हो सकती हैं।
लैपटॉप 006

3
ग्राहकों को DNS उत्तरों को कैश नहीं करना चाहिए, यही DNS सर्वरों के लिए है। मुझे पता है कि विंडोज़ चुप (और घातक) कैशिंग का बहुत शौकीन है, लेकिन यह कई कारणों में से एक है, जो मुझे लगता है कि यह उत्पादन के उपयोग के लिए अयोग्य है।
MadHatter मोनिका

जवाबों:


11

कुछ कारण हैं कि मैं ऐसा क्यों नहीं करूंगा:

  • अगर आपको ज़रूरत नहीं है तो DMZ राउटर और फ़ायरवॉल पर अतिरिक्त दबाव क्यों डालें? हमारी अधिकांश आंतरिक सेवाएँ DMZ में नहीं, बल्कि सामान्य कॉर्पोरेट क्षेत्र में हैं, कभी-कभार दूरस्थ पहुँच के लिए DMZ में सेवाओं के साथ। अंदर-अंदर नट को करने से DMZ में अधिक भार जुड़ जाता है, जो हमारे मामले में महत्वपूर्ण होगा।
  • यदि आप DNAT + SNAT नहीं करते हैं, तो आपको असममित रूटिंग मिलेगी, जो कि सही पाने के लिए कुख्यात है। तो आप SNAT और स्रोत IP infomation खो देते हैं। हालांकि, समस्या निवारण उद्देश्यों के लिए लोगों को स्रोत आईपी लिंक करने के लिए यह उपयोगी है। या कभी-कभी मूर्खता के मामलों में उद्देश्यों की पूर्ति करना। "अरे यह आईपी अनधिकृत सेवा X पर कुछ शानदार कर रहा है" "ओह, आइए देखते हैं कि कौन सी इमैप सर्वर लॉग्स में है"।

2
बस एक नोट, अगर आपका फ़ायरवॉल L3 रूटिंग कर रहा है और आपके पास आपके बाहरी और आंतरिक ग्राहकों के लिए आपके मार्ग फ़ायरवॉल पर हैं, तो आपको असममित रूटिंग के बारे में चिंता नहीं करनी चाहिए, है ना?
एमडीमैरा

12

जाहिर है, इसके लिए निश्चित उत्तर नहीं हो सकता है , लेकिन मैं कई कारणों से सोच सकता हूं:

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

1
1. इस स्थिति में NAT का उपयोग वैसे भी किया जा रहा है। यह NAT नहीं जोड़ रहा है जहाँ पहले NAT नहीं था। 2. मेरे उदाहरण में, वे सभी एक ही उपकरण या उपकरणों के समूह द्वारा नियंत्रित किए जाते हैं। 4. जैसा कि ऊपर मेरी टिप्पणी में कहा गया है, एक बहुत ही सामान्य परिदृश्य आंतरिक रूप से DNS के लिए AD डोमेन नियंत्रकों का उपयोग कर रहा है। विंडोज डीएनएस विचारों का समर्थन नहीं करता है। इसके अलावा, मैंने पाया है कि कुछ हद तक आधुनिक राउटर / फ़ायरवॉल फ़र्मवेयर NAT हेयरपिनिंग को एक या दूसरे तरीके से सपोर्ट करते हैं।
एमडीमैरा

1
@MDMarra कुछ टिप्पणी करता है: 1. - "देखभाल करने के लिए कम से कम एक NAT अजीब बात होगी" जिसका मैं मूल रूप से मतलब है, 2. - आपका प्रश्न स्पष्ट रूप से ऐसा नहीं कहता है, लेकिन सिर्फ एक राउटर के साथ यह स्पष्ट रूप से संभालना आसान होगा , 4. आंतरिक डीएनएस के साथ जो सभी ग्राहकों के लिए अनिवार्य है, आपको विचारों की आवश्यकता नहीं है - आप बस एक आंतरिक क्षेत्र बनाएंगे और जैसा कि आपने अपने प्रश्न में उल्लेख किया है, वैसा ही प्रभाव प्राप्त करेंगे, जो अभी भी लागू होने से ऊपर है।
वाबेट

1
क्या NAT अजीब है, हालांकि? यह कौन सा विशिष्ट व्यवहार पेश करेगा जो समस्याओं का कारण बनता है? मैंने ऐसे विश्वविद्यालय में काम किया, जिसमें नेट बाल कटाने को 100+ बाहरी मेजबानों के लिए नेटस्क्रीन क्लस्टर पर कॉन्फ़िगर किया गया था और हमें कभी कोई समस्या नहीं हुई।
एमडीमैरा

यह भी ध्यान रखें कि इस परिदृश्य में बाल के लिये कांटा नेट का उपयोग कर वास्तव में यह देखने के लिए कर रही है और अधिक आईपीवी 6 समाधान की तरह है, क्योंकि आईपीवी 6 के तहत प्रणाली एक विश्व स्तर पर पहुंचा जा सकता-पता होगा; हेयरपिन NAT उस व्यवहार का अनुकरण करता है।
पॉल गियर

@MDMarra "हेयरपिन NAT" मामले के लिए सबसे उत्कृष्ट "NAT विचित्रता" गैर-इष्टतम रूटिंग पथ होगा, जिसका अर्थ है कि फिर से लिखे गए पैकेटों के माध्यम से वे जिस रास्ते से वापस आते हैं, उसमें से अधिकांश को यात्रा करना होगा। एक पैकेट डंप में यह देखना जब कनेक्टिविटी का समस्या निवारण सबसे अच्छा है। मेरा मानना ​​है कि दूसरों ने पहले से ही अपने जवाबों में असममित रूटिंग मुद्दे का उल्लेख किया है, जो संबंधित है। इसमें कोई शक नहीं है कि आप इसे ठीक काम कर सकते हैं। लेकिन यह आईएमओ के अधिकांश मामलों में प्रयास के लायक नहीं है।
वबबिट

7

डिस्क्लेमर - यह एक फ्लेमबैट उत्तर है।

एक सामान्य कारण मुझे लगता है कि इस तरह के समाधानों से बचा जाता है नेटवर्क इंजीनियरों की ओर से NAT का एक तर्कहीन भय / घृणा है । यदि आप इस पर चर्चा के कुछ उदाहरण देखना चाहते हैं, तो इन्हें देखें:

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

वहाँ तुम जाओ - अपने दिल की सामग्री के लिए downvote! :-)


1
मुझे नहीं पता कि मैं इसे एक अतार्किक डर मानूंगा। अनुभव ने मुझे सिखाया है कि NAT बहुत सारे सामानों के साथ अजीब चीजें तोड़ या कर सकता है।

1
@ यदि आप पहले से ही अपने बाहरी इंटरफ़ेस पर NAT का उपयोग कर रहे हैं, तो NAT पाशबैक को कॉन्फ़िगर करने से क्या अंतर पड़ता है?
एमडीमैरा

@ मम्मरा - वास्तव में कोई नहीं। मैं नहीं बल्कि पांडित्यपूर्ण बिंदु बना रहा था कि कभी-कभी नेट के लिए नेटवर्क सेवाओं की टीम का डर तर्कहीन नहीं होता है।

मुझे NAT से डर नहीं लगता, मुझे इससे नफरत है।
माइकल हैम्पटन

1
नफरत को शामिल करने के लिए संपादित पोस्ट। :-)
पॉल गियर २

3

मेरा अनुमान है:

  1. स्प्लिट डीएनएस को आसानी से समझा जाता है।
  2. एनएटी हेयरपिन राउटर पर संसाधनों का उपयोग करता है जबकि विभाजन-डीएनएस नहीं करता है।
  3. राउटर में बैंडविड्थ सीमाएं हो सकती हैं जो आपको विभाजन-डीएनएस सेटअप के माध्यम से नहीं मिलती हैं।
  4. स्प्लिट-डीएनएस हमेशा बेहतर प्रदर्शन होगा क्योंकि आप रूटिंग / एनएटी चरणों से बचते हैं।

हेयरपिन NAT के लिए प्लस साइड पर,

  • एक बार सेटअप होने के बाद यह काम करता है।
  • काम के नेटवर्क और सार्वजनिक इंटरनेट के बीच चले गए लैपटॉप के लिए DNS कैश के साथ कोई समस्या नहीं है।
  • एक सर्वर के लिए DNS केवल एक ही स्थान पर प्रबंधित होता है।

आंतरिक सर्वर पर कम ट्रैफ़िक आवश्यकताओं वाले छोटे नेटवर्क के लिए मैं हेयरपिन NAT के साथ जाऊंगा। सर्वर के लिए कई कनेक्शन के साथ एक बड़ा नेटवर्क और जहां बैंडविड्थ और विलंबता महत्वपूर्ण है, विभाजन-डीएनएस के साथ जाएं।


2

मेरे दृष्टिकोण से, यह सिस्को पिक्स के बीच एएसए संक्रमण के बीच थोड़ा बदल गया। aliasआज्ञा खो दी । और सामान्य तौर पर, सिस्को फ़ायरवॉल पर अंदर के इंटरफ़ेस से बाहरी पते तक पहुंचने के लिए किसी प्रकार की चालबाजी की आवश्यकता होती है। देखें: मैं बाहरी आईपी पर अपने आंतरिक सर्वर तक कैसे पहुंच सकता हूं?

हालांकि, हमें हमेशा डुप्लिकेट आंतरिक DNS ज़ोन को बनाए रखने की आवश्यकता नहीं होती है। सिस्को एएसए एनएटी बयान पर कॉन्फ़िगर किए जाने पर बाहरी पते के लिए डीएनएस प्रश्नों को पुनर्निर्देशित कर सकता है। लेकिन मैं सार्वजनिक DNS ज़ोन के लिए एक आंतरिक क्षेत्र रखना पसंद करता हूं ताकि उस दानेदारता हो और फ़ायरवॉल के लिए कदम के बजाय इसे एक जगह पर प्रबंधित करने में सक्षम हो।

आमतौर पर, केवल कुछ सर्वर होते हैं जिनके लिए पर्यावरण (मेल, वेब, कुछ सार्वजनिक सेवाओं) में इसकी आवश्यकता हो सकती है, इसलिए यह एक जबरदस्त समस्या नहीं है।


अगर यह सिस्को द्वारा समर्थित और प्रलेखित है, तो क्या यह चालाकी है ? यकीन है कि यह थोड़ा अधिक काम है, लेकिन क्या यह मुश्किल या हैक करने योग्य है?
एमडीमैरा

छल, जिसमें लोग पहले से ही अवगत नहीं हैं, अगर वे इसके बारे में नहीं जानते / अपेक्षा / विचार करते हैं। यह एक सामान्य प्रश्न है: मैं अपने सिस्को फ़ायरवॉल के अंदर से एक बाहरी आईपी तक कैसे पहुंच सकता हूं
ewwhite

Typically, there are only a few servers that may require this within an environmentशायद कुछ जगहों पर, लेकिन मैंने एक DMZ में 100+ सर्वर / उपकरणों के साथ एक विश्वविद्यालय में काम किया और मैंने तीन DMZ में फैले 40+ सर्वर के साथ एक परीक्षण / प्रमाणन प्रदाता पर भी काम किया। छोटी कंपनियों के लिए आपके पास केवल एक या दो सर्वर बाहर के संपर्क में हो सकते हैं, लेकिन जरूरी नहीं कि यह सभी के लिए हो।
एमडीमैरा

यदि सर्वर एक DMZ में हैं, तो यह एक समस्या से कम है, है ना?
ewwhite

इस उदाहरण में "डीएमजेड" का अर्थ है कि जगह के बीच जोनों के बीच डिफ़ॉल्ट इनकार नियमों के साथ उक्त फ़ायरवॉल का बाहरी अनुमान।
एमडीमैरा

2

मैं कुछ कारणों के बारे में सोच सकता हूं:

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

0

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

मैं NAT लूपबैक सेटअप करूँगा, DMZ स्विच में प्लग करूँगा और स्पूफ आंतरिक स्रोत पते के साथ पैकेट भेजूँगा। सर्वर लॉग की जांच करें कि क्या उन्हें प्राप्त हुआ था। तब मैं कॉफ़ी शॉप जाता और देखता कि क्या मेरा आईएसपी ख़राब पते को रोक रहा है। अगर मुझे पता चला कि मेरा NAT राउटर सोर्स इंटरफेस की जाँच नहीं कर रहा है, तो शायद मैं अपने ISP की जाँच कर रहा हूँ, भले ही NAT लूपबैक का उपयोग न करूँ।


क्षमा करें, मैं गलत समझ सकता हूं कि आप क्या कह रहे हैं, लेकिन RFC1918 पतों को इंटरनेट पर रूट नहीं किया गया है, इसलिए मैं नहीं देखता कि WAN भर में उन्हें बिगाड़ने की कोशिश क्या हो रही है। वे भी पहली उम्मीद नहीं करेंगे।
एमडीएमरा

गंतव्य पता सर्वर पर मैप की गई पोर्ट पर NAT का सार्वजनिक पता है। स्रोत पता NAT के अंदर निजी IP पते में से एक है। स्रोत पते राउटिंग में उपयोग नहीं किए जाते हैं और प्रत्येक सार्वजनिक राउटर द्वारा चेक नहीं किए जाते हैं। एक वैध आंतरिक क्वेरी से केवल अंतर यह है कि पैकेट WAN से आ रहा है।
केंट इंग्लैंड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.