VPN चालू रहते ऐप नहीं चलना चाहिए: इसे कौन लागू करता है

kill switch और ओवरलैप-निषेध के नियम विपरीत दिशाओं में इशारा करते हैं, इसलिए सामान्य VPN सेटिंग्स कभी दूसरे को व्यक्त नहीं करतीं। kill switch गिरी हुई टनल पर प्रतिक्रिया देता है, जबकि यह आवश्यकता ऊपर रहती टनल पर प्रतिक्रिया देती है और ऐप को तस्वीर से बाहर रखती है। एक डिज़ाइन निर्णय अधिकांश हल कर देता है: ऐप रोका जाए, उसे शुरू होने से रोका जाए, या सिर्फ़ नेटवर्क पहुँच छीन ली जाए। फ़ायरवॉल नियम या प्रोसेस मारने वाले लूप की ओर बढ़ने से पहले वह परत चुनें, क्योंकि निरीक्षण से लागू नियम हर लॉन्च पर एक खिड़की चूक जाता है।

भ्रम: kill switch प्रोग्राम शुरू होने से रोकता है

kill switch ट्रैफ़िक नियंत्रण हैं, और वे इसमें ईमानदार हैं: टनल की स्थिति के अनुसार पैकेट की अनुमति या अस्वीकृति देते हैं। उनमें से कोई प्रोग्राम शुरू करने से इनकार नहीं करता, और कोई यह नहीं जाँचता कि किस निष्पादन योग्य फ़ाइल ने सॉकेट खोला। डेस्कटॉप शॉर्टकट, शेड्यूल किया गया कार्य और पृष्ठभूमि सहायक—सभी ऐप का नाम जानने वाली किसी चीज़ से गुज़रे बिना नेटवर्क तक पहुँचते हैं। इन दो तंत्रों के बीच की दूरी वही जगह है जहाँ अधिकांश भ्रम रहता है।

प्रोग्राम शुरू हो सकता है या नहीं, यह वास्तव में तय करने वाली व्यवस्था एप्लिकेशन नियंत्रण है। Windows पर इसका अर्थ AppLocker या WDAC है, और प्रबंधित macOS पर डिवाइस प्रोफ़ाइल द्वारा लागू अनुमति सूची। दोनों टनल से स्वतंत्र हैं, इसीलिए दोनों आवश्यकताएँ एक ही टिकट में मिला दी जाती हैं और फिर कोई भी पूरी नहीं होती।

औज़ार का नाम लेने से पहले मोड का नाम लें

नियम को तीन अवस्थाओं वाली स्टेट मशीन के रूप में लिखें: सामान्य उपयोग, VPN कार्य सत्र और प्रस्थान। निषिद्ध ओवरलैप बीच की अवस्था का है, क्लाइंट सॉफ़्टवेयर का नहीं।

जो अवस्था बदलता है, उसके पास क्रम में तीन क्रियाएँ हैं: ऐप का काम पूरा करना, उसका सामान्य बंद होना माँगना, और टनल ऊपर आने से पहले इंस्टेंस के चले जाने की पुष्टि करना। दूसरे सिरे पर भी क्रम मायने रखता है, क्योंकि पहले जुड़ने और बाद में प्रोग्राम रोकने वाला VPN ओवरलैप की अनुमति दे चुका है। अगर आवश्यकता कनेक्शन स्थापित करने को भी शामिल करती है, तो जुड़े होने के संकेतक की प्रतीक्षा बहुत देर है।

दो-तरफ़ा टकराव वास्तव में क्या करता है

वास्तव में systemd द्वारा प्रबंधित दो सेवाओं के लिए Conflicts= सममित है: एक शुरू करने से दूसरी रुक जाती है। यूनिट संदर्भ इस व्यवहार का दस्तावेज़ीकरण करता है और अलग से स्पष्ट क्रम माँगता है जब एक को दूसरी के शुरू होने से पहले रुकना पूरा करना हो। उन क्रम-प्रविष्टियों के बिना रुकना और शुरू होना होड़ करते हैं, और परिणाम समय पर निर्भर करता है।

यह अस्वीकृति सूची नहीं है। निर्भरता उलटी जोड़ें तो ऐप शुरू होने से उलटा VPN रुक जाएगा, और यही वह खराबी है जिस पर संदेह करना चाहिए जब टनल किसी पूर्वानुमेय क्षण पर अपने आप डिस्कनेक्ट हो जाए। डेस्कटॉप एप्लिकेशन systemd यूनिट नहीं है, और NetworkManager कनेक्शन भी यूनिट नहीं है, इसलिए यह पैटर्न केवल उन सेवाओं के लिए काम करता है जिन्हें आप स्वयं लपेटते हैं।

सिर्फ़ पहला लॉन्च नहीं, संक्रमण जाँचें

चार संक्रमण तय करते हैं कि आवश्यकता टिकती है या नहीं: ऐप चालू रहते सत्र में प्रवेश, सत्र के बीच में उसे फिर शुरू करना, असफल VPN शुरुआत, और जानबूझकर डिस्कनेक्ट। हर एक को जाँचें और परिणाम यूनिट फ़ाइलों के पास रखें। नीचे के आदेश वर्तमान संबंध पढ़ते हैं और फिर सबसे महत्वपूर्ण संक्रमण का अभ्यास करते हैं।

systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active

तीसरे आदेश को ऐप निष्क्रिय छोड़ना चाहिए, और चौथे को सत्र चलते समय केवल टनल कनेक्शन सूचीबद्ध करना चाहिए। अलग परिणाम का अर्थ है कि संक्रमण बिलकुल लागू नहीं होता।

सत्र के दौरान फिर से शुरू करना वही मामला है जो लपेटे-आधारित डिज़ाइन को उजागर करता है, क्योंकि डेस्कटॉप से शुरू किया गया शॉर्टकट कभी लॉन्चर स्क्रिप्ट से सलाह नहीं लेता। अगर यह बाईपास मायने रखता है, तो प्रवर्तन एप्लिकेशन नियंत्रण का है, VPN क्लाइंट का नहीं। सत्र का अंत भी दस्तावेज़ करें, और प्रवेश के समय रोके गए हर प्रक्रिया को फिर खोलने के बजाय जानबूझकर पुनः आरंभ को प्राथमिकता दें। हर संक्रमण का परिणाम उसी नोट में दर्ज करें जिसमें यूनिट फ़ाइलें रहती हैं।