NAT पछाडिको WireGuard पियरमा पोर्ट फर्वार्डिङ: DNAT र SNAT

एउटा ब्राउजरले https://203.0.113.10:8443 अनुरोध गर्छ, प्रोक्सीले जडान स्वीकार्छ, र WireGuard पियरमा रहेको सेवाले कहिल्यै जवाफ दिँदैन। DNAT नियमले आफ्नो काम गरिरहेको छ; असफल हुने भाग जवाफ हो। प्याकेटलाई दुवै अनुवादबाट पछ्याउनुहोस् र छुटेको नियम स्पष्ट हुन्छ। समाधान सही हुकमा अर्को NAT कथन हो, नयाँ टनेल होइन।

एउटा अनुरोध सुरुदेखि अन्त्यसम्म पछ्याउनुहोस्

अनुरोध प्रोक्सीको सार्वजनिक इन्टरफेसमा आउँछ, स्रोतमा ग्राहकको सार्वजनिक ठेगाना र गन्तव्यमा प्रोक्सीको ठेगाना हुन्छ। nat PREROUTING मा DNAT नियमले गन्तव्यलाई पियरको टनेल ठेगाना 10.90.0.2 मा पुनः लेख्छ। त्यसपछि राउटिङ निर्णयले प्याकेटलाई wg0 मार्फत बाहिर पठाउँछ, र फर्वार्ड मार्ग पूरा हुन्छ।

पियरमा प्याकेटले अब मूल सार्वजनिक स्रोत ठेगाना बोकेको छ, किनकि कसैले त्यसलाई पुनः लेखेको छैन। सेवाले जडान स्वीकार्छ र आफ्नो जवाफ आफ्नै डिफल्ट गेटवेमा पठाउँछ, जो पियरअगाडिको घरायसी राउटर हो। त्यो राउटरसँग कहिल्यै नदेखेको प्रवाहका लागि कुनै अवस्था छैन, त्यसैले यसले प्याकेट फाल्छ वा आफ्नै सार्वजनिक ठेगानामा अनुवाद गर्छ, जुन ग्राहकले स्वीकार गर्ने छैन।

असममिति नै सम्पूर्ण समस्या हो: अनुरोध प्रोक्सीबाट जान्छ, र जवाफ सिधै जान प्रयास गर्छ। प्रोक्सीको जडान ट्र्याकिङले जवाफ प्रोक्सीबाट फर्केर आएमा मात्र मद्दत गर्छ, र स्रोत ठेगाना अझै मूल ग्राहकतिर देखाइरहेको बेला त्यो त्यहाँ फर्कन सक्दैन।

फर्कने अनुवाद थप्नुहोस्

फर्वार्ड हुने प्रवाहको स्रोत पियरतिर जानुअघि प्रोक्सीको टनेल ठेगानामा पुनः लेख्नुहोस्। त्यसपछि सेवाले 10.90.0.1 मा जवाफ दिन्छ, प्रोक्सीले त्यो प्राप्त गर्छ, र प्याकेट ग्राहककहाँ फर्कनुअघि जडान ट्र्याकिङले दुवै अनुवाद उल्टाउँछ।

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

POSTROUTING नियम जानाजान साँघुरो छ: यो अनुवादित गन्तव्य र टनेल इन्टरफेससँग मिल्छ, त्यसैले wg0 बाट संयोगवश बाहिरिने असम्बन्धित ट्राफिक पुनः लेख्दैन। फराकिलो masquerade नियम ले ग्राहकको ठेगाना पनि लुकाउँथ्यो, तर त्यो हरेक प्रवाहका लागि गर्थ्यो र NAT तालिकाको अडिट कठिन बनाउँथ्यो।

टनेल जहाँ छ त्यहीँ नियम राख्नुहोस्

टनेलको ठेगाना वा इन्टरफेसलाई सन्दर्भ गर्ने नियमहरू wg-quick ले त्यो कन्फिगर गरेपछि चल्नुपर्छ। इन्टरफेस PreUp अघि सिर्जना हुन्छ, तर ठेगाना, MTU, DNS र मार्गहरू त्यसपछि लागू हुन्छन्, र ती सबै ठाउँमा भएपछि PostUp चल्छ। थपहरू PostUp मा र हटाउनेहरू PreDown मा राख्नुहोस्।

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

हटाउनेहरू थपहरूसँग टोकन दर टोकन मिल्नुपर्छ, multiport र इन्टरफेस मिलानहरू सहित। एउटा मिलानमा फरक पर्ने हटाउनेले केही हटाउँदैन, र अर्को पुनः जडानले नियमको दोस्रो प्रतिलिपि थप्छ। केही पुनः जडानपछि तालिकामा कन्फिगरेसन लाइनसँग जोड्न गाह्रो हुने दोहोरो प्रतिलिपिहरू हुन्छन्।

नतिजा iptables -t nat -S प्रयोग गरेर पुनः जडानपछि जाँच्नुहोस्। यदि त्यही नियम दुई पटक देखिन्छ भने PreDown लाइन मिल्दैन र सफाइ चुपचाप असफल हुन्छ।

फर्वार्डिङ, फिल्टरिङ र अर्को NAT

IPv4 फर्वार्डिङ स्थायी रूपमा सक्षम गर्नुहोस्, त्यसपछि फिल्टर तालिकामा फर्वार्ड हुने प्रवाहलाई अनुमति दिनुहोस्। DNAT FORWARD शृंखलाअघि हुन्छ, त्यसैले फिल्टर नियम सार्वजनिक ठेगानासँग नभई अनुवादित गन्तव्यसँग मिल्छ। यदि UFW ले फायरवाल चलाउँछ भने, अनुमतिलाई मार्ग नियमका रूपमा व्यक्त गर्नुहोस्; साधारण होस्ट नियमले फर्वार्ड हुने ट्राफिक समेट्दैन।

प्रोक्सीका नियम सही भए पनि अरू दुई NAT तहले मार्ग तोड्न सक्छन्। घरायसी जडानमा सार्वजनिक ठेगाना राउटरको हुन्छ, र त्यसको फायरवालमा पोर्ट खोल्नु त्यो पोर्ट प्रोक्सीमा पठाउने पोर्ट-फर्वार्ड प्रविष्टि बनाउनुसँग बराबर होइन। बाहिरबाट खुला देखिने तर केही पनि जवाफ नदिने पोर्टमा प्रायः त्यही म्यापिङ हुँदैन।

NAT VPS मा प्रदायकले सार्वजनिक पोर्टलाई निजी ठेगानामा म्याप गर्छ। म्यापिङ तपाईंले घोषणा गरेको पोर्टसँग मिल्नुपर्छ, र अमिलता बिग्रिएको टनेलजस्तै देखिन्छ। WireGuard कन्फिगरेसन बदल्नुअघि प्रदायकको म्यापिङ पुष्टि गर्नुहोस्।

फर्कने मार्ग जाँच्नुहोस् र लागत स्वीकार्नुहोस्

प्रोक्सीको LAN नभएको नेटवर्कबाट जडान गर्नुहोस्, त्यसपछि जडान खुला रहेको बेला अनुवाद जोडी जाँच्नुहोस्:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

conntrack प्रविष्टिले मूल tuple, अनुवादित tuple र जवाफको दिशा देखाउनुपर्छ। यदि जवाफ छैन भने पियरले टनेलबाट पठाइरहेको छैन, जसको अर्थ सामान्यतया SNAT नियम लागू भएन वा पियरको आफ्नै फायरवालले प्रवाह फ्याँक्यो।

PostUp ले नियमहरू पुनः लागू गर्छ भनी प्रमाणित गर्न एक पटक रिबुट गर्नुहोस्, त्यसपछि टनेल रोक्नुहोस् र PreDown ले ती हटाएको पुष्टि गर्नुहोस्। डिस्कनेक्टपछि बाँकी रहने मृत नियमहरू नै पछिको परिवर्तन अप्रत्याशित रूपमा व्यवहार गर्नुको कारण हो।

अन्तमा, SNAT को लागत स्वीकार्नुहोस्। सेवाले हरेक अनुरोध प्रोक्सीबाट आएको देख्छ, त्यसैले पहुँच लग, प्रति-ग्राहक दर सीमा र अनुमत ठेगाना सूचीहरूले अब प्रयोगकर्ताहरू छुट्याउँदैनन्। हेयरपिन केसलाई प्रोक्सीको LAN का ग्राहकहरूका लागि आफ्नै स्रोत अनुवाद चाहिन्छ। यदि पियरलाई वास्तविक ग्राहक ठेगाना चाहिन्छ भने, विकल्प ग्राहक नेटवर्कतिर फर्कने मार्ग हो, जो बढी काम हो तर जानकारी जोगाउँछ।