दोन 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 आणि कोणताही दुय्यम इग्रेस मार्गही तपासा, नंतर पुढील बदल नियमाच्या मजकुराऐवजी मॅपिंगपासून सुरू व्हावा म्हणून अंतर्गत-ते-सार्वजनिक जोड्या फायरवॉलच्या दस्तऐवजीकरणात नोंदवा।