ASA का दूरस्थ उपयोगकर्ता सबनेट तक क्यों पहुँचता है पर ऐप तक नहीं
रूट साबित करते हैं कि सुरंग काम करती है, यह नहीं कि उपयोगकर्ता ऐप खोल सकता है। सत्र को मिला फ़िल्टर पढ़ें, फिर अनुमत और अस्वीकृत कनेक्शन जाँचें।
आपका उपयोगकर्ता जुड़ता है, पता पाता है, ऐप के सबनेट में सर्वर को पिंग करता है और फिर भी उस पर सेवा नहीं खोल पाता। ASA पर यह संयोजन सामान्य है, क्योंकि सफल सुरंग और उपयोगी अनुमति अलग-अलग सेटिंग्स तय करती हैं। स्प्लिट-टनल सूची ने चुना कि कौन-से गंतव्य सुरंग में गए; VPN फ़िल्टर और गंतव्य के अपने एक्सेस नियम तय करते हैं कि डिक्रिप्ट किया गया अनुरोध कहाँ तक पहुँच सकता है। रूट सूची को चौड़ा करने के बजाय तीनों निर्णय क्रम से निपटें, जब तक कुछ बदल न जाए।
तीन निर्णय जिन्हें भ्रमित करना आसान है
प्रवेश बताता है कि उपयोगकर्ता सुरंग बना सकता है या नहीं: क्रेडेंशियल, प्रमाणपत्र और कोई दूसरा कारक। मार्ग चयन बताता है कि क्लाइंट किन गंतव्यों को उस सुरंग में भेजता है। प्राधिकरण बताता है कि डिक्रिप्ट किया गया अनुरोध सेवा तक पहुँच सकता है या नहीं। केवल तीसरा वह त्रुटि पैदा करता है जिसकी उपयोगकर्ता शिकायत करता है।
उन्हें अलग पहचानने का तेज़ तरीका यह पूछना है कि कोई बदलाव क्या तोड़ेगा। स्प्लिट सूची से रूट हटाने पर उस सबनेट का ट्रैफ़िक रुक जाता है पर कुछ मिलता नहीं; VPN फ़िल्टर में ACE जोड़ने से गंतव्य मिलता है पर क्लाइंट जो सुरंग में भेजता है वह नहीं बदलता।
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
सत्र को वास्तव में मिला फ़िल्टर पढ़ें
उस कॉन्फ़िगरेशन से नहीं जो आपको लगता है लागू है, जीवंत सत्र से शुरू करें। show vpn-sessiondb detail anyconnect सौंपी गई समूह नीति और उस सत्र से जुड़ा फ़िल्टर नाम छापता है। यदि फ़ील्ड खाली है, तो कोई फ़िल्टर कुछ लागू नहीं कर रहा और अवरोध कहीं और से आ रहा है।
फिर उस नीति को पढ़ें जिसके पास मान है, डिफ़ॉल्ट सहित, क्योंकि फ़िल्टर विरासत में मिल सकता है, आप जहाँ देख रहे हैं वहाँ लिखा होना ज़रूरी नहीं:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
सत्र पर फ़िल्टर नाम की तुलना उस ACL से करें जिसे आपने अभी संपादित किया। मिलते-जुलते नाम वाली ACL जो उपयोगकर्ता को कभी नहीं मिली, उस सत्र की संसाधन नीति नहीं बदल सकती, और यही सबसे आम कारण है कि सही दिखने वाला बदलाव बेअसर रहता है।
प्राथमिकता बाकी समझाती है। फ़िल्टर सेटिंग के लिए DAP रिकॉर्ड उपयोगकर्ता नाम विशेषताओं से ऊपर है, और उपयोगकर्ता नाम विशेषताएँ समूह नीति से ऊपर हैं। जब सत्र ऐसा फ़िल्टर दिखाए जिसकी आपने अपेक्षा नहीं की, तो समूह को छूने से पहले उस उपयोगकर्ता से मेल खाती DAP नीति खोजें।
स्प्लिट सूची और फ़िल्टर अलग फ़ील्ड हैं
ASA 9.x पर समूह नीति split-tunnel-network-list और vpn-filter को अलग-अलग सेटिंग्स के रूप में रखती है, और 9.22 समूह-नीति मार्गदर्शिका इसी कारण उन्हें अलग-अलग दस्तावेज़ित करती है। नेटवर्क सूची क्लाइंट के लिए रूटिंग संकेत है; फ़िल्टर डिक्रिप्ट किए गए ट्रैफ़िक पर लागू एक्सेस नियंत्रण सूची है।
यह भेद तब मायने रखता है जब उपयोगकर्ता को सबनेट में एक ही HTTPS सेवा चाहिए। सबनेट को स्प्लिट सूची में डालें ताकि पैकेट सुरंग में जाएँ, फिर फ़िल्टर में केवल उसी सेवा की अनुमति दें। रूट सूची बढ़ाना कुछ भी अधिकृत नहीं करता, और उसे घटाना प्रवर्तन का तंत्र नहीं है।
जाँचें कि इंटरफ़ेस ACL भी मार्ग में है या नहीं
डिक्रिप्ट किया गया दूरस्थ पहुँच ट्रैफ़िक हमेशा बाहरी इंटरफ़ेस ACL से वैसे नहीं गुजरता जैसे लोग मानते हैं। जहाँ sysopt connection permit-vpn सक्षम है, वहाँ ASA उस ट्रैफ़िक के लिए अपना प्रलेखित VPN बायपास लागू करता है, जबकि लागू VPN फ़िल्टर उसके बाद भी लागू रहते हैं। सेटिंग को show run all sysopt से जाँचें, टोपोलॉजी आरेख से तर्क करने के बजाय।
किसी भी तरह, गंतव्य होस्ट का अपना फ़ायरवॉल और ऐप का प्राधिकरण मार्ग में रहते हैं। TCP 443 की अनुमति देने वाला ASA नियम ऐप को उपयोगकर्ता स्वीकार करने पर मजबूर नहीं करता।
बदलाव को अस्वीकृत कनेक्शन से भी स्वीकार करें
केवल अनुमत परीक्षण बहुत कम साबित करता है, क्योंकि काम करती सुरंग फ़िल्टर हो या न हो वही पहला पैकेट पैदा करती है। क्लाइंट से इच्छित सेवा खोलें, फिर ऐसे गंतव्य को आज़माएँ जो बंद रहना चाहिए और पुष्टि करें कि वह सही कारण से विफल होता है।
टिकट बंद करते समय चार तथ्य दर्ज करें: स्वीकृत पहचान, सत्र को वास्तव में मिली नीति और फ़िल्टर, स्प्लिट सूची के गंतव्य, और वह संसाधन जिस तक उपयोगकर्ता को पहुँचने की अनुमति थी। ये चार बताते हैं कि ट्रैफ़िक कहाँ नियंत्रित होता है, बिना रूट सूची को फ़ायरवॉल बनाए।
यदि फ़िल्टर अनुमति देने के बाद भी सेवा मना करती है, तो होस्ट पर जाएँ: सुनने का पता, होस्ट फ़ायरवॉल और ऐप का अपना उपयोगकर्ता मैपिंग। उस समय सुरंग ने अपना काम किया, और ASA पर और बदलाव केवल जोखिम जोड़ते हैं।