गेटवेच्या स्वतःच्या टनेल पत्त्यांपैकी एकावर LAN उपकरण सादर करण्यासाठी NAT ची एक ओळ पुरते। तरीही कनेक्शन अयशस्वी होते, कारण उत्तर देणाऱ्या उपकरणाला माहीत नाही की क्लायंटचा पत्ता त्या गेटवेमार्फत पोहोचण्यायोग्य आहे। क्लायंटकडून आतील बाजूस पॅकेट ट्रेस करा, नंतर उत्तर परत बाहेरच्या दिशेने ट्रेस करा, आणि गहाळ अर्धा भाग स्पष्ट होईल।

क्लायंटच्या दृष्टिकोनातून सुरुवात करा

या उदाहरणातील क्लायंट VPN पूल 10.62.0.0/24 मध्ये आहे आणि पोर्ट 8080 वर 10.62.0.1 शी जोडतो। तो पत्ता गेटवेचाच आहे, त्यामुळे पॅकेट दुसऱ्या पीअरकडे नाही तर गेटवेच्या कर्नेलकडे पोहोचते। गेटवेच्या मागे LAN 172.21.4.0/24 आहे। गेटवेकडे 172.21.4.10 आहे आणि प्रत्यक्षात HTTP सेवा देणारे उपकरण 172.21.4.40 आहे।

दुसऱ्या VPN पीअरचा पत्ता गेटवेच्या सेवा पत्त्याशी बदलता येत नाही। क्लायंट पीअरच्या पत्त्याशी जोडत असेल, तर गेटवेचा कोणताही नियम अजिबात सहभागी होत नाही, आणि ही संपूर्ण फेरी चुकीची बाब आहे।

गंतव्य अनुवादाची व्याप्ती जाणूनबुजून मर्यादित करा

अरुंद आवृत्ती एक पोर्ट सादर करते आणि फक्त गंतव्य पुन्हा लिहिते। पॅकेट त्याचा प्रोटोकॉल आणि स्रोत टिकवते, आणि यामुळेच उर्वरित फेरी रोचक होते।

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

प्रोटोकॉल आणि पोर्ट निकषांशिवाय नियम ही रुंद आवृत्ती आहे: क्लायंटने निवडलेला कोणताही पोर्ट टिकवतो आणि फक्त पत्ता बदलतो। संपूर्ण होस्ट सादर करायचा असेल तर तो योग्य आहे, आणि एकच सेवा हेतू असेल तर चुकीचा। नियम पुन्हा वाचा आणि इंटरफेसचे नाव पुष्टी करा। चुकीच्या इंटरफेसवरील DNAT नियम कोणाशीही जुळत नाही, ज्यामुळे गहाळ नियमासारखीच वेळमर्यादा येते आणि उपकरणाकडे पाहण्यात एक तास वाया जातो।

फॉरवर्डिंग सीमा सहमत होऊ द्या

अनुवाद हेडर बदलतो, परवानगी देत नाही। डीफॉल्ट ड्रॉप धोरणासह फॉरवर्ड केलेल्या प्रवाहाला स्वतःची परवानगी हवी, आणि परतीच्या दिशेला तुमच्या धोरणात बहुधा आधीपासून असलेला स्थापित कनेक्शनचा नियम हवा।

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

प्रत्येक DNAT प्रवाहासाठी बिनशर्त परवानगी या रचनेपेक्षा रुंद आहे आणि नंतर दुसऱ्याने जोडलेल्या मॅपिंगलाही परवानगी देईल। गंतव्य आणि पोर्टचे नाव द्या, आणि बाकी बंद ठेवा। फॉरवर्ड नियमाचे काउंटर शून्यावर राहिले आणि NAT चे काउंटर वाढले, तर पॅकेट तुमच्या नियमापूर्वीच टाकून दिले जात आहे। दुसरी प्रत जोडण्याऐवजी साखळीचा क्रम वाचा।

उपकरणाला कसे तरी उत्तर द्यावे लागेल

अनुवादानंतर उपकरणाला 10.62.0.0/24 मध्ये स्रोत दिसतो। त्याचे उत्तर त्याच्या डीफॉल्ट गेटवेकडे जाते, जो LAN राउटर आहे, VPN गेटवे नाही, जोपर्यंत काही त्याला अन्यथा सांगत नाही। दोन व्यवस्था हे दुरुस्त करतात आणि त्या समतुल्य नाहीत। उपकरणावर किंवा LAN राउटरवरचा मार्ग 10.62.0.0/24 ला 172.21.4.10 कडे पाठवतो आणि क्लायंट स्रोत टिकवतो। मर्यादित स्रोत अनुवाद त्याऐवजी क्लायंटला गेटवेच्या LAN पत्त्यामागे लपवतो।

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

सेवेला काय हवे आहे त्यानुसार निवडा। प्रति-क्लायंट धोरण आणि अर्थपूर्ण लॉग राउट केलेले स्वरूप इच्छितात; ज्या उपकरणाला मार्ग देता येत नाही, किंवा ज्या सेवेला LAN पत्ता पाहणे बंधनकारक आहे, ते अनुवादित स्वरूपाकडे निर्देश करतात। एक उत्तर कार्यान्वित करण्यासाठी जागतिक masquerade नियमाकडे हात लांबवू नका। तो प्रत्येक क्लायंटला प्रत्येक गंतव्यापासून लपवतो आणि स्रोत पत्त्यांवर अवलंबून असलेली धोरणे शांतपणे मोडतो।

गेटवेपासूनच चाचणी करू नका

गेटवेवर 10.62.0.1 कडे तयार केलेली विनंती येणाऱ्या PREROUTING मधून नाही तर OUTPUT साखळीतून बाहेर पडते। तिचे अपयश किंवा यश क्लायंटकडे पाहणाऱ्या नियमाबद्दल काहीही सांगत नाही, आणि अशाच प्रकारे लोक चालू असलेला नियम तुटलेला आहे असा निष्कर्ष काढतात।

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

खरी क्लायंट विनंती चालवा आणि दोन्ही वाचा। conntrack नोंद लागू केलेला अनुवाद दाखवते, आणि कॅप्चर दाखवतात की विनंती LAN मध्ये गेली की नाही आणि टनेलकडे उत्तर परत आले की नाही। नियम बदलल्यानंतर नवीन कनेक्शन वापरा, कारण विद्यमान स्थिती आपले पूर्वीचे मॅपिंग ठेवते आणि जुन्या पद्धतीने अयशस्वी होत राहील। नंतर संपूर्ण संभाषणाची पुष्टी करा: उपकरणाचा पत्ता, फॉरवर्डिंग परवानगी आणि उत्तराचा मार्ग सर्व एकाच प्रवाहाचे वर्णन करतात।

संबंधित लेख