NAT मागील OpenVPN क्लायंट कसा इंटरनेट एक्झिट होतो

तीन Linux होस्ट, एक रचना: सार्वजनिकरीत्या उपलब्ध OpenVPN हब, एक लॅपटॉप आणि आत काहीही फॉरवर्ड न करणाऱ्या साध्या घरगुती राउटरमागील एक्झिट मशीन। एक्झिट स्वतः हबला डायल करते। मग ग्राहकाचा इंटरनेट ट्रॅफिक लॅपटॉपवर टनेलमध्ये शिरतो आणि एक्झिटच्या स्वतःच्या अपलिंकमधून बाहेर पडतो। या रचनेतील प्रत्येक आश्चर्यकारक गोष्ट एका तपशिलातून येते: कनेक्शन एक्झिटने सुरू केले, त्यामुळे आत जाणारा मार्ग आधीच आहे आणि तो तयार करण्यासाठी पोर्ट फॉरवर्डिंगची गरज नाही।

पुढील मजकूर कॉन्फिगरेशनचा क्रम नाही तर पॅकेटचा मार्ग पाहतो, कारण कोणता घटक कोणता निर्णय घेतो हे कळल्यावरच कॉन्फिगरेशनला अर्थ येतो। प्रत्येक स्तर नेमका एक निर्णय घेतो आणि चुका दोन स्तर एक मानल्या जातात तिथे साचतात।

दोन ट्रान्सपोर्ट सत्रे, एक अंतर्गत मार्ग

प्रत्येक होस्ट हबशी स्वतःचे बाह्य कनेक्शन ठेवतो आणि त्यातील कोणतेही दुसऱ्याबद्दल जाणत नाही। ग्राहकाचा इंटरनेटकडील ट्रॅफिक हा वेगळा अंतर्गत प्रवाह आहे, जो ग्राहकाच्या टनेलमध्ये वाहून नेला जातो आणि नंतर एक्झिटच्या टनेलमधून पुन्हा बाहेर सोडला जातो। हबला हाच अंतर्गत प्रवाह रूट करायचा आहे आणि एक्झिटला तोच फॉरवर्ड करायचा आहे।

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

दोन्ही बाह्य कनेक्शन क्लायंटच्या बाजूने बाहेर जातात, त्यामुळे एक्झिटचा राउटर कधीही इनबाउंड SYN पाहत नाही आणि त्याला कधीही डेस्टिनेशन NAT नियमाची गरज पडत नाही। त्याला फक्त प्रस्थापित ट्रान्सपोर्ट जिवंत ठेवायचा असतो, जे तो कोणत्याही दीर्घ कनेक्शनसाठी आधीच करतो। सार्वजनिक इंटरनेटवरील कशालाही आधी एक्झिटपर्यंत पोहोचण्याची गरज नाही, म्हणून त्या अपलिंकवरील गतिशील पत्ता ही समस्या नाही। राउटरला बाहेर जाणाऱ्या सत्राला परवानगी द्यावी लागते, पण ती ब्राउझर आधीच वापरत असलेली परवानगी आहे।

iroute सर्व्हरच्या आत प्रत्यक्षात काय इन्स्टॉल करते

कोणता साथीदार कोणत्या गंतव्याचा मालक आहे हे ठरवणारे हब हेच एकमेव उपकरण आहे आणि तो निर्णय ते कर्नेलमध्ये नाही तर स्वतःच्या यूजरस्पेस राउटिंग टेबलमध्ये घेते। एक्झिटसाठी exit-node नावाची client-config-dir नोंद तिथे डीफॉल्ट प्रीफिक्सचा दावा करू शकते:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

ती ओळ सर्व्हर प्रोसेसला सांगते की "कोणत्याही गंतव्यासह अंतर्गत पॅकेट या क्लायंटचे आहेत"। ती हबच्या ऑपरेटिंग सिस्टममध्ये डीफॉल्ट रूट जोडत नाही आणि हबला इंटरनेट गेटवे बनवत नाही। OpenVPN 2.6 संदर्भ क्लायंट-विशिष्ट अंतर्गत राउटिंग आणि कर्नेल राउटिंग वेगळ्या यंत्रणा म्हणून ठेवते आणि हेच विभाजन या रचनेला हबच्या डीफॉल्ट रूटला स्पर्श न करता काम करण्याचे कारण आहे।

ग्राहकाला आरशासारखी सूचना हवी, push म्हणून दिलेली, जेणेकरून त्याचा स्वतःचा ट्रॅफिक स्थानिक गेटवेमधून बाहेर जाण्याऐवजी टनेलमध्ये शिरेल। सबनेट टोपोलॉजीत पूल एक्झिटच्या tun उपकरणावरील जोडलेला मार्ग आहे, त्यामुळे परतीच्या दिशेला अतिरिक्त push लागत नाही; एक्झिटला जे मिळू नये ते खालील रीडायरेक्शन आहे, जे तिच्या स्वतःच्या अपलिंक ट्रॅफिकला ज्या टनेलचा वापर करायचा आहे त्यात परत पाठवेल। ते फक्त ग्राहकाला पाठवा आणि CCD फाइल निवडली गेली असे मानण्याऐवजी क्लायंटवर लागू झालेले मार्ग वाचा।

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

फॉरवर्डिंग एक्झिटचे कर्नेल करते

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

म्हणून एक्झिटला सतत चालू IPv4 फॉरवर्डिंग, ग्राहकाच्या टनेल स्रोतांना अपलिंककडे प्रवेश देणारा नियम आणि tun मधून परत जाणारा उत्तरमार्ग लागतो। संपूर्ण होस्टसाठी फॉरवर्डिंग सुरू केल्याने त्यातून रूट होणाऱ्या इतर सर्वांचे वर्तनही बदलते, म्हणून नियमाने सर्व स्वीकारण्याऐवजी स्रोत आणि इंटरफेस यांची नावे द्यावीत।

परतीचा मार्ग स्रोत भाषांतर विकत घेते

इंटरनेट होस्टकडे 10.90.0.x पत्त्याकडे कोणताही मार्ग नाही, त्यामुळे उत्तरे एक्झिटपर्यंत पोहोचण्याआधीच टाकून दिली जातील। पॅकेट अपलिंक सोडताना स्रोत पुन्हा लिहिल्याने ते सुटते आणि कनेक्शन ट्रॅकिंग परतीला ते पुनर्लेखन उलट देते।

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

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

हब कुठे लागू करू शकते आणि कुठे नाही

client-to-client आणि पारंपरिक यूजरस्पेस डेटा पाथसह हब सर्व्हर प्रोसेसच्या आतच साथीदारांमध्ये अंतर्गत पॅकेट सुपूर्द करते। ते कधीही हबच्या कर्नेल FORWARD साखळीतून जात नाहीत, त्यामुळे तिथला कर्नेल नियम कितीही काळजीपूर्वक लिहिला असला तरी साथीदारांमधील संचार मर्यादित करू शकत नाही। अंमलबजावणी सर्व्हरच्या स्वतःच्या धोरणातच असली पाहिजे: कोणाला जोडण्याची परवानगी आहे, त्याला कोणती CCD फाइल मिळते आणि एक्झिटची डीफॉल्ट मालकी अजिबात दिली जाते का।

म्हणूनच डीफॉल्ट iroute हा व्यापक विश्वासाचा निर्णय आहे। एक्झिटला अनियंत्रित इंटरनेट पत्त्यांकडून परतीचा ट्रॅफिक कायदेशीरपणे स्वीकारावा लागतो आणि ती अशी मशीन असली पाहिजे जी तुम्ही नियंत्रित, पॅच आणि देखरेख करता। तीच मालकी ज्याला तुम्ही राउटर देणार नाही अशा साथीदाराला देणे हीच या रचनेची आमंत्रित चूक आहे।

सदस्यत्व हेच खरे नियंत्रण आहे। स्वतःचे मार्ग कॉन्फिगर करू शकणारा कोणताही क्लायंट एक्झिट वापरण्याचा प्रयत्न करू शकतो, म्हणून कोण जोडू शकतो किंवा एक्झिट कोणत्या साथीदारांना सेवा देईल हे मर्यादित करणे रचनेचा भाग आहे, नंतरचा विचार नाही।

एक्झिट गायब झाल्यावर सुरक्षितपणे अयशस्वी होणे

एक्झिट ऑफलाइन करा आणि अंतर्गत डीफॉल्ट मालकी तिच्या सत्रासह गायब होते। जे होऊ नये ते म्हणजे हब शांतपणे बदली एक्झिट होणे: VPN पूलपासून हबच्या अपलिंकपर्यंत कोणताही डीफॉल्ट मार्ग नाही आणि हबवर तोच ट्रॅफिक आनंदाने फॉरवर्ड करणारा व्यापक मास्करेड नियम नाही। ते अयशस्वी होणे जाणीवपूर्वक तपासा आणि नंतर आधीच उघडलेल्या पानाऐवजी नवीन प्रवाहाने पुनर्प्राप्ती तपासा।

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

एक्झिट गेल्यानंतरही ग्राहकाचा ट्रॅफिक इंटरनेटपर्यंत पोहोचत असेल, तर दुसरे काही तो वाहून नेत आहे आणि तुम्ही ठरवलेली सीमा अस्तित्वात नाही। DNS आणि IPv6 यांनाही स्वतंत्र निर्णय माना: IPv4 मार्ग आणि मास्करेड AAAA ट्रॅफिकबद्दल काहीही सांगत नाहीत आणि हबने ढकललेला रिझॉल्व्हर क्वेरी प्रत्यक्षात जिथून बाहेर पडते तिथूनच उत्तर देईल।