दो VPN क्लाइंट, दो सार्वजनिक पते: SNAT को मिलाएँ

दो VPN क्लाइंट दो अलग सार्वजनिक IPv4 पतों से बाहर जा सकते हैं, और यह करने वाला नियम ज़्यादातर लोगों की अपेक्षा से छोटा है। इसे काम करने वाली चीज़ iptables का सिंटैक्स नहीं, बल्कि पैकेट की वह स्थिति है जब वह इग्रेस चेन तक पहुँचता है: वहाँ का स्रोत पता अब भी क्लाइंट में अंतर कर पाना चाहिए। अगर किसी पहले के masquerade ने दोनों को एक ही पते पर समेट दिया है, तो कोई भी प्रति-क्लाइंट नियम वह अंतर वापस नहीं ला सकता। पहले यह सवाल तय करें, फिर अनुवाद लिखें।

कौन-सी पहचान गेटवे तक बचती है

नियम पैकेट के स्रोत पते से मेल खाता है, VPN उपयोगकर्ता नाम से नहीं और उस नाम से भी नहीं जो क्लाइंट ऐप्लिकेशन दिखाता है। रास्ते में पहले पैकेट का जो भी रूपांतरण करता है, वह तय करता है कि आपका नियम अब भी क्या देख सकता है। nat तालिका क्रम से चलाएँ और वह बिंदु खोजें जहाँ स्रोत अब भी हर क्लाइंट के लिए अलग है।

iptables -t nat -S POSTROUTING

उस सूची को ऊपर से पढ़ें। ऊपर के पास का masquerade नियम हर मेल खाते फ़्लो के लिए स्रोत फिर से लिखता है, और उसके बाद रखी गई प्रति-क्लाइंट प्रविष्टियाँ ऐसे पते से मेल खाती हैं जो अब मौजूद नहीं है। जब दो LAN डिवाइस एक ही टनल साझा करते हैं और एक ही आंतरिक पते के रूप में पहुँचते हैं, तो फ़ायरवॉल से पहले डिज़ाइन बदलना होगा: उनकी स्रोत श्रेणियाँ अलग रखें या हर एक को अपना आंतरिक पता दें।

आंतरिक पते का आवंटन प्रमाणित क्लाइंट से जोड़ें। वह पता किसी दूसरे डिवाइस को देना उसके साथ इग्रेस नीति भी सौंप देना है, और स्रोत रूपांतरण अपने आप में पहचान का प्रमाण नहीं है।

रूपांतरण पता नहीं गढ़ सकता

हर सार्वजनिक पता इस इग्रेस बिंदु को आवंटित या यहाँ रूट किया जाना चाहिए, और जवाबों को वापस इसी तक पहुँचने का रास्ता मिलना चाहिए। जो नियम ऐसे पते से ट्रैफ़िक भेजता है जहाँ कोई वापस रूट नहीं करता, वह दूर के छोर पर गिरा दिया जाता है या ऐसे होस्ट को जवाब दिया जाता है जिसने कभी माँगा ही नहीं। क्लाउड प्रदाता के इंस्टेंस का सार्वजनिक पता आम तौर पर पैकेट निकलने से पहले निजी इंटरफ़ेस पते में बदल दिया जाता है, इसलिए SNAT स्रोत वही पता होना चाहिए जिसे प्रदाता स्वीकार करेगा, कंसोल में दिखने वाला मान नहीं। प्रदाता का पता मॉडल पढ़ें और हर पैकेट में सार्वजनिक मान कॉपी करने के बजाय उसका पालन करें।

व्यवहार में इसका मतलब है कि फ़ायरवॉल को छूने से पहले प्रदाता कंसोल में रूट किया गया प्रीफ़िक्स जाँचें, और जब मैपिंग एक-से-एक हो तो निजी इंटरफ़ेस पते को रूपांतरण स्रोत के रूप में इस्तेमाल करें। नीचे के उदाहरणों में इस्तेमाल पते दस्तावेज़ीकरण श्रेणियों से आए हैं, इसलिए पहले जो बदलना है वह पते का पाठ ही है।

सामान्य masquerade से पहले डालें

कुछ भी जोड़ने से पहले इग्रेस इंटरफ़ेस और मौजूदा चेन की पुष्टि करें। पहला तय करता है कि नियम किन पैकेटों से मेल खा सकता है, और दूसरा दिखाता है कि उसके सामने पहले से क्या खड़ा है।

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

पहला कमांड उस इंटरफ़ेस का नाम बताता है जिससे इंटरनेट जाने वाला पैकेट वास्तव में निकलता है। दूसरा लाइन नंबरों के साथ चेन छापता है। सामान्य masquerade प्रविष्टि वह पंक्ति है जिसके ऊपर रहना है।

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

ऊपर के दोनों नियम एक-एक आंतरिक पते से मेल खाते हैं, मेल को इग्रेस इंटरफ़ेस तक सीमित करते हैं और स्रोत स्पष्ट रूप से सेट करते हैं। जोड़ने के बजाय डालें: स्थान 1 पर इनका मूल्यांकन masquerade पंक्ति से पहले होता है। दोनों के बीच क्रम मायने नहीं रखता क्योंकि उनके स्रोत अलग हैं। रूट कमांड ने जो बताया उससे ens3 बदलें, और दूसरे फ़ायरवॉल मैनेजरों को उन्हीं हुक्स से दूर रखें, क्योंकि दो टूल का एक ही तालिका लिखना ही सही नियम के असर न होने का आम कारण है।

नए फ़्लो से स्रोत साबित करें

स्टेटफ़ुल NAT फ़्लो शुरू होने पर रूपांतरण बाँधता है और बाद के पैकेटों के लिए उसे दोबारा इस्तेमाल करता है, इसलिए बदलाव से पहले खुला सत्र बदलाव के बाद भी अपना पुराना स्रोत बनाए रखता है। केवल नया शुरू किया गया कनेक्शन ही नियम साबित करता है।

conntrack -L -s 10.88.4.20 -p tcp --dport 443

उस प्रविष्टि की उत्तर दिशा पढ़ें: उसका गंतव्य वह पता है जिसे दूर का छोर स्रोत के रूप में देखता है। इसकी तुलना अपने इच्छित सार्वजनिक पते से करें, और पुराना पता लिए प्रविष्टि को टूटे नियम के बजाय बहुत जल्दी शुरू हुए फ़्लो का सबूत मानें। क्लाइंट से नया कनेक्शन खोलने को कहें, फिर क्वेरी दोहराएँ। परीक्षण के लिए पूरी ट्रैकिंग तालिका फ़्लश करना गेटवे पर हर दूसरे सत्र को बाधित करता है।

रूपांतरण अब भी रूट नहीं चुनता, फ़िल्टर से फ़्लो नहीं गुज़ारता और इनबाउंड सेवा प्रकाशित नहीं करता। गलत रूट और गुम अनुमति नियम सही SNAT नियम के बाद भी विफल रहते हैं। IPv6 और किसी भी द्वितीयक इग्रेस पथ की भी जाँच करें, फिर फ़ायरवॉल के दस्तावेज़ीकरण में आंतरिक-से-सार्वजनिक जोड़े दर्ज करें ताकि अगला बदलाव नियम के पाठ के बजाय मैपिंग से शुरू हो।