विभाजित बोगदा: तुम्ही सेट केलेल्या 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 वर मालक प्रक्रिया ओळख सोडवून तेच करतो. प्रक्रियेचे नाव तुमच्या धोरणातील नावांशी तुलना करा. जर नाव ब्राउझर असेल आणि ब्राउझर वगळलेला असेल, तर क्लिक दोषामुळे नव्हे, तर रचनेनुसार बोगद्याबाहेर गेले. धोरणाचा नियम जिवंत सॉकेटशी जुळवणे हीच संपूर्ण पद्धत.
हँडलर आधीच चालू असताना, आणि नंतर तो बंद असताना तपासणीची पुनरावृत्ती करा. दोन्ही निकाल वेगळे असू शकतात, आणि तोच फरक बोगद्यातून सुटणाऱ्या दुव्यांबद्दलच्या बहुतेक अधूनमधून येणाऱ्या अहवालांचे स्पष्टीकरण देतो.
व्याप्ती हा कामाच्या प्रवाहाचा गुणधर्म आहे
एखादे काम सुरुवातीपासून शेवटपर्यंत बोगद्यात राहायचे असेल, तर ते जिथपर्यंत पोहोचू शकते ते प्रत्येक घटक धोरणात असणे आवश्यक आहे: लाँचर, हँडलर, व्यूअर, आणि प्लॅटफॉर्म त्यांच्यामध्ये घालणारा कोणताही मध्यस्थ. व्यापक व्याप्ती हे अनेकदा प्रामाणिक उत्तर असते, आणि प्रत्येक शेअर लक्ष्याचे ऑडिट करण्यापेक्षा ते स्वस्त पडते.
एक ॲप दुरुस्त करण्यासाठी सिस्टम मध्यस्थ वगळणे ही सामान्य चूक आहे. मध्यस्थ सामायिक असतात, म्हणून वगळणे तोच मार्ग वापरणाऱ्या इतर प्रत्येक ॲपपर्यंत जाते, सहसा आठवड्यांनंतर अहवाल येईपर्यंत कोणाच्याही लक्षात येत नाही. घटक वगळण्यापूर्वी त्यावर आणखी काय अवलंबून आहे ते वाचा.
ओळख राउटिंगपासून वेगळी ठेवा. विनंती कोणत्या एक्झिटला मिळते याची पर्वा न करता दुवा सत्र टोकन किंवा खाते ओळख वाहू शकतो. योग्यरीत्या राउट केलेले क्लिकही गंतव्यस्थानाला ते कोणी अनुसरले हे नक्की सांगू शकते.
कामाचा प्रवाह दस्तऐवजीकृत करा, पहिला चेकबॉक्स नाही. जेव्हा एखादे काम चार प्रोग्रामांपर्यंत पसरते, तेव्हा चार प्रोग्राम असलेला आकृतीच ट्रॅफिक कुठे जाईल हे भाकीत करतो, आणि एकल-ॲप सेटिंग ही त्याची फक्त एक ओळ असते.