विभाजित टनेल: तपाईंले सेट गरेको VPN बाहिर लिङ्क किन खुल्छ
राउटिङले सकेट खोल्ने प्रक्रियाको पछ्याउँछ, तपाईंलाई लिङ्क देखाएको एपको होइन। आफ्ना अपवादहरू फराकिलो बनाउनु अघि कुन प्रोग्राम जोडिन्छ भनी प्रमाणित गर्नुहोस्।
कुनै एपलाई टनेलबाट पठाउनुले त्यस एपले सुरु गर्ने सबैसम्म यसको राउटिङ लैजाँदैन, इन्टरफेसले उल्टो संकेत गरे पनि। लिङ्कले अनुरोध अर्को प्रोग्रामलाई सुम्पन्छ, त्यो प्रोग्रामले आफ्नै सकेट खोल्छ, र प्लेटफर्मले नियमहरू पाठ देखाउने प्रक्रियामा नभई नयाँ प्रक्रियामा लागू गर्छ। टनेल नीतिले वास्तवमा त्यही दोस्रो प्रक्रिया देख्छ, र त्यो तपाईंले सेट गरेको होइन।
त्यसैले समावेश गरिएको एपले टनेल बाहिर रहेको ब्राउजर खोल्न सक्छ। बहिष्कृत ब्राउजरले काम यसको भित्र रहेको एपलाई फर्काउन सक्छ। यो आश्चर्यका दुवै दिशा सामान्य व्यवहार हुन्।
कसैले सेट नगरेको कार्यप्रवाहको भाग
प्रत्येक एपको नीति कुनै कार्यान्वयनयोग्य फाइल वा प्याकेजको पहिचानविरुद्ध लेखिन्छ, र प्रत्येक जडान बन्ने क्षणमै मूल्याङ्कन गरिन्छ। ब्राउजर, कागजात दर्शक, मिडिया प्लेयर र प्रणालीको साझेदारी पाना—प्रत्येकको आफ्नै पहिचान हुन्छ, र प्रत्येकले आफ्नै निर्णय पाउँछ। गहिरो लिङ्कले डाटा बोक्छ, नीति होइन।
त्यसैले अवलोकन मनपरी लाग्छ: एउटै क्लिक कुन ह्यान्डलरले जवाफ दिन्छ भन्ने आधारमा दुई बाटो हुँदै राउट हुन्छ। टनेलभित्रको मेल क्लाइन्टले टनेल बाहिर बस्ने ब्राउजरमा लिङ्क खोल्छ, र पृष्ठ तपाईंको घरको ठेगानाबाट लोड हुन्छ। टनेल बाहिरको ब्राउजरले भित्र बस्ने दर्शकमा कागजात खोल्छ, र फाइल निकासबाट आउँछ। दुईमध्ये कुनै पनि नतिजा क्लाइन्टको दोष होइन।
पहिले नै चलिरहेको ह्यान्डलरले अवस्था बिगार्छ। ब्राउजर पहिले नै खुला छ भने, लिङ्क विद्यमान प्रक्रियाका लागि सन्देश बन्छ, र त्यो प्रक्रियाले सुरु हुँदाको राउटिङ कायम राख्छ। ह्यान्डलर बन्द गरेर फेरि खोल्दा नतिजा बदलिन्छ, र त्यसैले समस्या मागिएपटक कहिल्यै दोहोरिँदैन।
| Platform | Policy object | What it is evaluated against |
|---|---|---|
| Android | Per-app VPN allowlist | Package name of the process opening the socket |
| Windows | Application traffic filters | Application path in the filter rule |
| Linux | UID or cgroup routing rules | Owner of the socket, which can be a different program |
जडान वास्तवमा कुन प्रक्रियाले बनायो
अनुमान गर्नुको सट्टा प्राप्त गर्ने पक्ष नाप्नुहोस्। टनेल चालु राख्नुहोस्, हानिरहित लिङ्कमा क्लिक गर्नुहोस्, र नयाँ प्रोग्रामले राखेका सकेटहरू हेर्नुहोस्।
ss -tnp state established '( dport = :443 )' Get-NetTCPConnection -State Established | Select-Object RemoteAddress,OwningProcess
पहिलो आदेशले Linux मा प्रत्येक स्थापित सकेटपछाडिको प्रक्रियाको नाम दिन्छ, र दोस्रोले Windows मा मालिक प्रक्रिया पहिचान समाधान गरेर त्यही गर्छ। प्रक्रियाको नाम आफ्नो नीतिका नामसँग तुलना गर्नुहोस्। नाम ब्राउजर हो र ब्राउजर बहिष्कृत छ भने, क्लिक दोषका कारण होइन, डिजाइन अनुसारै टनेलबाट बाहिर गयो। नीतिको नियमलाई जीवित सकेटसँग मिलाउनु नै सम्पूर्ण विधि हो।
ह्यान्डलर पहिले नै चलिरहेको अवस्थामा, र त्यसपछि बन्द अवस्थामा जाँच दोहोर्याउनुहोस्। दुई नतिजा फरक हुन सक्छन्, र त्यही भिन्नताले टनेलबाट भाग्ने लिङ्कबारे अधिकांश रोकिएर आउने रिपोर्टहरू व्याख्या गर्छ।
कभरेज कार्यप्रवाहको गुण हो
कुनै काम सुरुदेखि अन्त्यसम्म टनेलभित्र रहनुपर्ने भए, त्यसले पुग्न सक्ने प्रत्येक घटक नीतिभित्र हुनुपर्छ: लन्चर, ह्यान्डलर, दर्शक, र प्लेटफर्मले तिनका बीचमा राख्ने कुनै पनि मध्यस्थ। फराकिलो कभरेज प्रायः इमानदार उत्तर हो, र प्रत्येक साझेदारी लक्ष्यको अडिट गर्नुभन्दा सस्तो पर्छ।
एउटा एप ठीक गर्न प्रणाली मध्यस्थ बहिष्कृत गर्नु सामान्य गल्ती हो। मध्यस्थहरू साझा हुन्छन्, त्यसैले बहिष्करण एउटै बाटो प्रयोग गर्ने प्रत्येक अन्य एपसम्म जान्छ, सामान्यतया हप्ताहरूपछि रिपोर्ट नआउन्जेल कसैले याद गर्दैन। घटक बहिष्कृत गर्नु अघि त्यसमा अरू के निर्भर छ पढ्नुहोस्।
पहिचानलाई राउटिङबाट अलग राख्नुहोस्। अनुरोध कुन निकासले पाउँछ भन्ने वास्ता नगरी लिङ्कले सत्र टोकन वा खाता पहिचान बोक्न सक्छ। राम्ररी राउट गरिएको क्लिकले पनि गन्तव्यलाई यो कसले पछ्यायो भनी ठ्याक्कै भन्न सक्छ।
कार्यप्रवाहको दस्तावेज बनाउनुहोस्, पहिलो चेकबक्सको होइन। जब कुनै काम चार प्रोग्रामसम्म फैलिन्छ, चार प्रोग्राम भएको रेखाचित्रले नै ट्राफिक कहाँ जान्छ भनी अनुमान गर्छ, र एकल-एप सेटिङ त्यसको एउटा मात्र पङ्क्ति हो।