कार्यालय और 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 को सुविधाजनक रखता है जबकि स्रोत-नियम अनुमान के बजाय निर्णय ही रहता है।