कार्यालय आणि 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 सोयीचा ठेवते, तर स्रोत-नियम अंदाजाऐवजी निर्णयच राहतो।