ASA समूह alias र समूह URL: प्रोफाइल कसरी छानिन्छ

ASA ले छानेपछि मात्र कनेक्शन प्रोफाइलले सत्रलाई नियन्त्रण गर्छ। त्यो एक वाक्य नै क्लाइन्ट-रहित पुरानो पोर्टलको समस्या पहिचानको पूरा ढाँचा हो। नप्रयोग गरिएको प्रोफाइलमा पूर्ण पहुँच नियमहरू हुन सक्छन् र पनि कसैलाई लागू नहुन सक्छ। कुनै पनि नीति सम्पादन गर्नुअघि लगइन प्रवेश बिन्दु पछ्याउनुहोस्।

तलका भिन्नताहरू 9.16 का कागजातहरूमा आधारित छन्; क्लाइन्ट-रहित SSL VPN 9.17(1) र त्यसपछि हटाइयो।

alias सूचीको प्रविष्टि हो, URL होइन

group-alias ले लगइन पृष्ठको समूह सूचीबाट प्रयोगकर्ताले छान्ने लेबल दिन्छ। त्यो सूची देखाउनु छुट्टै सेटिङ हो, tunnel-group-list enable। alias केवल छनोटको नाम हो, त्यसभन्दा बढी केही होइन। staff नामको alias कन्फिगर गर्दा प्रोफाइल छान्ने /staff URL बन्दैन।

ब्राउजरभित्रबाट सूची र URL एउटै छनोटजस्तो देखिने हुनाले मानिसहरूले alias ले दोहोरो काम गर्छ भन्ने अपेक्षा गर्छन्।

group-url ले वास्तवमा के मिलाउँछ

group-url ले आउने URL लाई कनेक्शन प्रोफाइलसँग बाँध्छ। त्यो सक्षम URL मिलेपछि, प्रयोगकर्तालाई सूचीबाट छान्न नभनी ASA ले प्रोफाइल छान्छ। URL पूर्ण र अभिप्रेत हुनुपर्छ, तपाईंको रिलिजले समर्थन गर्ने सिन्ट्याक्समा। त्यसको DNS रेकर्ड र प्रमाणपत्र प्रयोगकर्ताले टाइप गर्नेसँग मिल्नुपर्छ, नत्र मिलान कहिल्यै हुँदैन।

प्रतिलिपि गरिएको URL प्रत्ययले कन्फिगरेसनबारे केही पनि प्रमाणित गर्दैन। ठेगाना पट्टी होइन, प्रोफाइल जाँच्नुहोस्।

छनोटलाई चल्ने नीतिसम्म पछ्याउनुहोस्

टनेल समूह छानिएपछि, यन्त्रले प्रमाणीकरण विधि र त्यसमा जोडिएको पूर्वनिर्धारित समूह नीति निर्धारण गर्छ। त्यसपछि प्रयोगकर्ता-विशेष विशेषता, प्रमाणीकरणले फर्काएका मान र गतिशील अधिकृति ती आधारका भागहरूलाई ओभरराइड गर्न सक्छन्। सत्रले वास्तवमा के पायो जाँच्नुहोस्। नामित नीति मात्र पढ्नाले आधार दिन्छ, नतिजा होइन।

यी दुईबीचको खाडल नै «नियम ठीक छ तर पहुँच गलत छ» भन्ने अधिकांश रिपोर्टको स्रोत हो।

उत्तराधिकार अलगाव होइन

तपाईंले अनिर्दिष्ट छोड्नुभएका विशेषताहरू पूर्वनिर्धारित समूह नीतिबाट उत्तराधिकारमा आउन सक्छन्। त्यसैले नयाँ नामित नीति साझा पूर्वनिर्धारितबाट अलग छैन, र तिनलाई सम्पादन गर्दा ती उत्तराधिकारमा पाउने हरेक प्रोफाइलसम्म पुग्छ। प्रत्येक प्रोफाइलका लागि प्रभावकारी स्रोत पहुँच, DNS सेटिङ र सत्र प्रतिबन्ध तुलना गर्नुहोस्। साझा केही बदल्नुअघि यो गर्नुहोस्।

पहुँच कार्यान्वयनलाई छनोटबाट अलग राख्नुहोस्।

क्लाइन्ट-रहित सत्रका लागि लागू हुने फिल्टर webtype ACL हो। टनेल क्लाइन्टका लागि VPN फिल्टर यसको विकल्प होइन, कन्फिगरेसनमा दुवै एउटै नीति ब्लकनजिक भएकै कारण मात्र।

नमिल्ने अवस्था तय गर्नुहोस्, त्यसपछि हरेक मार्ग परीक्षण गर्नुहोस्

पोर्टलको सामान्य URL र अन्य नमिल्ने प्रवेश बिन्दुमा के हुनुपर्ने हो निर्धारण गर्नुहोस्। एउटा परीक्षण खाता पास होस् भनेर साझा पूर्वनिर्धारित सम्पादन गर्नुको सट्टा वास्तविक पूर्वनिर्धारित-प्रोफाइल मार्ग र त्यसको अधिकृति हेर्नुहोस्। त्यसपछि तीन नयाँ सत्र खोल्नुहोस्: स्पष्ट URL, सक्षम सूची प्रविष्टि र सामान्य प्रवेश बिन्दु। हरेकका लागि छानिएको प्रोफाइल र प्रभावकारी नीति लेख्नुहोस्।

अघिल्लो लगइनको ब्राउजर ट्याब पुनः प्रयोग गर्दा तुलना बिग्रन्छ, किनकि त्यो सत्र पहिले नै प्रोफाइलसँग बाँधिएको छ।

त्यो अभिलेखले «पोर्टल खुल्छ» लाई लगइन-देखि-नीति म्यापिङमा बदल्छ जसलाई तपाईं पछि अडिट गर्न सक्नुहुन्छ, र प्रोफाइल ठीक देखिँदा पनि कसैलाई नियन्त्रण नगर्दा यही एक मात्र दिगो उत्तर हो।