Cisco AnyConnect सँग आउने vpn क्लाइन्ट कुराकानीजस्तै व्यवहार गर्छ: यसले प्रम्प्ट छाप्छ, एउटा लाइन पर्खन्छ, अनि अर्को छाप्छ। त्यो कुराकानी फाइल वा पाइपबाट भित्र पठाउनुहोस् र त्यही बाइनरी निगरानीबिना चल्छ। प्रविधि एउटा रिडाइरेक्ट र क्रमबद्ध जवाफ सूची हो, र स्क्रिप्ट भरपर्दो छ कि छैन भन्ने रिडाइरेक्टले होइन, त्यही सूचीले निर्धारण गर्छ।

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

एउटा क्रम, क्लाइन्टले सोध्ने क्रममै

क्लाइन्टलाई एक पटक अन्तरक्रियात्मक रूपमा चलाउनुहोस् र हरेक प्रम्प्ट देखिने क्रममा लेख्नुहोस्। त्यही ट्रान्स्क्रिप्ट जवाफ-फाइल बन्छ। फाइललाई बाइनरीमा रिडाइरेक्ट गर्दा पहिलो लाइन नै जडान आदेश हुनुपर्छ, त्यसैले क्रम प्रयोगकर्ता नामले होइन, होस्ट नामले सुरु हुन्छ।

connect vpn.example.com
0
<username>
<password>
y
exit

खाली 0 ले गेटवेले सूची दिँदा पहिलो जडान प्रोफाइल छान्छ; तपाईंको गेटवेले छाप्ने इन्डेक्स प्रयोग गर्नुहोस्। y ले लगइन ब्यानर स्वीकार्छ, त्यसैले ब्यानर नभए त्यो लाइन मेट्नुहोस् र तपाईंको गेटवेले थप प्रश्न सोध्ने ठाउँमा एउटा लाइन थप्नुहोस्। अन्त्यको exit ले अन्तिम जवाफ सकिएपछि क्लाइन्टलाई सफा रूपमा अन्त्य गर्न दिन्छ।

/opt/cisco/anyconnect/bin/vpn -s < anyconnect.txt

यहाँ गैर-अन्तरक्रियात्मक मोड वैकल्पिक होइन। -s बिना क्लाइन्टले टर्मिनल कब्जा गर्न र रिडाइरेक्ट गरिएको इनपुट बेवास्ता गर्न सक्छ; यससँग जवाफहरू स्ट्रिमबाट पढिन्छन् र प्रक्रिया फर्कन्छ। बाइनरीलाई उच्च विशेषाधिकार चाहिने ठाउँमा कललाई sudo -n मा बेर्नुहोस्, ताकि स्क्रिप्ट पासवर्ड प्रम्प्टमा अड्किनुको सट्टा तुरुन्तै असफल होस्।

जवाफ-फाइल कहाँ चुहिन्छ

पासवर्ड भएको फाइल एउटा प्रमाण हो, त्यसैले त्यसलाई प्रमाणकै अनुमति दिनुहोस्: मोड 600, काम चलाउने खाताको स्वामित्वमा, र कहिल्यै साझा वा सिङ्क गरिएको डाइरेक्टरीमा नहुने। पछि सुधार्नुको सट्टा मोड पहिले नै लागू गरेर बनाउनुहोस्, किनकि लेख्ने र chmod बीच फाइल क्षणभर सबैले पढ्न सक्ने हुन्छ।

install -m 600 /dev/null ~/.config/anyconnect.txt
chmod 700 ~/.config

अर्को आधा argv हो। आर्गुमेन्टका रूपमा दिइएको पासवर्ड प्रक्रिया सूची बनाउने हरेक स्थानीय प्रयोगकर्तालाई देखिन्छ, र शेल इतिहासमा पनि पुग्छ। यसको सट्टा यसलाई फाइल डिस्क्रिप्टर वा वातावरण चरबाट पढ्नुहोस्, र पेलोडलाई उद्धरणमा राख्नुहोस् ताकि शेलले भित्र केही पनि विस्तार गर्न नसकोस्।

printf '%s\n' 'connect vpn.example.com' '0' "$VPN_USER" "$VPN_PASS" 'y' 'exit' \
  | sudo -n /opt/cisco/anyconnect/bin/vpn -s

उद्धरणमा ध्यान दिनुहोस्। दोहोरो उद्धरणभित्र ! भएको पासवर्ड क्लाइन्टले देख्नुअघि नै अन्तरक्रियात्मक शेलले विस्तार गर्न सक्छ, र असफलता प्रोटोकल समस्याजस्तो देखिने सामान्य event-not-found त्रुटिका रूपमा आउँछ।

सुरुङ प्रमाणित गर्नुहोस्, अनि बन्द गर्नुहोस्

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

/opt/cisco/anyconnect/bin/vpn state
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 10 https://<internal-host>/
/opt/cisco/anyconnect/bin/vpn disconnect

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

जब स्थिर सूची सुरक्षित रहन छोड्छ

जवाफ-फाइलले आजको प्रम्प्ट क्रम सङ्केत गर्छ। बदलिएको ब्यानर, जबरजस्ती पासवर्ड परिवर्तन वा दोस्रो-कारकको चुनौतीले यसलाई खाता लक गर्न सक्ने लुपमा बदल्छ, त्यसैले स्क्रिप्टले पुनः सुरु गर्नुको सट्टा पहिलो अप्रत्याशित जवाफमा बाहिर निस्कनुपर्छ।

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

रोटेसन पनि त्यही समीक्षामा पर्छ। यदि प्रमाण भण्डारण गरिन्छ भने, यो कसले पढ्न सक्छ, कहिले बदलिन्छ र होस्ट पुनर्निर्माण हुँदा यसलाई केले हटाउँछ भन्ने तय गर्नुहोस्। कसैले पासवर्डलाई छोएन भनेर एक वर्ष चल्ने स्क्रिप्ट डिजाइन होइन, रोटेसन नीतिको प्रतीक्षामा रहेको दुर्घटना हो।

AnyConnect नभएका प्रोफाइलहरू

Cisco का दुई पुराना प्रमाण शैलीहरूलाई यससँग भ्रमित गरिन्छ। vpnc प्रोफाइलले IPSec ID माग्छ, जो वास्तवमा समूहको नाम हो, त्यसपछि समूह गोप्य, त्यसपछि तपाईंका आफ्नै प्रमाणहरू, र ती तीनै गेटवे चलाउनेबाट आउँछन्। पुरानो Cisco IPsec AnyConnect भन्दा फरक प्रोटोकल हो, त्यसैले vpnc ले AnyConnect-मात्र सेवामा पुग्न सक्दैन; openconnect --protocol=anyconnect त्यो कामका लागि खुला क्लाइन्ट हो।

.pcf फाइलले पुरानो क्लाइन्ट प्रोफाइल वर्णन गर्छ। त्यभित्रको होस्ट, समूहको नाम र समूह पासवर्ड Cisco IPsec बोल्ने क्लाइन्टमा हातले फेरि हाल्न सकिन्छ, तर फाइल सार्वभौमिक आयात होइन र कुनै पनि गैर-पूर्वनिर्धारित पोर्ट वा सुरुङ मोड सामान्यतया स्थानान्तरणमा हराउँछ।

गेटवेले साँच्चै के दिन्छ त्यसबाट सुरु गर्नुहोस्, अनि त्यो प्रोटोकल बोल्ने क्लाइन्ट छान्नुहोस्। अर्को साइटबाट प्रोफाइल कपी गर्नु नै त्यो बाटो हो जसबाट मानिसहरू कहिल्यै समस्या नभएका प्रमाणहरू डिबग गर्न पुग्छन्।

सम्बन्धित लेखहरू