LAN के अंदर से DNAT'ted webserver को एक्सेस करना

Question

मेरे पास एक राउटर के साथ एक छोटा नेटवर्क है, जो इंटरनेट, एक सर्वर और स्थानीय नेटवर्क में कुछ वर्कस्टेशन से संबंध रखता है।

सर्वर को इंटरनेट से एक्सेस किया जाना है, और राउटर iptables में कई DNAT प्रविष्टियाँ सेट हैं, जैसे:

-A PREROUTING -i ppp0 -p tcp -m multiport --dports 22,25,80,443 -j DNAT --to-destination 192.168.2.10

बाहरी पैकेट ppp0इंटरफ़ेस के माध्यम से राउटर पर आते हैं , और आंतरिक वाले से जाते हैं br-lan, जिसमें वास्तव में स्विच और डब्ल्यूएलएएन एडाप्टर शामिल हैं। समस्या यह है कि जब बाहरी पहुंच ठीक काम करती है, तो DNS-सॉलिड एक्सटर्नल आईपी (असाइन किए गए ppp0) द्वारा LAN के अंदर से सर्वर तक पहुंचने की कोशिश विफल हो जाती है।

एकमात्र समाधान जो मैं आविष्कार करने में सक्षम था, राउटर के /etc/hostsआंतरिक आईपी को इंगित करने के लिए स्थैतिक प्रविष्टियों को जोड़ना है , लेकिन चूंकि कोई वाइल्डकार्ड नहीं हैं (और मेरे पास कम से कम तीन शीर्ष-स्तरीय डोमेन हैं जो उस सिस्टम को सौंपे गए हैं, दसियों उप डोमेन की गिनती नहीं), बल्कि यह कुरकुरे और विफलता-प्रवण है। क्या आप कुछ बेहतर सुझा सकते हैं?

मुझे केवल यह सवाल मिला है , जो बहुत मददगार नहीं था।

यदि यह प्रासंगिक है, तो राउटर OpenWRT 10.03 कामिकेज़ को dnsmasq के साथ चलाता है।

Comments

OpenWRT का क्या संस्करण?

— कोरी एस।

@ कोरी 10.03 स्टेबल, लेकिन इसका ओपनरट से कोई लेना-देना नहीं है, है न?

— व्हाइटवार्क

Answer 1

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

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

यूसीआई में एक अन्य आंतरिक होस्ट से उनके सार्वजनिक आईपी / पोर्ट reflectionकॉम्बोस के माध्यम से आंतरिक सर्वर तक पहुंचने का सही तरीका फ़ाइल में प्रत्येक विशिष्ट डीएनएटी लक्ष्य के तहत कॉन्फ़िगरेशन विकल्प को सक्षम करना है /etc/config/firewall। यह व्यवहार यहाँ प्रलेखित है ।

उदाहरण के लिए:

config redirect option target 'DNAT' option src 'wan' option dest 'lan' option proto 'tcp' option src_dport '44322' option dest_ip '192.168.5.22' option dest_port '443' option name 'apache HTTPS server' option reflection '1'

नोट: संकेतित OpenWRT प्रलेखन के अनुसार, reflectionडिफ़ॉल्ट रूप से सक्षम है। मेरे परीक्षण में, यह मामला नहीं था।

Answer 2

मैंने अपना मूल उत्तर हटा दिया, क्योंकि मुझे पूरा भरोसा नहीं था कि यह सही था। तब से मेरे पास कुछ समय के लिए VMs के एक छोटे से वर्चुअल नेटवर्क को स्थापित करने के लिए है, ताकि नेटवर्क पर सवाल उठाया जा सके। यहाँ फ़ायरवॉल नियमों का एक सेट है जो मेरे लिए काम करता है ( iptables-saveप्रारूप में, natकेवल तालिका के लिए ):

-A PREROUTING -d 89.179.245.232/32 -p tcp -m multiport --dports 22,25,80,443 -j DNAT --to-destination 192.168.2.10
-A POSTROUTING -s 192.168.2.0/24 -o ppp0 -j MASQUERADE
-A POSTROUTING -s 192.168.2.0/24 -d 192.168.2.10/32 -p tcp -m multiport --dports 22,25,80,443 -j MASQUERADE

पहला POSTROUTINGनियम लैन के साथ इंटरनेट कनेक्शन साझा करने का एक सीधा तरीका है। मैंने इसे पूर्णता के लिए वहीं छोड़ दिया।

PREROUTINGनियम और दूसरा POSTROUTINGएक साथ शासन उचित NATs स्थापित है, तो बाहरी आईपी पते के माध्यम सर्वर से है कि कनेक्शन, हो सकता है की कनेक्शन बाहर से या लैन अंदर से हुई हों परवाह किए बिना। जब LAN पर क्लाइंट बाहरी IP पते के माध्यम से सर्वर से जुड़ते हैं, तो सर्वर राउटर के आंतरिक आईपी पते (192.168.2.1) से आने वाले कनेक्शन को देखता है।

दिलचस्प बात यह है कि यह पता चलता है कि दूसरे POSTROUTING नियम के कुछ रूपांतर भी काम करते हैं। यदि लक्ष्य को बदल दिया जाता है -j SNAT --to-source 192.168.2.1, तो प्रभाव समान रूप से नहीं होता है MASQUERADE: सर्वर राउटर के आंतरिक आईपी ​​पते से उत्पन्न होने के रूप में स्थानीय लैन क्लाइंट से कनेक्शन देखता है । दूसरी ओर, यदि लक्ष्य को बदल दिया जाता है -j SNAT --to-source 89.179.245.232, तो NAT अभी भी काम करता है, लेकिन इस बार सर्वर स्थानीय LAN क्लाइंट से कनेक्शन को राउटर के बाहरी आईपी ​​पते (89.179.245.232) से उत्पन्न होने के रूप में देखता है ।

अंत में, ध्यान दें कि आपके मूल PREROUTING/ DNATनियम के साथ -i ppp0काम नहीं करता है, क्योंकि नियम कभी भी लैन क्लाइंट से आने वाले पैकेट से मेल नहीं खाता है (क्योंकि वे ppp0इंटरफ़ेस के माध्यम से राउटर में प्रवेश नहीं करते हैं )। PREROUTINGकेवल आंतरिक LAN क्लाइंट के लिए एक दूसरा नियम जोड़कर इसे काम करना संभव होगा , लेकिन यह एक असंगत (IMO) होगा और अभी भी बाहरी आईपी पते को स्पष्ट रूप से संदर्भित करने की आवश्यकता होगी।

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

Comments

यह पूरी तरह से काम करता है, बहुत-बहुत धन्यवाद! मैं मानता हूं कि DNS सेटअप बेहतर है, लेकिन आप एक ही बाहरी आईपी पर अलग-अलग पोर्ट को इसके साथ LAN पर विभिन्न मशीनों के लिए अग्रेषित नहीं कर सकते। वैसे भी, मैं केवल एक ही व्यक्ति हूँ जो कभी भी इस सेटअप को बनाए रखेगा, इसलिए यह ठीक है।

— व्हाइटवार्क

मुझे खुशी है कि यह आपके लिए काम कर रहा है!

— स्टीवन सोमवार

"IMO" क्या है? अंतर्राष्ट्रीय उल्का संगठन www.imo.net?

— योनातन कोमर

@ macmadness86 IMO == मेरी राय में

— स्टीवन सोमवार

Answer 3

एक सामान्य समाधान अपने आंतरिक होस्ट को स्थानीय DNS सर्वर पर इंगित करना है जो इन होस्टनाम के लिए सही "आंतरिक" पता देता है।

एक और समाधान - और हम इसका उपयोग कर रहे हैं जहां मैं हमारे सिस्को फ़ायरवॉल पर काम करता हूं - इन पतों के अनुरूप फ़ायरवॉल पर DNS प्रतिक्रियाओं को फिर से लिखना है। मुझे नहीं लगता कि लिनक्स के लिए ऐसे उपकरण हैं जो अभी ऐसा करते हैं।

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

Comments

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

— व्हाइटवार्क

क्या आप विन्यास का सुझाव दे सकते हैं? मैंने यह कोशिश की: ip rule add to 89.179.245.232 dev br-lan table 10; ip route add 89.179.245.232 via 192.168.2.10 dev br-lan table 10और यह काम नहीं कर रहा है।

— व्हाइटक्वार्क

रूटिंग टेबल 10 में क्या है? आंतरिक सर्वरों पर, आप संभवतः उन्हें अपने प्राथमिक इंटरफ़ेस पर स्थानीय 192.168.xx पता (स्थानीय रूप से संवाद करने के लिए) और सार्वजनिक पते (एक उपनाम के रूप में) दोनों के लिए चाहते हैं।

— लार्क्स 14

Answer 4

आप जो करने के लिए कह रहे हैं उसे कहा जाता है NAT Loopbackऔर इसके लिए आवश्यक है कि आप एक SNAT नियम जोड़ें ताकि आपके LAN से आपके सर्वर पर आने वाले पैकेट राउटर के माध्यम से वापस जाएँ:

-A POSTROUTING -p tcp -s 192.168.2.0/24 -d 192.168.2.10 -m multiport --dports 22,25,80,443 -j SNAT --to-source 89.179.245.232

Comments

अफसोस की बात है, यह काम नहीं करता है। मैंने मूल -i ppp0रूप से प्रश्न में अपने नियम में विकल्प को याद किया है , क्योंकि यह अन्य श्रृंखला द्वारा नियंत्रित किया गया था; यह नियम LAN से आने वाले पैकेटों को रूट करने से रोकेगा (और अगर मैं इसे सक्षम करूँगा, तो पैकेट गलत स्रोत से जाएंगे और अस्वीकृत हो जाएंगे)।

— व्हाइटवार्क

या तुमने कोशिश की? यह केवल उन्हीं विशिष्ट बंदरगाहों पर आपके सर्वर आईपी पर जाने वाले लैन से पैकेट को प्रभावित करेगा।

— घेराबंदी

हाँ, मैंने किया। (और मैंने पहला नियम भी बदलने की कोशिश की)। जैसे खुदाई 192.168.2.1 # 53 को एक पैकेट भेजता है, और फिर 192.168.2.10 # 53 से, आपके नियम के साथ या बिना एक अप्रत्याशित उत्तर प्राप्त होता है।

— व्हाइटवार्क

Answer 5

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

Comments

हाँ, मैंने लिखा है कि मैं dnsmasq का उपयोग कर रहा हूँ। स्वचालित प्रतिस्थापन स्थापित करने पर कोई विचार?

— व्हाइटवार्क

मुझे OpenWRT और कामिकेज़ के बारे में कुछ नहीं पता है, लेकिन मैं जो पढ़ रहा हूं, उसके आधार पर - अगर आपने अपने /etc/dnsmasq.conf "cname = ext-hostname.domain.com, int-hostname.domain.com" से निम्नलिखित को जोड़ा है, तो क्या होगा

— कर्टम

खैर, जहां तक ​​मैं निर्धारित करने में सक्षम था, dnsmasq cnameमास्क का समर्थन नहीं करता है, और इस तरह से उपडोमेन गिनती के कारण मेरे लिए लागू नहीं है।

— व्हाइटवार्क 5

Answer 6

मैं निम्नलिखित समाधान के साथ अपने अतिथि नेटवर्क को उन पोर्ट से कनेक्ट करने की अनुमति देने के लिए आया, जो मेरे वान से लैन नेटवर्क पर भेजे गए थे। यह स्क्रिप्ट मेरे "नेटवर्क -> फ़ायरवॉल -> कस्टम नियम" अनुभाग में रखी गई है:

# lookup the public IP (DDNS resolves to this)
wanip=$(ip route get 8.8.8.8 | awk -F"src " 'NR==1{split($2,a," ");print a[1]}')

# Guest network to LAN
# srcname is the guest network name, this needs to match for iptables
srcname=guest
# CIDR notation of guest and lan networks
srcnet=192.168.15.0/24
tgtnet=192.168.10.0/24
# router (openwrt) IP on lan network
tgtrouter=192.168.10.1
# host on lan network where ports are normally forwarded
tgthost=192.168.10.5
# ports to forward as a list or range
tcpports=8080,9090
udpports=12345

prechain=prerouting_${srcname}_rule
postchain=postrouting_${srcname}_rule

# reset the tables to prevent duplicate rules
iptables -t nat -F ${prechain}
iptables -t nat -F ${postchain}

iptables -t nat -A ${prechain} -s ${srcnet} -d ${wanip}/32 -p tcp -m tcp -m multiport --dports ${tcpports} -m comment --comment "${srcname} NAT reflection TCP DNAT" -j DNAT --to-destination ${tgthost}
iptables -t nat -A ${postchain} -s ${srcnet} -d ${tgthost}/32 -p tcp -m tcp -m multiport --dports ${tcpports} -m comment --comment "${srcname} NAT reflection TCP SNAT" -j SNAT --to-source ${tgtrouter}
iptables -t nat -A ${prechain} -s ${srcnet} -d ${wanip}/32 -p udp -m udp -m multiport --dports ${udpports} -m comment --comment "${srcname} NAT reflection UDP DNAT" -j DNAT --to-destination ${tgthost}
iptables -t nat -A ${postchain} -s ${srcnet} -d ${tgthost}/32 -p udp -m udp -m multiport --dports ${udpports} -m comment --comment "${srcname} NAT reflection UDP SNAT" -j SNAT --to-source ${tgtrouter}

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

uci set firewall.@include[0].reload="1"
uci commit firewall

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

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

Comments

वर्तमान कर्नेल में conntrackमैच मॉड्यूल है। और आप सभी को इस मुद्दे को हल करने की आवश्यकता है जैसे कि एकल नियम का उपयोग करें:iptables -t nat -A POSTROUTING --dst <lan-net> ! --src <lan-gw-ip> -m conntrack --ctstate DNAT --ctorigdst <wan-gw-ip> -j MASQUERADE

— एंटोन

@AntonDanilov अच्छा है, मुझे वह पसंद है। मेरे द्वारा उपयोग किए जाने वाले नियम एक ही सबनेट से कनेक्शन के लिए OpenWRT में पहले से ही प्रतिबिंब NAT नियमों से आधारित थे। निश्चित नहीं है कि अगर उनके पास इसके अलावा कोई अन्य कारण हो तो संभवत: कॉनट्रैक उपलब्ध होने से पहले लिखा जाए।

— BMitch