साझा पीसीमा एउटा 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 नियम, प्रोफाइल अनुमति वा गेटवेको सत्र नीति। त्यो अभिलेखले अर्को परिवर्तनलाई समीक्षायोग्य बनाउँछ। कसैले दोस्रो लगइन स्क्रिन देख्दा त्यही प्रश्न फेरि खुल्नबाट पनि यसले रोक्छ। पहुँच अधिकार होइन, र तीमध्ये कुनै पनि अलगाव होइन।