AWS Client VPN: लॉगिन सफल होता है, पर सबनेट तक पहुँच नहीं बनती

आपका क्लाइंट Connected दिखाता है, प्रमाणपत्र वैध है, और इंट्रानेट पेज फिर भी समय-समाप्ति पर रुकता है। यह अंतर लगभग कभी प्रमाणीकरण नहीं होता। AWS Client VPN लॉगिन से अलग गंतव्यों को प्राधिकृत करता है, और सामान्यतः दो कारण होते हैं: ऐसा समूह मान जो पहचान प्रदाता द्वारा भेजे गए मान से मेल न खाए, और अधिक विशिष्ट गंतव्य नियम जो व्यापक नियम को हरा दे। दोनों endpoint कॉन्फ़िगरेशन में दिखते हैं, बस यह जानना ज़रूरी है कि कहाँ देखना है।

लॉगिन सफल हुआ; नियम मेल नहीं खाया

प्रमाणीकरण बताता है कि उपयोगकर्ता कौन है। प्राधिकरण नियम बताते हैं कि वह पहचान किन नेटवर्क प्रीफ़िक्स तक पहुँच सकती है। उपयोगकर्ता पहला पास कर सकता है और दूसरे में विफल हो सकता है, और क्लाइंट आपको ऐसा कनेक्शन देता है जो बना रहता है जबकि हर अनुरोध समय-समाप्ति पर पहुँचता है।

यह पुष्टि करके शुरू करें कि endpoint के पास ऐसा प्राधिकरण नियम है जिसका गंतव्य विफल हो रहे पते को शामिल करता है। यदि कोई मेल खाता नियम नहीं है, तो कनेक्शन सही व्यवहार कर रहा है; नीति का अभाव है।

समूह मान वास्तव में कहाँ से आता है

Active Directory में access-group फ़ील्ड समूह का SID रखता है, उसका प्रदर्शन नाम नहीं। SAML फ़ेडरेशन में यह वह समूह ID या नाम रखता है जो कॉन्फ़िगर किया गया SAML समूह एट्रिब्यूट वास्तव में ले जाता है। मान को assertion या डायरेक्टरी लुकअप से कॉपी करें, विकी पेज से नहीं।

IAM समूह एक अलग नियंत्रण तल है। Client VPN endpoint का प्रशासन करने की अनुमति IAM समूह को उपयोगकर्ता का VPN समूह नहीं बनाती, और access-group फ़ील्ड में IAM समूह का नाम चिपकाने से वह AD SID या SAML एट्रिब्यूट मान में नहीं बदलता।

किसी दूसरी डायरेक्टरी में मिलते-जुलते नाम का समूह कुछ सिद्ध नहीं करता। endpoint की प्रमाणीकरण विधि और उसी सिस्टम में उपयोगकर्ता की सदस्यता या assertion जाँचें।

सबसे लंबा प्रीफ़िक्स जीतता है, 0.0.0.0/0 सहित

प्राधिकरण सबसे लंबे प्रीफ़िक्स मेल से आँका जाता है, और सभी गंतव्यों का नियम पहले नहीं बल्कि अंत में आँका जाता है। Engineering के लिए 10.46.0.0/16 नियम और सबके लिए 0.0.0.0/0 नियम जोड़ें, फिर भी Engineering से बाहर का उपयोगकर्ता व्यापक नियम से 10.46.20.10 तक नहीं पहुँच पाएगा।

यहीं सुधार गलत हो सकता है। संकीर्ण नियम हटाने से उपयोगकर्ता की पहुँच लौट आती है और वह सबनेट हर उस पहचान को भी मिल जाता है जिसे व्यापक नियम कवर करता है। कुछ भी हटाने से पहले समूह-से-नेटवर्क मैट्रिक्स बनाएँ और लिखें कि किन समूहों को किस रेंज तक पहुँचना है। ये नियम केवल अनुमति देते हैं; व्यापक अनुमति में से अपवाद काटने के लिए कोई निषेध प्रविष्टि नहीं है।

बदलावों को न्यायपूर्ण ढंग से आँकने के लिए नया कनेक्शन भी चाहिए। नियम संपादित करने के बाद क्लाइंट को फिर से जोड़ें, फिर दोबारा परीक्षण करें।

प्राधिकरण को डेटा पथ से अलग रखें

मेल खाता नियम कोई मार्ग नहीं है. endpoint को जुड़ा हुआ सबनेट और गंतव्य के लिए रूट तालिका प्रविष्टि चाहिए, और लक्ष्य संसाधन के सुरक्षा समूह को ट्रैफ़िक स्वीकार करना चाहिए। वापसी ट्रैफ़िक और DNS भी काम करने चाहिए।

ऐसे उपयोगकर्ता का परीक्षण करें जिसे सफल होना चाहिए और ऐसे उपयोगकर्ता का जिसे बाहर रहना चाहिए। दोनों लॉगिन कर सकते हैं जबकि केवल एक सबनेट तक पहुँचता है, और यही अंतर वह साक्ष्य है जो आप चाहते हैं।

यदि IP पता काम करता है पर होस्टनाम नहीं, तो प्राधिकरण छूने से पहले resolver देखें। यदि कोई रूट पते को कवर नहीं करता, तो संबद्धता या रूट तालिका ठीक करें। यदि पैकेट पहुँचता है और सेवा उसे अस्वीकार करती है, तो अगला पड़ाव उस सेवा की नीति है। प्राधिकरण मैट्रिक्स को सभी उपयोगकर्ताओं तक बढ़ाना छिपा देता है कि इनमें से कौन-सी परत वास्तव में टूटी थी।

टिकट बंद करने से पहले पहचान स्रोत, सटीक समूह मान, गंतव्य प्रीफ़िक्स और ट्रैफ़िक ले जाने वाला रूट दर्ज करें। यह रिकॉर्ड अगली कनेक्टेड परंतु पहुँच नहीं रिपोर्ट को एक और अनुमान दौर के बजाय दो मिनट की तुलना में बदल देता है।