कार्यालय र VPN का लागि एउटै URL? अनुमति सूचीको मिथक किन असफल हुन्छ
VPN जडानले अनुमति सूचीमा रहेको साइटले देख्ने ठेगाना बदल्दैन। URL थप्नु अघि वास्तविक एग्रेस, विश्वसनीय प्रोक्सी हप र IPv6 मार्ग जाँच गर्नुहोस्।
टनेल जोड्नुहोस्, त्यही बुकमार्क खोल्नुहोस्, र अनुमति सूचीको साइट कार्यालयबाट जस्तो जवाफ दिन्थ्यो ठ्याक्कै त्यस्तै जवाफ दिन्छ। यही त्यो अनुमान हो जसमा अधिकांश दूरस्थ-पहुँच योजनाहरू चुपचाप टेक्छन्, र तीनवटा छुट्टै कुरा एकै समयमा सत्य रहेसम्म मात्र त्यो टिक्छ। तीमध्ये कुनै पनि VPN क्लाइन्टको विशेषता होइन, र कुनै DNS रेकर्डले तीमध्ये एउटा पनि दिन सक्दैन। घरमा बुकमार्क असफल हुँदा ब्राउजरले तपाईंलाई एउटा सामान्य त्रुटि दिन्छ, कारण हराएको मार्ग होस्, अस्वीकृत एग्रेस ठेगाना होस् वा जुन स्रोतको रिपोर्ट गर्छ त्यसलाई बदलेको प्रोक्सी होस्। ती तीनलाई एउटै समस्या मान्नु नै सानो नीति-सुधार अनुमति सूची फराकिलो बनाउने एक हप्तामा बदलिने बाटो हो।
वास्तविक कार्यालय सञ्जालसँगको सम्पर्कमा टिक्ने डिजाइन अनुमानभन्दा साँघुरो छ: तीन पंक्तिको स्पष्ट निर्णय तालिका, एउटा कार्यान्वयन बिन्दु जसलाई छल्न सकिँदैन, र केही प्रमाणित गर्ने अस्वीकृति परीक्षण। अनुमान भत्काउने काम पहिले आउँछ, किनकि त्यसपछिको सबै कुरा कुन तहले स्रोतलाई गलत रूपमा प्रस्तुत गरिरहेको छ भन्ने जान्नमा निर्भर छ।
मिथक: जोडिनु मार्गन होइन
एउटा टनेल स्थापना हुन्छ, र क्लाइन्टले केही प्रिफिक्सका लागि मार्गहरू स्थापना गर्छ। जोडिनु भन्नाले यत्ति मात्र गर्छ। असम्बन्धित HTTPS अनुरोध टनेलबाट जान्छ कि जाँदैन, र पुग्दा कुन सार्वजनिक ठेगानाबाट आएको जस्तो देखिन्छ, यी निर्णय पछि अरू घटकहरूले लिन्छन्: मार्ग तालिकाले बाटो छान्छ, र एग्रेसले स्रोत छान्छ।
त्यही कारण एउटै ल्यापटप, एउटै ब्राउजर प्रोफाइल र एउटै बुकमार्कका साथ कार्यालय र भान्साको टेबुल फरक पर्छन्। कार्यालयमा अनुरोध साइट सञ्चालकले सहमति दिएको हेरचाह गरिएको सार्वजनिक ठेगानाबाट बाहिरिन्छ। पूर्ण टनेलबाट यो VPN एग्रेसबाट बाहिरिन सक्छ, जुन फरक ठेगाना हो र कसैले थपेसम्म अस्वीकृत। विभाजित टनेलबाट यो टनेलभित्र पटक्कै नपर्न सक्छ। ती तीन मार्गमध्ये दुईवटा मात्र कहिल्यै साइट-मालिकसँगको सम्झौताको भाग थिए, र तेस्रो थप allow प्रविष्टिले टाल्नुपर्ने खोट होइन।
तीन अनुरोध अवस्था, दुई स्वीकृत एग्रेस
फायरवाल छुनु अघि म्याट्रिक्स लेख्नुहोस्, किनकि तालिका नै डिजाइन हो र नियम त्यसको एउटा मात्र कार्यान्वयन। तलका ठेगानाहरू कागजात श्रेणी हुन्; तिनलाई आफ्नै हेरचाह गरिएका मानहरूले बदल्नुहोस् र साइट-मालिकले जाँच गर्न सक्ने ठाउँमा राख्नुहोस्।
| Request path | Source the site sees | Intended decision |
|---|---|---|
| Office, no tunnel | Office public exit | Admit to the application login |
| Remote, approved full tunnel | Approved VPN egress | Admit to the same login |
| Remote, ordinary connection | Neither approved address | Deny at the network boundary |
यी योजनाहरूमध्ये अधिकांश बीचको पंक्तिमा टुट्छन्। महत्त्वपूर्ण कुरा कार्यान्वयन गर्ने यन्त्रले देख्ने ठेगाना हो, ल्यापटपले टनेलभित्र राख्ने निजी ठेगाना होइन र त्यसको LAN ठेगाना पनि होइन। 10.8.0.6 जस्तो मान सार्वजनिक साइटका लागि केही अर्थ राख्दैन, 192.168.1.44 पनि राख्दैन। टनेलको ठेगाना टनेलको ठेगाना-व्यवस्थाको विवरण हो, साइटले जाँच गर्न सक्ने कुनै प्रमाणपत्र होइन।
तपाईंको VPN ले स्थिर, कागजातीय एग्रेस दिन सक्दैन भने म्याट्रिक्समा कुनै वैध बीचको पंक्ति छैन र जतिसुकै अनुमति सूचीले एउटा बनाउँदैन। त्यस क्षणका इमानदार विकल्पहरू स्पष्ट निजी मार्गबाट पुगिने निजी साइट, वा अनुप्रयोगको अगाडि पहिचान-सचेत पहुँच गेटवे हुन्। दुवैको सार्वजनिक अनुमति सूचीभन्दा फरक करार छ, र दुवैलाई लेखापरीक्षकलाई बुझाउनु त्यो सूचीभन्दा सजिलो छ जुन संयोगले काम गर्न थालेसम्म बढ्दै गयो।
निर्णय लिइने ठाउँमै स्रोत पढ्नुहोस्
प्रतिबन्ध त्यो यन्त्रमा राख्नुहोस् जसले अनुरोध अन्त्य गर्छ, र कुनै वैकल्पिक उत्पत्ति मार्गले त्यसलाई छल्दैन भनी पुष्टि गर्नुहोस्। Nginx पहुँच मोड्युल ले allow र deny निर्देशनहरूलाई क्रममा मूल्याङ्कन गर्छ, पहिलो मिलान जित्छ, र घेर्ने ब्लकबाट उत्तराधिकारमा आएका नियमहरू location भित्र अझै लागू हुन्छन्। एउटै ठाउँमा साँघुरो allow को छेउमा फराकिलो allow हुँदा सामान्यतया फराकिलोले निर्णय गर्छ। त्यस location को एक पंक्ति पनि सम्पादन गर्नु अघि त्यसको पूरा प्रभावकारी कन्फिगरेसन पढ्नुहोस्।
server {
listen 443 ssl;
server_name intranet.example.com;
set_real_ip_from 10.20.0.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
location /app/ {
allow 203.0.113.24; # office public exit
allow 198.51.100.77; # approved VPN egress
deny all;
proxy_pass http://app_backend;
}
}लोड ब्यालेन्सर वा रिवर्स प्रोक्सीको पछाडि त्यो नियमले प्रोक्सीलाई देख्छ, जबसम्म तपाईंले अरू केही भन्नुहुन्न। कलरको ठेगाना समर्थित विश्वसनीय-प्रोक्सी संयन्त्रबाट मात्र, प्रोक्सी ठेगानाको स्पष्ट सूचीसहित पुनःस्थापित गर्नुहोस्। स्वीकृत ठेगाना दाबी गर्ने अनुरोध हेडर कलरले त्यसको स्वामित्व राख्छ भन्ने प्रमाण होइन, र सार्वजनिक श्रोतामा नजाँचिएको अग्रेषित हेडरले अनुमति सूचीलाई सजावट बनाउँछ।
त्यसपछि अर्को ठेगाना परिवार जाँच्नुहोस्। केवल IPv4 समेट्ने नियम-समूह AAAA मा पनि जवाफ दिने होस्टनामका लागि अपूर्ण निर्णय हो, र कार्यरत IPv6 भएको क्लाइन्ट त्यही अनुप्रयोगमा तपाईंले कहिल्यै समीक्षा नगरेको मार्गबाट पुग्छ।
विभाजित टनेल: कहिल्यै भित्र नपर्ने अनुरोध
विभाजित टनेलले आफ्नो सूचीमा भएका प्रिफिक्स मात्र बोक्छ। कार्यालयका आन्तरिक सबनेट सामान्यतया त्यो सूचीमा पर्छन्; सार्वजनिक वेबसाइट पर्दैन। ब्राउजरले नाम समाधान गर्छ, छानिएको ठेगानालाई मार्ग तालिकासँग तुलना गर्छ, र तैपनि अगाडि स्थानीय पूर्वनिर्धारित गेटवे भेट्छ।
यसरी अनुरोध प्रयोगकर्ताको घरको जडानबाट आउँछ, अस्वीकृत हुन्छ, र प्रतिवेदनले VPN बिग्रिएको भन्छ जबकि टनेल ठ्याक्कै जसका लागि कन्फिगर गरिएको थियो त्यही गरिरहेको हुन्छ। दुई सुधार वैध छन्: त्यो गन्तव्यलाई टनेलबाट पठाउनुहोस् र स्वीकृत एग्रेसले बोक्न दिनुहोस्, वा साइटमा सिधै पुगिन्छ भनी स्वीकार गरी दूरस्थ प्रयोगकर्तालाई पहुँच गेटवेजस्तो अर्को स्वीकृत मार्ग दिनुहोस्। घरको ठेगाना संयोगले समावेश नहुनेसम्म साइटको सार्वजनिक अनुमति सूची फराकिलो बनाउनु ती दुईमध्ये कुनै होइन, र यसले डिजाइनले लागू गर्नुपर्ने सीमा हटाउँछ। पहिला दुईले म्याट्रिक्सलाई इमानदार राख्छन्; तेस्रोले त्यसबाट एक पंक्ति चुपचाप मेटाउँछ।
अस्वीकृति प्रमाणित गर्नुहोस्, त्यसपछि पुनःप्राप्ति
तालिकाको हरेक पंक्तिमा उभिएको क्लाइन्टबाट वास्तविक निर्णय प्रयोग गर्ने अनुरोधले परीक्षण गर्नुहोस्। असम्बन्धित कुनै ठेगाना देखाउने पृष्ठसँगको पहुँच-जाँचले केही प्रमाणित गर्दैन, किनकि त्यो गन्तव्य अनुप्रयोगभन्दा फरक मार्ग लिन सक्छ।
curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'सीमानाको पहुँच रेकर्डलाई तालिकाले अनुमान गरेको कुरासँग तुलना गर्नुहोस्। त्यसपछि टनेल तल झार्नुहोस् र अस्वीकृत हुनुपर्ने नयाँ अनुरोध गर्नुहोस्; पहिले नै लोड भएको पृष्ठ वा पहिले नै खुलेको जडानले केही पनि परीक्षण गर्दैन। यदि कुनै अस्वीकृति देखिएन भने कार्यान्वयन बिन्दु तपाईंले सोचेको ठाउँमा छैन।
सञ्जालमा प्रवेशपछि पनि अनुप्रयोग प्रमाणीकरण राख्नुहोस्, किनकि कार्यालय एग्रेस र VPN एग्रेस दुवैले धेरै मानिसको प्रतिनिधित्व गर्छन् र कुनैले पनि व्यक्तिलाई चिन्न सक्दैन। प्रयोगकर्ताका लागि निर्देशन छोटो रहन्छ: स्वीकृत टनेल उठाउनुहोस्, त्यसपछि फेरि प्रयास गर्नुहोस्। यसैले एउटा URL सुविधाजनक राख्छ, जबकि स्रोत-नियम अनुमानको सट्टा निर्णय नै रहन्छ।