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