एकच सर्व्हर IP, दोन मार्ग: OpenVPN चा बाह्य प्रवाह चिन्हांकित करणे

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

जे दोन प्रवाह वेगळे करायचे आहेत त्यांच्यापासून सुरुवात करा

एक प्रवाह म्हणजे एन्क्रिप्टेड OpenVPN वाहतूक स्वतः, जी अपलिंकमधून बाहेर जायला हवी, अन्यथा टनेल स्वतःचे बाह्य कनेक्शन वाहून नेईल। दुसरा म्हणजे त्याच सार्वजनिक पत्त्यावरची साधी HTTPS विनंती, जी तुम्हाला टनेलमध्ये हवी आहे जेणेकरून ती टनेल स्रोताकडून सेवेपर्यंत पोहोचेल। तेच गंतव्यस्थान, अनेकदा तोच पोर्ट क्रमांक, वेगळा आवश्यक मार्ग।

या स्पष्टीकरणात असे गृहीत धरा की 10.90.0.10 वरचा क्लायंट tun1 मधून जोडलेला आहे, सर्व्हरचा सार्वजनिक पत्ता 198.51.100.25 आहे, आणि मुख्य तक्ता अस्पर्शित आहे ज्याचा डीफॉल्ट मार्ग नेहमीच्या अपलिंककडे जातो। सर्व्हरच्या बाजूला आतील मार्गावर वेब सेवा स्वीकारावी लागते आणि रहदारी टनेल स्रोताकडे परत पाठवावी लागते; सार्वजनिक पत्त्यावर पॅकेट पाठवणे सर्व्हरचा लिसनर किंवा फायरवॉल धोरण रद्द करत नाही।

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

लिफाफा वाहून नेणाऱ्या सॉकेटला चिन्हांकित करा

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

mark 42
route-noexec
disable-dco

दशांश 42 हे हेक्साडेसिमल 0x2a आहे, आणि हेक्स स्वरूप हेच राउटिंग नियम जुळवतील। link-options चा संदर्भ mark ला Linux वर एन्क्रिप्टेड आउटगोइंग पॅकेटवर लागू होणारी गोष्ट म्हणून वर्णन करतो, म्हणजे नेमके तेच सॉकेट ज्याचा मार्ग तुम्हाला नियंत्रित करायचा आहे। डेटा चॅनलचा ऑफलोड बंद केल्यास हे उदाहरण वापरकर्ता-स्पेस मार्गावर राहते, जिथे चिन्हाचे वर्तन वर्णन केलेले आहे।

route-noexec OpenVPN चे मार्ग आपोआप जोडणे आणि काढणे दाबून टाकते। ते त्यांच्या जागी काहीही स्थापित करत नाही, म्हणून या क्षणापासून मार्गांच्या मालकाला टनेलला लागणारा प्रत्येक मार्ग सांभाळावा लागतो। बदलानंतर एखादे खासगी गंतव्यस्थान गायब झाले, तर ते गहाळ बदली धोरण आहे, चिन्हातील दोष नाही।

हे करताना 198.51.100.25 साठी मुख्य तक्त्यात होस्ट मार्ग ठेवू नका। असा मार्ग हीच सूट परत आणतो जी रचना मर्यादित करू पाहते, आणि खालीलपैकी कोणत्याही धोरणाला विचारण्यापूर्वी तो HTTPS प्रवाहासाठी जिंकेल।

बाकी सर्व टनेल तक्त्यात पाठवा

टनेल इंटरफेस अस्तित्वात येऊन त्याचा पत्ता धारण केल्यावर धोरण असे दिसते:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

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

चिन्ह नसलेली रहदारी नंतर टनेल तक्त्यात पडते, टनेल स्रोत घेते आणि VPN मधून बाहेर पडते। चिन्हांकित रहदारी पुढील दोन नियमांवरील fwmark चाचणीत अपयशी ठरते आणि यादीत खाली असलेल्या नेहमीच्या मुख्य शोधाकडे पुढे जाते, जिथे अपलिंकचा डीफॉल्ट मार्ग अजूनही आहे। शेवटचा unreachable नियम तोच आहे जो टनेल मार्ग नसताना चिन्ह नसलेल्या प्रवाहाला शांतपणे अपलिंकवर परत पडण्यापासून रोखतो। निवडकर्ता सुरुवातीपासून शेवटपर्यंत चिन्ह आहे, आणि गंतव्य पत्ता कधीही निर्णयात येत नाही।

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

परतीच्या मार्गाला तेच चिन्ह दिसू द्या

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

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

सैल परतीचा-मार्ग तपासणीही पर्याय नाही। सैल मोडमध्येही स्रोतासाठी काही मार्ग असणे आवश्यक आहे, आणि तुम्ही जोडलेला unreachable रक्षक चिन्ह नसलेल्या शोधांसाठी मुद्दाम एक काढून टाकतो। या रचनेवर विसंबून राहण्यापूर्वी कनेक्शन-चिन्ह एकत्रीकरण पूर्ण करून त्याचे पुनरावलोकन करा, आणि होस्ट फिल्टर स्वतंत्र प्रश्न माना: चिन्ह हे राउटिंग संकेत आहे, परवानगी नाही। एकत्रीकरण नसल्यास लक्षण असे की सत्र स्थापित होते आणि उत्तरे येऊ लागताच शांत होते।

दोन मार्ग शोधांनी हे सिद्ध करा

कर्नेल दोन संदर्भांसाठी काय ठरवते याची तुलना करा, आणि निर्गम स्थितीऐवजी dev आणि src फील्ड वाचा:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

पहिला शोध टनेल स्रोतासह tun1 वर सुटला पाहिजे, आणि दुसरा अपलिंकवर। हे कृत्रिम शोध आहेत, म्हणून ते धोरण सिद्ध करतात, चालू प्रक्रिया नाही: चालू क्लायंटचा प्रत्यक्ष वाहतूक मार्ग वेगळा पुष्टी करा, नंतर प्रमाणपत्र पडताळणी सुरू ठेवून खरी HTTPS विनंती करा।

पूर्ण जाहीर करण्यापूर्वी रचना काय व्यापत नाही ते लिहा। DNS, IPv6 आणि नियमांचे जीवनचक्र प्रत्येकाला स्वतःचा निर्णय लागतो, आणि हे IPv4 राउटिंगचे उदाहरण आहे, संपूर्ण गोपनीयता कॉन्फिगरेशन नाही। त्याचे मूल्य निवडकर्ता आहे: लिफाफ्याला अपलिंकची सूट मिळते, आणि त्याच पत्त्यावरील साध्या सेवेला ती वारसाहक्काने घ्यायची गरज नाही।