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 क्लाइन्टको होइन। सत्रको अन्त्य पनि दस्तावेज गर्नुहोस्, र प्रवेशमा रोकिएका हरेक प्रक्रिया फेरि खोल्नुभन्दा जानाजान पुनः सुरु गर्नलाई प्राथमिकता दिनुहोस्। हरेक संक्रमणको नतिजा युनिट फाइल राख्ने त्यही टिप्पणीमा लेख्नुहोस्।