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 मा थप परिवर्तनले जोखिम मात्र थप्छ।