एक ही सार्वजनिक आईपी पते का उपयोग करके NAT के पीछे कई सर्वरों को उजागर करना

Question

यह NAT और DNS के बारे में एक कैननिकल प्रश्न है

मैं वर्तमान में एक डीएमजेड के साथ एक नेटवर्क स्थापित करने की कोशिश कर रहा हूं जिसमें एक वेब सर्वर और एक ई-मेल सर्वर है जो इंटरनेट से अलग एक नेटवर्क पते से अनुवाद कर रहा है (एनएटी) फ़ायरवॉल।

मैंने निम्नलिखित इंटरफेस के साथ NAT फ़ायरवॉल स्थापित किया है:

WAN - x.x.x.x (redacted public IP address)
DMZ - 192.168.124.5/24
LAN - 192.168.123.5/24

मेरे DMZ पर मेरे दो मेजबान हैं:

Web server - 192.168.124.30
E-mail server - 192.168.124.32

मुझे पता है कि मैं के लिए DNS कॉन्फ़िगर करना होगा example.comसंकल्प दोनों के लिए डोमेन example.comऔर mail.example.comमेरी सार्वजनिक आईपी पते को।

मैं अपने NAT फ़ायरवॉल को example.com192.168.124.30 पर वेब सर्वर पर आने वाले सभी अनुरोधों को और 192.168.124.32 पर mail.example.comई-मेल सर्वर को आने वाले सभी अनुरोधों को अग्रेषित करना चाहूंगा । मुझे अपने NAT फ़ायरवॉल कॉन्फ़िगरेशन में "पोर्ट फ़ॉरवर्डिंग" फ़ीचर दिखाई दे रहा है, लेकिन मैं जो चाह रहा हूँ उसे प्राप्त नहीं कर सकता।

Comments

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

— इवान एंडरसन

Answer 1

आप विशेष रूप से DNS और एप्लिकेशन लेयर प्रोटोकॉल के बीच TCP / IP प्रोटोकॉल स्टैक की परतों के बीच कैसे प्रवाहित होते हैं, इस बारे में आपकी सोच में गड़बड़ हो रही है।

आपके पास एक सार्वजनिक IP पता है। आपके DNS निश्चित रूप से दोनों हल कर सकते हैं mail.example.comऔर example.comएक ही सार्वजनिक IP पता करने के लिए।

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

TCP और UDP प्रोटोकॉल पोर्ट नंबर का उपयोग करके होस्ट द्वारा दी जाने वाली विशिष्ट सेवाओं को अलग करते हैं। आपके उदाहरण के मामले में, पोर्ट फॉरवर्डिंग (जिसे पोर्ट एड्रेस ट्रांसलेशन भी कहा जाता है, या PAT) का उपयोग आपके NAT फ़ायरवॉल के फीचर को टीसीपी पोर्ट 80 (HTTP) में इनबाउंड टीसीपी पोर्ट भेजने के दौरान वेब सर्वर पर भेजने के लिए संभव हो सकता है। आपके ईमेल सर्वर पर 25 (SMTP)।

यदि, हालांकि, आप दोनों मशीनों पर एक ही सेवा की मेजबानी करने की योजना बनाते हैं तो यह रणनीति समस्याग्रस्त हो जाती है। मान लीजिए कि आप अपने वेब सर्वर (ग्राहक की पहुंच के लिए) पर एक सुरक्षित वेब साइट और अपने ईमेल सर्वर (वेबमेल के लिए) पर एक सुरक्षित वेब साइट दोनों की मेजबानी करने जा रहे हैं। टीसीपी पोर्ट 443 (HTTPS) में आपके NAT फ़ायरवॉल के सार्वजनिक आईपी पते पर आने वाले अनुरोधों को केवल एक सर्वर या दूसरे पर भेजा जा सकता है।

इस स्थिति का सामान्यीकृत समाधान अधिक सार्वजनिक आईपी पते हैं। क्योंकि IPv4 पते दुर्लभ हो रहे हैं जो समस्याग्रस्त भी हो सकते हैं।

हम आवेदन स्तर पर कुछ प्रोटोकॉल में सार्वजनिक आईपी पते की कमी के आसपास काम कर रहे हैं । उदाहरण के लिए, HTTP / 1.1 ने Host:हेडर को विशेष रूप से एक वेब सर्वर को एक ही सार्वजनिक आईपी पते पर कई वेबसाइटों की मेजबानी करने की अनुमति देने के लिए जोड़ा । दूरस्थ क्लाइंट द्वारा दर्ज होस्टनाम के आधार पर उचित प्रमाण पत्र के चयन की अनुमति देने के लिए टीएलएस सर्वर नाम संकेत (एसएनआई) एक्सटेंशन जोड़ता है ।

एप्लिकेशन लेयर में इस तरह का वर्कअराउंड करने का मतलब है कि हर एप्लिकेशन लेयर प्रोटोकॉल को अपने "फिक्स" (और फिर सभी सर्वर और क्लाइंट सॉफ्टवेयर को उस "फिक्स" को लागू करना होगा)। यह एक लंबा आदेश है।

अनुप्रयोग परत प्रोटोकॉल को संशोधित करने के एवज में कुछ प्रोटोकॉल सॉफ्टवेयर का उपयोग करते हुए कई मेजबानों के बीच "मल्टीप्लेक्स" होने के लिए आसानी से उपयोग करने योग्य हैं जो "मार्ग" अनुरोध कर सकते हैं। यह संभावना इस बात से परे है कि एक सरल एनएटी फ़ायरवॉल सक्षम है क्योंकि पैकेट को आवेदन परत पर निरीक्षण करने की आवश्यकता है। एनजीएक्स जैसे रिवर्स-प्रॉक्सी का उपयोग HTTP प्रोटोकॉल के लिए "मल्टीप्लेक्सिंग" (या फ़ोरफ़्रंट TMG या ISA सर्वर पर Microsoft वातावरण में वेब प्रकाशन नियमों) का एक अच्छा उदाहरण है। सिद्धांत रूप में किसी भी प्रोटोकॉल को एक रिवर्स प्रॉक्सी के माध्यम से गुणा किया जा सकता है, लेकिन प्रोटोकॉल जितना अधिक गूढ़ होगा, उतना ही संभव होगा कि आप कस्टम कोड लिखे जाने के बारे में बात करेंगे।

जब आपको एक ही सार्वजनिक आईपी पते पर दो अलग-अलग मेजबानों से एक ही सेवा की पेशकश करने की आवश्यकता होती है, तो आपके पास हमेशा मेजबानों में से एक को गैर-मानक पोर्ट पर ले जाने का विकल्प होता है। हालांकि इसके लिए ग्राहकों को गैर-मानक पोर्ट के बारे में पता होना चाहिए। HTTP (एस) के मामले में यह URL में http://example.com:XXXनोटेशन (जहां XXXगैर-मानक पोर्ट संख्या है) के साथ होता है। क्या यह आपकी स्थिति में समस्याग्रस्त होगा या नहीं, यह केवल आप ही तय कर सकते हैं। (मेरे अनुभव से पता चला है कि वस्तुतः कोई भी अंत उपयोगकर्ता :XXXकिसी भी URL में पोर्ट संकेतन को संभालने में सक्षम नहीं है, जिसे उन्हें हाथ से दर्ज करना है।)

Comments

वर्कअराउंड, "फिक्स" नहीं। :)

— माइकल हैम्पटन

@ मिसेलहैम्पटन - मैं तुम्हें सुनता हूं '! > मुस्कान <

— इवान एंडरसन

@EvanAnderson आपके उत्तर के लिए धन्यवाद। मुझे लगता है कि मैंने चीजों को गड़बड़ कर दिया है क्योंकि मुझे फॉरएफ्रंट के साथ काम करने के लिए इस्तेमाल किया गया था, ऐसा काम सिर्फ मुझे सामान्य लगा। क्या आप इस क्षमता वाले किसी भी लिनक्स फ़ायरवॉल वितरण के बारे में जानते हैं जो अनुप्रयोग परत पर काम करता है? मैंने अभी तक Shorewall को देखा था, लेकिन मुझे यकीन नहीं है कि अगर यह ऐसा करने में सक्षम है क्योंकि यह iptables पर आधारित है, जैसा कि आपने उल्लेख किया है, ip लेयर पर।

— अत्रोग्यमा

Answer 2

आपकी "पोर्ट फ़ॉरवर्डिंग" सुविधा आपको 192.168.124.32 को 80 और: 443 से 192.168.124.30 और शेष बंदरगाहों (या बस उन लोगों को ईमेल का उपयोग करने के लिए कॉन्फ़िगर किया गया है) के लिए नियत ट्रैफ़िक भेजने की सुविधा दे सकती है। यदि किसी कारण से आपको ईमेल सर्वर के साथ-साथ वेब सर्वर के लिए उन दो बंदरगाहों की आवश्यकता है, तो आप मुश्किल में हैं। इस विधि को काम करने के लिए, आपके ईमेल सर्वर पर किसी भी वेब एक्सेस को एक अलग (सबसे अधिक संभावना वाले गैर-मानक) पोर्ट पर होना होगा। आप शायद उन वेब सर्वर को भी सेट कर देंगे जो किसी भी चीज़ को रीडायरेक्ट करने के लिए कहते हैं, " mail.example.com" इसके बजाय उपयोग करने के लिए, उन उपयोगकर्ताओं के लिए जो पोर्ट नंबर को जोड़ना नहीं जानते और / या सुरक्षित कनेक्शन निर्दिष्ट करते हैं। (आप मेल सर्वर के लिए केवल सुरक्षित वेब कनेक्शन का उपयोग करने जा रहे हैं , है ना?)https://mail.example.com:other_port

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

Answer 3

यदि आपके "आने वाले अनुरोध" अलग-अलग चीजें हैं, अर्थात वेब सर्वर के लिए वेब ट्रैफ़िक (HTTP) और मेल सर्वर के लिए मेल ट्रैफ़िक (SMTP), तो यह वास्तव में किया जा सकता है: HTTP, TCP पोर्ट 80 (HTTPS के लिए 443) का उपयोग करता है, जबकि SMTP टीसीपी पोर्ट 25 का उपयोग करता है; इस प्रकार, उसी सार्वजनिक आईपी पते से, आप अपने वेब सर्वर पर HTTP ट्रैफ़िक, और एसएमटीपी ट्रैफ़िक को अपने मेल सर्वर पर अग्रेषित कर सकते हैं; यह "पोर्ट फ़ॉरवर्डिंग" का अर्थ है। कोई भी सभ्य फ़ायरवॉल इसके लिए सक्षम है।

हालाँकि, यदि संयोग से दोनों सर्वरों को समान प्रकार के ट्रैफ़िक को स्वीकार करने में सक्षम होने की आवश्यकता होती है, तो यदि आपका मेल सर्वर भी वेबमेल सेवा को होस्ट करता है, तो आप मुश्किल में हैं, क्योंकि आप विशिष्ट पोर्ट (80 और / या 443) को अग्रेषित कर सकते हैं केवल एक ही सर्वर के लिए; उस नाम के आधार पर वेब ट्रैफ़िक को अलग करने के लिए, जिसका उपयोग ग्राहक अनुरोध करने के लिए करता था, आपको इसके विपरीत टीसीपी / आईपी से उच्च स्तर पर कुछ संचालित करने की आवश्यकता होती है, जैसे कि रिवर्स प्रॉक्सी।