एक मशीन, दोन कामे, एक फायरवॉल: एक Wi-Fi अपलिंक, त्यामागे लहान Ethernet सबनेट आणि मशीनमधून बाहेर जाणारे सर्व स्थानिक आहे असे गृहीत धरणारा डेस्कटॉप VPN क्लायंट. स्थानिक पातळीवर सुरू केलेले ॲप स्थानिक आउटपुट मार्गाने बाहेर पडतात. वर्कस्टेशनच्या मागील उपकरणे Ethernet पोर्टवर येतात आणि त्यांना फॉर्वर्डिंगचा निर्णय हवा असतो. पहिल्या मार्गासाठी लिहिलेली वगळणूक दुसरा मार्ग कधीच पाहत नाही, आणि म्हणूनच ब्राउझर टनेलला बगल देतो, उपकरणे देत नाहीत.

दोन पॅकेट मार्ग, एक धोरण

OriginPathDecision owner
Application on the workstationOUTPUT then egressThe VPN app's routing policy
Device behind the workstationPREROUTING then FORWARDThe workstation's own forwarding policy

पहिली ओळ बहुतेक split-tunneling मार्गदर्शकांमध्ये वर्णिली जाते. दुसरी म्हणजे त्याच मशीनवर योगायोगाने असलेले राउटर संरचना. दोन्हींना एका मानसिक प्रतिमानात विरघळवणे हीच चूक आहे; ते कर्नेल सामायिक करतात, धोरण नाही. कोणताही नियम संपादित करण्यापूर्वी दोन्ही मार्ग काढा, आणि उर्वरित रचना कोणता मार्ग गहाळ आहे यावरून येते.

एक मशीन एक चाचणी उत्तीर्ण होऊन दुसरीत का अपयशी ठरते हेही तक्ता स्पष्ट करतो. वर्कस्टेशनवरील ब्राउझर स्थानिक मार्ग सिद्ध करतो; Ethernet पोर्टमध्ये जोडलेला लॅपटॉप फॉर्वर्डिंग मार्ग सिद्ध करतो. प्रत्येक बदल दोन्हींनी तपासा, अन्यथा ब्राउझर कितीही वेळा रीफ्रेश केला तरी दुसरा तपासल्याशिवाय राहतो.

ॲप वगळणूक प्रत्यक्षात काय वर्गीकृत करते

प्रति-ॲप वगळणूक सामान्यतः अशी कार्य करते: प्रक्रिया किंवा वापरकर्त्याच्या पॅकेटवर खूण करणे, आणि नंतर खूण केलेला रहदारी टनेलबाहेर मार्गस्थ करणे. ही स्थानिक-आउटपुट रचना आहे. डाउनस्ट्रीम उपकरणाच्या पॅकेटला स्थानिक प्रक्रिया नसते, म्हणून ते निवडकाशी कधीच जुळत नाही, निवडक काहीही असो.

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

ट्रान्झिट करार लिहा

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

फॉर्वर्डिंगला परवानगी द्या, नंतर ते फिल्टर करा. Linux गेटवेला फॉर्वर्डिंग सक्रिय, दोन्ही दिशांनी इच्छित रहदारीला परवानगी देणारे नियम आणि एकतर अपस्ट्रीम परतीचा मार्ग किंवा जाणूनबुजून मर्यादित स्रोत भाषांतर हवे. NAT एकटे अपलिंक निवडत नाही आणि फिल्टरमधून जाण्यास परवानगी देत नाही; ते त्या निर्णयांनंतर केवळ पत्ता पुन्हा लिहिते.

ट्रान्झिटसाठी वर्गीकरण फॉर्वर्डिंग मार्ग निर्णयापूर्वीच घडले पाहिजे, म्हणजे output नाही तर prerouting टप्प्यात. निर्णयानंतर ठेवलेला नियम पॅकेट बदलू शकतो, पण पॅकेट आधीच कुठे पाठवले गेले आहे ते बदलू शकत नाही.

खुणा त्या ॲपच्या आहेत जो त्यांचा मालक आहे

खूण मूल्ये, तक्ता क्रमांक आणि साखळी प्राधान्ये VPN ॲपच्या धोरणाचा भाग आहेत, शाश्वत स्थिरांक नाहीत. दुसरा कार्यक्रम पुन्हा तयार करतो त्या तक्त्यात नियम घालण्यावर अवलंबून असलेले जाळे पुढील अद्ययावत करताना तुटेल, सोयीच्या वेळी नाही तर पुन्हा जोडणीच्या वेळी.

accept निवाड्यासह दुसरी आधार साखळी जोडल्याने नंतरच्या साखळीचा drop आवश्यकपणे मोडला जात नाही. आधार साखळींना हुक आणि प्राधान्ये असतात, आणि क्रमातील पहिला निवाडा जिंकतो; एका साखळीतील accept दुसरी साखळी आधी पोहोचते त्या dropला रद्द करत नाही. वाढलेला एक काउंटर नाही, संपूर्ण नियमसंच आणि राउटिंग धोरणाचा क्रम पाहा. काउंटर नियम चालला हे सिद्ध करतो, त्याचा निवाडाच लागू झाला हे कधीच सिद्ध करत नाही.

एकत्रित करा, किंवा सबनेट हलवा

दोन्ही रचना बायपास कोणाच्या मालकीचा आहे यात वेगळ्या आहेत. एकत्रित रचना एक मशीन आणि एक धोरण ठेवते, पण VPN ॲपच्या तक्ता जीवनचक्रावर आणि त्याचे दस्तऐवज बदलू शकतील अशा खुणांच्या संचावर अवलंबून राहण्याच्या किमतीने. डाउनस्ट्रीम जाळ्यासाठी समर्पित राउटर ते अवलंबन पूर्णपणे काढून टाकते: सबनेटचा स्वतःचा अपलिंक असतो, आणि वर्कस्टेशन फॉर्वर्डिंग भूमिका नसलेले क्लायंट राहते.

दुसरे निवडा जेव्हा डाउनस्ट्रीम जाळ्याने VPN अद्ययावतांमधून कार्यरत राहायचे असते, किंवा जेव्हा प्रत्येक प्रकाशनानंतर एकत्रित धोरण कोणीही तपासू शकत नाही. पहिले केवळ तेव्हाच निवडा जेव्हा एकत्रीकरण दस्तऐवजीकृत आहे आणि कोणी त्याची जबाबदारी घेतली आहे.

चार अवस्थांमध्ये सीमा तपासा: जोडलेले, पुन्हा जोडत असलेले, जाणूनबुजून अवरोधित आणि थांबवलेले. प्रत्येकात नाव-निराकरण आणि दोन्ही पत्ता कुटुंबे तपासा, कारण DNS गळती करणारा बायपास तुम्ही रचलेली वगळणूक नाही. चाचणीने नेमकी सीमा सिद्ध केली पाहिजे, केवळ एक पान लोड झाले एवढे नाही.

संबंधित लेख