एउटा मेसिन, दुई काम, एउटा फायरवाल: एउटा 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 चुहाउने बाइपास तपाईंले डिजाइन गरेको अपवाद होइन। परीक्षणले ठ्याक्कै सीमा प्रमाणित गर्नुपर्छ, एउटा पृष्ठ लोड भयो भन्ने मात्र होइन।

सम्बन्धित लेखहरू