अपस्ट्रीम VPN मागील डाउनस्ट्रीम क्लायंट: राउट की NAT?

एक गेटवे तुमच्या स्वतःच्या उपकरणांसाठी WireGuard आणि दुसऱ्या कोणाच्या नेटवर्ककडे OpenVPN क्लायंट चालवतो. दोन आतील इंटरफेसांमधील फॉरवर्डिंग चालते, आणि डाउनस्ट्रीम सबनेट आता अपस्ट्रीम सेवेचा भाग आहे असा निष्कर्ष काढणे सोपे आहे. तसे नाही. क्लायंटने ओढलेला राउट तुमच्या गेटवेला सांगतो की विनंत्या कुठे पाठवायच्या; पण दूरचे नेटवर्क आपण कधीच ऐकले नसलेल्या उपकरणांना ट्रॅफिक कसा परत पाठवते याबद्दल तो काहीच सांगत नाही. एकही नियम जोडण्यापूर्वी अपस्ट्रीम प्रत्यक्षात जे रिटर्न मॉडेल सपोर्ट करते ते निवडा.

राउटिंगला हात लावण्यापूर्वी रिटर्न मॉडेल ठरवा

या मार्गदर्शनात डाउनस्ट्रीम क्लायंट 10.90.0.0/24 वापरतात, गेटवेला दिलेला अपस्ट्रीम टनेल पत्ता 10.80.0.6 आहे, आणि मंजूर दूरचा स्रोत 172.20.0.30 आहे. या आकाराला दोन मॉडेल बसतात: डाउनस्ट्रीम स्रोत टिकवून दूरच्या बाजूकडून तो राउट करून घेणे, किंवा स्रोताचे गेटवेच्या स्वतःच्या टनेल पत्त्यात भाषांतर करणे. या निर्णयानंतरचे सर्व यांत्रिक आहे, आणि निर्णयालाच सेवेच्या मालकाची गरज असते. वरची एक ओळ दूरच्या बाजूशी राउटिंग करार आहे; दुसरी तुम्ही एकट्याने करू शकता अशी स्थानिक धोरण बदल आहे. या दोन्हींचा गोंधळ दहा मिनिटांचे काम वाटाघाटीत बदलतो.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

एक ओळ निवडा आणि तिला चिकटून राहा. ओळी पायऱ्या नाहीत, पर्याय आहेत, आणि त्या मिसळल्यास पुनरावलोकनात कोणीही समजावून सांगू शकत नाही अशी रचना तयार होते.

राउटद्वारे स्रोत जतन

दूरची बाजू डाउनस्ट्रीम पत्त्यावरून विनंती घेते, त्यामुळे तिला त्या सबनेटसाठी सपोर्टेड राउट आणि पीअर मालकी, तसेच ती स्वीकारण्याची परवानगी लागते. ही दूरची सेटिंग्ज आहेत, आणि कोणताही स्थानिक Linux राउट ती बनवत नाही. त्या स्पष्टपणे आणि लेखी मागा, प्रीफिक्स आणि ती वाहून नेणाऱ्या टनेल पीअरसह, आणि उत्तर सेवा साइट-टू-साइट व्यवस्था अजिबात सपोर्ट करते की नाही यावर अवलंबून असेल अशी अपेक्षा ठेवा.

उत्तर होय असल्यास स्थानिक संरचना लहान आहे: फॉरवर्डिंग सुरू, डाउनस्ट्रीम श्रेणी झाकणारे WireGuard पीअरचे allowed-ips, आणि दोन्ही दिशांनी ओलांडण्यास परवानगी देणारे फायरवॉल धोरण.

जाणीवपूर्वक स्रोत भाषांतर

सेवा ट्रॅफिक फक्त जोडलेल्या क्लायंटच्या पत्त्यावर परत पाठवत असल्यास, बाहेर पडताना स्रोताचे त्या पत्त्यात भाषांतर करा आणि उत्तरांसाठी तो उलटणारी conntrack स्थिती ठेवा. नियम इच्छित डाउनस्ट्रीम स्रोत, इच्छित दूरची गंतव्ये आणि अपस्ट्रीम इंटरफेसपुरता मर्यादित करा. प्रत्येक इंटरफेसातून बाहेर पडणाऱ्या सर्व गोष्टींचे भाषांतर करणारा नियम या गरजेपेक्षा खूप मोठे धोरण आहे, आणि तो तुम्हाला नंतर चकित करेल.

IPv6 ला स्वतःची रचना लागते; IPv4 masquerade ओळ कॉपी करणे हे आर्किटेक्चर नाही. भाषांतरित मार्ग कॅशे केलेल्या कनेक्शनऐवजी नव्या कनेक्शनने तपासा.

स्थानिक डेटा मार्ग अजूनही चालला पाहिजे

भाषांतर स्थानिक काम काढून टाकत नाही: गेटवेला अजूनही डाउनस्ट्रीम गंतव्यांसाठी राउट, योग्य WireGuard पीअर स्रोत मालकी, सुरू फॉरवर्डिंग आणि इंटरफेसांमध्ये अरुंद फायरवॉल धोरण लागते. गेटवेवरच तयार झालेली विनंती यापैकी एकही परवानगी वापरून पाहत नाही, म्हणून गेटवेवरील स्थानिक चाचण्या उत्तीर्ण होतात पण डाउनस्ट्रीम उपकरणे अजूनही अपयशी ठरतात.

गेटवेवरून नाही, खऱ्या डाउनस्ट्रीम उपकरणावरून चाचणी करा. स्रोत पत्ता हाच या सरावाचा संपूर्ण उद्देश आहे.

एक स्रोत म्हणजे एक सत्र ओळख

दूरची सेवा प्रत्येक डाउनस्ट्रीम उपकरणासाठी स्वतंत्र प्रमाणीकरण नाही तर गेटवेचे प्रमाणित सत्र आणि त्याचा भाषांतरित पत्ता पाहते. प्रति-उपकरण परवानग्या आणि अनुप्रयोग ओळखी स्पष्ट ठेवा, आणि अनेक उपकरणांच्या वतीने काम करणाऱ्या गेटवेला अजिबात परवानगी आहे का हे सेवेच्या मालकाकडून खात्री करा. भाषांतर हा प्रति-उपकरण नोंदणीची अट टाळण्याचा मार्ग नाही; सेवा प्रत्येक उपकरणाची नोंदणी मागत असेल तर तेच मॉडेल वापरा किंवा साइट-टू-साइट व्यवस्थेसाठी वाटाघाटी करा.

ती खात्री नियमाच्या शेजारी runbook मध्ये लिहा, कारण पुढील पुनरावलोकक विचारेल की रचना मंजूर होती की फक्त सोयीची.

तुटलेली स्थिती ठरवा, मग तीन विनंत्या तपासा

अपस्ट्रीम टनेल पडल्यावर काय होते ते ठरवा. जिथे बंदी आहे तिथे अधिकृत दूरचा ट्रॅफिक सामान्य WAN फॉलबॅकचा शांतपणे पाठलाग करू नये, म्हणून ओलांडण्यास परवानगी देणाऱ्या फायरवॉल धोरणानेही बंद स्थितीत अपयशी व्हावे. मग खऱ्या डाउनस्ट्रीम उपकरणावरून तीन प्रकरणे तपासा: चालणारी परवानगी असलेली विनंती, अपयशी ठरणारी परवानगी नसलेली विनंती, आणि परवानगी असलेली विनंती थांबवणारे अपस्ट्रीम अपयश.

प्रत्येक नियमासाठी एका ओळीत रोलबॅक नोंदवा, जेणेकरून हेतू पुन्हा रचल्याशिवाय बदल रद्द करता येईल.