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 वरील पुढील बदल फक्त जोखीम वाढवतात।