सामायिक पीसीवर एक 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 नियम, प्रोफाइल परवानगी किंवा गेटवेचे सत्र धोरण. ती नोंद पुढील बदल पुनरावलोकनयोग्य करते. कोणी दुसरी लॉगिन स्क्रीन पाहिल्यावर तोच प्रश्न पुन्हा उघडण्यापासूनही ती रोखते. पोहोच ही अधिकृतता नाही, आणि त्यांपैकी कोणतेही वेगळेपण नाही.