टोकन कोड की प्रतीक्षा करने वाले VPN लॉगिन को कैसे स्वचालित करें

विक्रेता के VPN क्लाइंट को शुरू करने वाली स्क्रिप्ट समय-सीमा खत्म होने तक अटकी रहती है, और लॉग दिखाता है कि क्लाइंट ऐसा सत्यापन कोड माँग रहा है जो किसी ने टाइप नहीं किया। पासवर्ड दिया गया था, इसलिए स्पष्ट निष्कर्ष यह है कि पासवर्ड गलत है। ऐसा नहीं है। कोड का अनुरोध अलग चैनल पर अलग बातचीत है, और आपकी स्क्रिप्ट ने उसे कभी नहीं खोला।

नीचे दी गई पाँच जाँच क्रम से करें। जो पहली विफल हो उसी पर रुकें, क्योंकि हर बाद का चरण पिछले के सही होने की अपेक्षा करता है।

जाँच 1: क्या क्लाइंट मानक इनपुट पढ़ता ही है?

कोई भी स्वचालन लिखने से पहले परखें: पाइप से क्लाइंट में एक नकली रहस्य भेजें और देखें क्या होता है। यदि वह अपना अनुरोध छापता है और फिर प्रतीक्षा करता है, तो वह पाइप नहीं पढ़ रहा।

कई क्लाइंट टर्मिनल डिवाइस को सीधे खोलते हैं, या गैर-टर्मिनल स्ट्रीम से रहस्य लेने से मना कर देते हैं, ताकि भटकी हुई पाइप पासवर्ड लीक न कर सके। OpenVPN प्रलेखित अपवाद है, क्योंकि --auth-user-pass फ़ाइल पथ लेता है। एक-बार कोड माँगने वाले विक्रेता क्लाइंट में सामान्यतः समकक्ष विकल्प नहीं होता, और उनका अनुरोध ऐसे टर्मिनल की प्रतीक्षा करता है जो आपकी स्क्रिप्ट ने कभी नहीं दिया।

जाँच 2: क्या चाइल्ड प्रक्रिया के पास टर्मिनल है?

pty चाइल्ड के लिए टर्मिनल आवंटित करता है, जो अनुरोधों को पठनीय आउटपुट में बदल देता है जिसका उत्तर आप क्रम से दे सकते हैं।

import pexpect

child = pexpect.spawn("openconnect vpn.example.net", encoding="utf-8", timeout=30)
child.expect("GROUP:")
child.sendline("staff")
child.expect("USERNAME:")
child.sendline("alice")
child.expect("PASSWORD:")
child.sendline(PASSWORD)
child.expect("Connected as", timeout=60)

ऊपर दिए अनुरोध स्ट्रिंग उदाहरण हैं; जो सटीक टेक्स्ट आपका क्लाइंट छापता है उसे कॉपी करें, जिसमें अक्षरों का केस और विराम-चिह्न शामिल हैं। हर प्रत्याशा के साथ समय-सीमा होती है, और बंद चाइल्ड स्थिति लौटाने के बजाय अपवाद उठाता है, इसलिए अनुक्रम को लपेटें और फ़ाइल के अंत को विफलता मानें। ध्यान दें यह खंड क्या नहीं करता: चाइल्ड स्क्रिप्ट के साथ मर जाता है, क्योंकि pty अलगाव की क्रियाविधि नहीं है और disown शेल का अंतर्निहित आदेश है जो आपकी स्क्रिप्ट द्वारा बनाई गई प्रक्रिया तक नहीं पहुँच सकता।

जाँच 3: क्या कोई समर्थित गैर-इंटरैक्टिव इनपुट है?

स्क्रीन-स्क्रैपिंग क्लाइंट अपग्रेड पर टूट जाती है, इसलिए पहले प्रलेखित विकल्प खोजें।

सहायता आउटपुट में टोकन या एक-बार कोड का विकल्प देखें, और देखें कि सेवा पासवर्ड फ़ील्ड में जोड़ा गया कोड स्वीकार करती है या नहीं। जहाँ क्लाइंट क्रेडेंशियल फ़ाइल पढ़ता है, वहाँ अनुरोध के बजाय उसे फ़ाइल दें:

openvpn --config office.ovpn --auth-user-pass <(printf "%s\n%s\n" "$USER_NAME" "$PASSWORD")

प्रक्रिया प्रतिस्थापन /dev/fd देने वाले सिस्टम पर क्लाइंट को पठनीय पथ देता है। क्लाइंट की दृष्टि से रहस्य अब भी रहस्य है, इसलिए इसे लॉग, शेल इतिहास और प्रक्रिया सूचियों से बाहर रखें। यदि क्लाइंट /dev/fd अस्वीकार करता है या क्रेडेंशियल पथ को एक से अधिक बार खोलता है, तो कड़ी अनुमतियों वाली वास्तविक फ़ाइल लिखें और उसी स्क्रिप्ट में उसे हटा दें।

जाँच 4: क्या सुरंग स्क्रिप्ट से अधिक जीवित रहेगी?

डिफ़ॉल्ट रूप से सुरंग अपने जनक के साथ मर जाती है, जो बूटस्ट्रैप स्क्रिप्ट की आवश्यकता का उल्टा है।

disown -h तभी मदद करता है जब आपने क्लाइंट को शेल जॉब के रूप में शुरू किया हो, क्योंकि वह उस शेल की जॉब तालिका संपादित करता है और आपकी स्क्रिप्ट द्वारा pty के ज़रिए बनाई गई प्रक्रिया तक नहीं पहुँच सकता। जो भी बिना निगरानी के फिर से जुड़ना चाहिए उसके लिए सेवा प्रबंधक बेहतर ठिकाना है, क्योंकि वह क्लाइंट को पुनः आरंभ करता है और दर्ज करता है कि वह क्यों मरा। किसी भी स्थिति में, हर पुनः कनेक्शन के बाद नया कोड अपेक्षित रखें: एक-बार टोकन पहले सफल प्रमाणीकरण में खर्च हो जाता है।

देखें sudo अनुक्रम के साथ क्या करता है। sudo का पासवर्ड अनुरोध VPN का अनुरोध नहीं है, और उसका उत्तर VPN पासवर्ड से देना ही सबसे सामान्य तरीका है जिससे बाकी सही प्रत्याशा क्रम विफल रहता है।

जाँच 5: क्या किसी व्यक्ति का कोड स्क्रिप्ट में होना चाहिए?

यह वह जाँच है जिसे लोग छोड़ देते हैं। टोकन किसी व्यक्ति का होता है, जबकि समय-सारणी पर ऊपर आने वाली सुरंग मशीन की होती है।

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

कार्यशील स्क्रिप्ट कैसी दिखती है

स्क्रिप्ट उस चरण को छापती है जहाँ वह पहुँची, रहस्य कभी नहीं, और किसी भी विफल प्रत्याशा पर गैर-शून्य कोड के साथ बाहर निकलती है।

जानबूझकर तोड़कर उसका परीक्षण करें: गलत पासवर्ड, गलत समूह, समाप्त टोकन। हर विफलता अटकने के बजाय नामित चरण पर रुकनी चाहिए। फिर असली सेवा के सामने उसे एक बार चलाएँ और सुरंग को स्क्रिप्ट के बाहर से जाँचें, अंदर से नहीं।