VPN गेटवेको आफ्नै ठेगानामा LAN सेवा प्रकाशित गर्नुहोस्

गेटवेका आफ्नै सुरुङ ठेगानाहरूमध्ये एउटामा 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 मा गयो कि गएन र सुरुङतिर जवाफ फर्क्यो कि फर्किएन देखाउँछ। नियम बदलेपछि नयाँ जडान प्रयोग गर्नुहोस्, किनकि अहिलेको अवस्थाले आफ्नो अघिल्लो म्यापिङ राख्छ र पुरानै तरिकाले असफल हुँदै जान्छ। त्यसपछि सारा कुराकानी पुष्टि गर्नुहोस्: यन्त्रको ठेगाना, फर्वार्डिङ अनुमति र जवाफको रुट सबैले एउटै प्रवाह वर्णन गर्छन्।