डाउनस्ट्रीम सबनेट बनाम डेस्कटॉप VPN: ट्रांज़िट को बाहर रखें, ऐप्स को नहीं
प्रति-ऐप बायपास केवल स्थानीय आउटपुट का वर्गीकरण करता है। वर्कस्टेशन के पीछे की डिवाइसों को अपनी इनग्रेस, फ़ॉरवर्डिंग और रिटर्न-पाथ नीति चाहिए।
एक मशीन, दो काम, एक फ़ायरवॉल: एक Wi-Fi अपलिंक, उसके पीछे छोटा Ethernet सबनेट, और एक डेस्कटॉप VPN क्लाइंट जो मानता है कि मशीन से निकलने वाला सब कुछ स्थानीय है। स्थानीय रूप से शुरू किए गए ऐप स्थानीय आउटपुट पथ से बाहर जाते हैं। वर्कस्टेशन के पीछे की डिवाइसें Ethernet पोर्ट पर आती हैं और उन्हें फ़ॉरवर्डिंग निर्णय चाहिए। पहले पथ के लिए लिखा अपवाद दूसरे को कभी नहीं देखता, और इसीलिए ब्राउज़र टनल से बचता है जबकि डिवाइसें नहीं।
दो पैकेट पथ, एक नीति
| Origin | Path | Decision owner |
|---|---|---|
| Application on the workstation | OUTPUT then egress | The VPN app's routing policy |
| Device behind the workstation | PREROUTING then FORWARD | The workstation's own forwarding policy |
पहली पंक्ति वही है जो अधिकांश split-tunneling गाइड बताते हैं। दूसरी एक राउटर कॉन्फ़िगरेशन है जो संयोग से उसी मशीन पर रहता है। दोनों को एक मानसिक मॉडल में पिघलाना ही ग़लती है; वे कर्नेल साझा करते हैं, नीति नहीं। कोई भी नियम संपादित करने से पहले दोनों पथ बनाएँ, और बाकी डिज़ाइन इससे निकलता है कि कौन-सा पथ गायब है।
तालिका यह भी बताती है कि एक ही मशीन एक परीक्षण पास क्यों कर सकती है और दूसरे में विफल क्यों। वर्कस्टेशन पर ब्राउज़र स्थानीय पथ साबित करता है; Ethernet पोर्ट में लगा लैपटॉप फ़ॉरवर्डिंग पथ साबित करता है। हर बदलाव को दोनों से जाँचें, वरना ब्राउज़र कितनी भी बार रीफ़्रेश हो, दूसरा अपरीक्षित रहता है।
ऐप अपवाद वास्तव में क्या वर्गीकृत करता है
प्रति-ऐप अपवाद आमतौर पर इस तरह काम करता है: किसी प्रोसेस या उपयोगकर्ता के पैकेट पर मार्क लगाना, और फिर मार्क किए गए ट्रैफ़िक को टनल के बाहर रूट करना। यह स्थानीय-आउटपुट संरचना है। डाउनस्ट्रीम डिवाइस के पैकेट का कोई स्थानीय प्रोसेस नहीं होता, इसलिए वह सिलेक्टर से कभी नहीं मिलता, सिलेक्टर जो भी हो।
सिलेक्टर जो भी हो, दोनों सूचियाँ एक ही सूची नहीं हैं, और पूरी बात यही है। Mullvad की Linux गाइड उन मार्कों का वर्णन करती है जिन्हें उसका फ़ायरवॉल और रूटिंग नीति खपाती है, और उसके उदाहरण स्थानीय आउटपुट को लक्षित करते हैं; वे डाउनस्ट्रीम राउटर का समर्थित वर्णन नहीं हैं। उन्हें कॉपी करने से ऐसी मशीन मिलती है जो मानती है कि उसका अपवाद है, जबकि वह सब कुछ टनल में फ़ॉरवर्ड कर रही होती है।
ट्रांज़िट अनुबंध लिखें
डाउनस्ट्रीम स्रोत प्रीफ़िक्स और इनग्रेस इंटरफ़ेस को साथ-साथ नाम दें, फिर उस प्रीफ़िक्स को इनग्रेस पर सीमित करें। सीमा के बिना, पोर्ट तक पहुँचने वाली कोई भी डिवाइस अपवादित पता दावा कर सकती है और बायपास से बाहर निकल सकती है। इसे दो प्रश्नों की तरह लें: क्या ये होस्ट इस अपलिंक का उपयोग बिल्कुल कर सकते हैं, और क्या ये वर्कस्टेशन या टनल के निजी रेंज तक पहुँच सकते हैं? ये अतिरिक्त अनुमतियाँ हैं, अपलिंक चुनाव के दुष्प्रभाव नहीं।
फ़ॉरवर्डिंग की अनुमति दें, फिर उसे फ़िल्टर करें। Linux गेटवे को फ़ॉरवर्डिंग सक्षम, दोनों दिशाओं में इच्छित ट्रैफ़िक की अनुमति देने वाले नियम, और या तो अपस्ट्रीम रिटर्न रूट या जानबूझकर सीमित स्रोत अनुवाद चाहिए। NAT अकेला अपलिंक नहीं चुनता और फ़िल्टर से पारगमन नहीं देता; वह उन निर्णयों के बाद केवल पता फिर से लिखता है।
ट्रांज़िट के लिए वर्गीकरण फ़ॉरवर्डिंग रूट निर्णय से पहले होना चाहिए, यानी output नहीं, prerouting चरण में। निर्णय के बाद रखा गया नियम पैकेट बदल सकता है, पर यह नहीं बदल सकता कि पैकेट पहले ही कहाँ भेजा जा चुका है।
मार्क उस ऐप के हैं जो उनका मालिक है
मार्क मान, तालिका संख्याएँ और चेन प्राथमिकताएँ VPN ऐप की नीति का हिस्सा हैं, शाश्वत स्थिरांक नहीं। जो नेटवर्क किसी ऐसी तालिका में नियम डालने पर निर्भर है जिसे दूसरा प्रोग्राम फिर से बनाता है, वह अगले अपडेट में टूट जाएगा, आमतौर पर सुविधाजनक समय पर नहीं बल्कि पुनः कनेक्ट के दौरान।
accept निर्णय वाली दूसरी बेस चेन जोड़ना ज़रूरी नहीं कि बाद की चेन के drop को ओवरराइड करे। बेस चेन में हुक और प्राथमिकताएँ होती हैं, और क्रम में पहला निर्णय जीतता है; एक चेन में accept उस drop को रद्द नहीं करता जहाँ दूसरी चेन पहले पहुँचती है। पूरा नियम-समूह और रूटिंग नीति का क्रम देखें, वह अकेला काउंटर नहीं जो बढ़ा। काउंटर साबित करता है कि नियम चला, कभी यह नहीं कि उसका निर्णय ही लागू हुआ।
एकीकृत करें, या सबनेट को स्थानांतरित करें
दोनों डिज़ाइन इसमें अलग हैं कि बायपास का मालिक कौन है। एकीकृत डिज़ाइन एक मशीन और एक नीति रखता है, इस कीमत पर कि वह VPN ऐप के तालिका जीवनचक्र और उन मार्कों के समूह पर निर्भर है जिन्हें उसका दस्तावेज़ बदल सकता है। डाउनस्ट्रीम नेटवर्क के लिए समर्पित राउटर उस निर्भरता को पूरी तरह हटा देता है: सबनेट का अपना अपलिंक होता है, और वर्कस्टेशन बिना फ़ॉरवर्डिंग भूमिका का क्लाइंट बना रहता है।
दूसरा चुनें जब डाउनस्ट्रीम नेटवर्क को VPN अपडेट के दौरान चलते रहना हो, या जब हर रिलीज़ के बाद कोई एकीकृत नीति का परीक्षण न कर सके। पहला केवल तब चुनें जब एकीकरण प्रलेखित हो और किसी की उस पर ज़िम्मेदारी हो।
सीमा को चार अवस्थाओं में जाँचें: जुड़ा हुआ, पुनः कनेक्ट होता, जानबूझकर अवरुद्ध और रुका हुआ। हर एक में नाम-समाधान और दोनों पता-परिवार जाँचें, क्योंकि DNS लीक करने वाला बायपास वह अपवाद नहीं है जो आपने डिज़ाइन किया। परीक्षण को सटीक सीमा साबित करनी चाहिए, केवल यह नहीं कि एक पेज लोड हुआ।