साझा पीसी पर एक VPN लॉगिन: रूट और कौन पाता है?
VPN लॉगिन एक व्यक्ति को प्रमाणित करता है; जो रूट वह स्थापित करता है वह अलग दायरा है। साझा मशीन पर होस्ट-व्यापी, प्रति-उपयोगकर्ता और प्रति-ऐप टनल की तुलना करें।
वर्कस्टेशन साझा करना एक ऐसा प्रश्न उठाता है जिसका उत्तर एकल-उपयोगकर्ता लैपटॉप को कभी नहीं देना पड़ता: एक व्यक्ति द्वारा टनल प्रमाणित करने के बाद दूसरा कौन उसका उपयोग कर सकता है? लॉगिन एक विषय की पहचान करता है, और जो रूट वह स्थापित करता है वह एक दायरे का वर्णन करता है, और ये दोनों चीजें एक ही वस्तु नहीं हैं। इनके बीच ऑपरेटिंग सिस्टम, क्लाइंट का कॉन्फ़िगरेशन और वह सब है जो निजी सेवा स्वयं मांगती है। अनुमान लगाए बिना उत्तर देने का एकमात्र तरीका प्रवर्तन-बिंदुओं की तुलना करना है।
एक लॉगिन, कई दायरे
प्रमाणन बताता है किसे भीतर आने दिया गया। रूट बताता है कौन-से पैकेट टनल से बाहर जा सकते हैं। प्राधिकरण बताता है कौन-सी सेवा परिणामी कनेक्शन स्वीकार करेगी, और तीनों में से कोई अगले को अनिवार्य नहीं करता।
होस्ट-व्यापी टनल सामान्य डिफ़ॉल्ट है, और यह अंतर को स्पष्ट करती है। रूट कर्नेल की तालिका में बैठता है, इसलिए उस तालिका का उपयोग करने वाली हर प्रक्रिया निजी नेटवर्क तक पहुँच सकती है, यहाँ तक कि वह भी जिसे कभी VPN संवाद न देखने वाले उपयोगकर्ता ने शुरू किया हो। यह टनल में दोष नहीं है; सिस्टम-व्यापी रूट का अर्थ यही है। निजी सेवा फिर भी कनेक्शन अस्वीकार कर सकती है, इसीलिए पहुँच और अनुमति को अलग उत्तर चाहिए।
परीक्षण से पहले चार प्रश्न लिख लेने से समीक्षा उनमें से किसी एक में सिमटने से बचती है।
सीमा वास्तव में कहाँ है
चार व्यवस्थाएँ अधिकांश मशीनों को कवर करती हैं: होस्ट-व्यापी टनल, प्रति-उपयोगकर्ता कनेक्शन, प्रति-अनुप्रयोग अनुमति सूची और अलग नेटवर्क नामस्थान या वर्चुअल मशीन।
हर एक प्रवर्तन-बिंदु को अलग जगह रखती है, और लेबल से अधिक मायने अंतर के हैं। प्रति-उपयोगकर्ता कनेक्शन प्रोफ़ाइल की अनुमतियों से लागू होता है, डेस्कटॉप लॉगिन स्क्रीन से नहीं। प्रति-ऐप अनुमति सूची क्लाइंट के भीतर लागू होती है, जो तय करता है कि वह क्या ढोएगा। नामस्थान या VM इंटरफ़ेस की सीमा पर लागू करता है, इसलिए भीतर की प्रक्रिया होस्ट का रूट बिल्कुल नहीं देख सकती। मशीन पर लॉगिन स्क्रीन की संख्या इनमें से किसी के बारे में कुछ नहीं कहती।
| Arrangement | Enforced by | Who can use the path |
|---|---|---|
| Host-wide tunnel | The routing table | Any local process using that table |
| Per-user connection | Profile permission list | Only the listed accounts |
| Per-app allowlist | The VPN client itself | Only the selected applications |
| Namespace or VM | The interface boundary | Only processes inside it |
तालिका को पंक्ति-दर-पंक्ति पढ़ने से दिखता है कि असली प्रश्न यह नहीं कि अलगाव है या नहीं, बल्कि यह कि वह कहाँ लागू किया गया है।
चार प्रवर्तन-बिंदुओं की तुलना करें
Linux पर रूट तालिका पहली देखने की चीज है, क्योंकि होस्ट-व्यापी टनल वहाँ दिखती है और नामस्थान नहीं। दूसरे उपयोगकर्ता के रूप में लुकअप चलाना वह कदम है जिसे लोग छोड़ देते हैं; उत्तर उससे अलग होता है जो उन्होंने स्वयं के रूप में पाया, और यही रिपोर्ट को समझाता है।
अगली दो जाँचें रूटिंग के बजाय नीति देखती हैं। UID से मेल खाने वाला फ़ायरवॉल नियम स्थानीय रूप से उत्पन्न ट्रैफ़िक पर लागू होता है, इसलिए वह एक ही होस्ट पर दो उपयोगकर्ताओं को अलग कर सकता है, तब भी जब दोनों रूट साझा करते हों। स्पष्ट अनुमति सूची वाली कनेक्शन प्रोफ़ाइल सक्रियण के समय नेटवर्क प्रबंधक द्वारा लागू होती है। कोई भी जाँच टनल बदलने की मांग नहीं करती, इसलिए कुछ भी पुनः डिज़ाइन करने से पहले इन्हें करना उचित है।
ip route get 10.40.2.10
sudo -u bob ip route get 10.40.2.10
nmcli connection show vpn-work | grep -i permission
sudo nft list ruleset | grep -n skuidयदि दूसरा लुकअप टनल का रूट दिखाता है, तो सीमा वहाँ नहीं है जहाँ डिज़ाइन ने माना था।
समवर्ती-सत्र नियम एक अलग नियंत्रण हैं
गेटवे अक्सर सीमित करते हैं कि एक खाता कितने सत्र रख सकता है, और उस सीमा का स्थानीय उपयोगकर्ताओं से कोई संबंध नहीं है। यह खाते को सीमित करती है, इसलिए वही क्रेडेंशियल लेकर साइन इन करने वाला दूसरा व्यक्ति पहले व्यक्ति की टनल समाप्त कर सकता है।
स्थानीय अलगाव की समस्या मानने से पहले विफलता पढ़ें। सत्र सीमा गेटवे पर डिस्कनेक्ट उत्पन्न करती है, जबकि दायरे की समस्या एक काम करती टनल उत्पन्न करती है जो बस दूसरे उपयोगकर्ता का ट्रैफ़िक नहीं ढोती। ये दो लक्षण पूरी तरह अलग सुधारों की ओर ले जाते हैं। क्लाइंट का सटीक संदेश रखें, क्योंकि वह आमतौर पर नियम का नाम बताता है। सीमा से बचने के बजाय प्रोफ़ाइल स्वामी से स्वीकृत कार्यप्रवाह मांगें।
वर्चुअल मशीन किसी को उस नियम से मुक्त नहीं करती, और वह अपना नेटवर्क और क्रेडेंशियल डिज़ाइन जोड़ती है।
जिस संदर्भ की आपको परवाह है उसका परीक्षण करें
इच्छित उपयोगकर्ता और ऐप का परीक्षण करें, फिर ऐसे संदर्भ का जिसे अस्वीकार होना चाहिए। जो समीक्षा केवल यह सिद्ध करती है कि मूल पासवर्ड काम करता है, उसने प्रमाणन का परीक्षण किया और कुछ नहीं।
sudo -u bob curl -sS -m 5 https://intranet.internal/health
wg show
ss -tnp | grep -E ':443|:51820'हर परिणाम के बगल में प्रवर्तन-बिंदु दर्ज करें: रूट तालिका, UID नियम, प्रोफ़ाइल अनुमति या गेटवे की सत्र नीति। वह रिकॉर्ड अगले बदलाव को समीक्षायोग्य बनाता है। यह हर बार किसी के दूसरी लॉगिन स्क्रीन देखने पर वही प्रश्न दोबारा खुलने से भी रोकता है। पहुँच प्राधिकरण नहीं है, और इनमें से कोई भी अलगाव नहीं है।