OpenConnect लगइन कुकीलाई सुरुङमा कसरी बदल्छ?

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

लगइनको क्रममा सुरुङबारे केही पनि वार्ता हुँदैन। यही बुझ्नुपर्ने भाग हो, किनकि धेरै स्क्रिप्ट त्रुटिले कुकी सुरक्षित राख्ने पासवर्ड वा ट्राफिक जोगाउने कुञ्जी हो भन्ने ठान्छन्, तर वास्तवमा त्यो निश्चित गेटवे सत्रका लागि वाहक टिकट हो।

क्लाइन्ट र गेटवेले क्रमैसँग के साटासाट गर्छन्

प्रमाणीकरण चरण साधारण सुरक्षित वेबसाइटजस्तो देखिन्छ। OpenConnect प्रयोगकर्ताको प्रमाण पठाउँछ, वा गेटवेको पुनर्निर्देशन पछ्याउँदै पहिचान प्रदायककहाँ जान्छ, र गेटवे प्रमाणीकरण कुकी समावेश गरेको कागजातसँग जवाफ दिन्छ। AnyConnect प्रोटोकलमा त्यो मान अर्को अनुरोधहरूमा कुकी हेडरमा जान्छ, सामान्यतया webvpn जस्तो नाममा, र पुस्तिकाले यसलाई सत्र अगाडि बोक्ने प्रमाण मान्छ।

दोस्रो चरण त्यही कुकी जोडेर गेटवेको VPN अन्त्यबिन्दुमा जाने CONNECT अनुरोध हो। गेटवेले त्यो जाँच्छ, ठेगाना तोक्छ, र क्लाइन्टले TLS माथि CSTP सुरु गर्छ, सत्र भएपछि DTLS वैकल्पिक छिटो डेटा मार्ग बन्छ। यही बिन्दुमा मात्र सुरुङका प्यारामिटर, मार्ग, DNS सेटिङ र सत्रका ट्राफिक कुञ्जीहरू स्थापित हुन्छन्। कुकीले क्लाइन्टलाई ढोकाबाट पार गरायो; यसले केही पनि इन्क्रिप्ट गरेन।

यही क्रमले openconnect --authenticate किन छ भन्ने बताउँछ। यसलाई चलाउनुहोस्, यसले वेब चरण गर्छ, COOKIE, HOST, CONNECT_URL र FINGERPRINT जस्ता शेल चरहरूको सानो ब्लक छाप्छ, र त्यसपछि कुनै सुरुङ बन्नुअघि बाहिरिन्छ। त्यसपछि र्यापर स्क्रिप्टले ती मानहरूसँग साँचो जडान सुरु गर्न सक्छ, र हेडलेस वा दुई कन्टेनर तैनाथीलाई ठ्याक्कै यही विभाजन चाहिन्छ।

कुकी सत्रको वाहक हो, कुञ्जी होइन

त्यो मानलाई वेब अनुप्रयोगको सत्र पहिचानजस्तै व्यवहार गर्नुहोस्। आफ्नो आयुभरि त्यो राख्ने जो कोहीले गेटवेबाट त्यो सुरुङ माग्न सक्छ जसको त्यो सत्र हकदार छ, त्यसैले यसको गोपनीयता महत्त्वपूर्ण छ। तर प्रतिलिपि गर्दा ट्राफिक खुल्दैन, किनकि सुरुङको गोपनीयता TLS हस्तमिलन र त्यसबाट निस्केका कुञ्जीबाट आउँछ, कुकीको शृंखलाबाट होइन।

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

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

प्रतिलिपि नछाडी कुकी सुम्पिने

Linux मा सबैभन्दा सुरक्षित यान्त्रिक हस्तान्तरण मानक इनपुट हो। --cookie-on-stdin मान stdin बाट पढ्छ, त्यसैले कुकी प्रक्रियाको आर्गुमेन्ट सूचीमा कहिल्यै देखिँदैन, जहाँ जो कोही स्थानीय प्रयोगकर्ताले ps ले पढ्न सक्छ। एउटा प्रक्रियामा प्रमाणीकरण गरी अर्कोमा सुरुङलाई खुवाउने पाइपलाइनले मान फाइल वा वातावरण चरमा होइन, पाइपमा राख्छ।

आर्गुमेन्ट र वातावरण चर फरक कारणले कमजोर छन्। आर्गुमेन्ट क्लाइन्टको सम्पूर्ण आयुभरि प्रक्रिया तालिकामा देखिन्छ र प्रायः शेल इतिहासमा पर्छ। वातावरण चर सन्तान प्रक्रियामा वंशानुगत जान्छ, र युनिट फाइलमा त्यो सेट गर्ने systemd युनिटले रहस्य पढ्न सकिने कन्फिगरेसनमा राख्छ। फाइल नै चाहिएमा त्यसलाई सेवा खातामा सीमित राख्नुहोस् र सत्र सकिएपछि हटाउनुहोस्।

विशेषाधिकारको सीमा पनि जानाजानी राख्नुहोस्। पहिचान प्रदायकसँग बोल्ने र सायद ब्राउजर खोल्ने प्रक्रिया त्यो लगइनको मालिक प्रयोगकर्ताका रूपमा चल्नुपर्छ। मार्ग, DNS र सुरुङ यन्त्र कन्फिगर गर्ने प्रक्रियालाई थप विशेषाधिकार चाहिन सक्छ। root को स्वामित्वको सुरुङमा कुकी उपलब्ध गराउन सम्पूर्ण ब्राउजर root का रूपमा चलाउनु गलत साटासाट हो, र आधुनिक OpenConnect सेटअपले त्यो मान त्यो सीमापार स्पष्ट रूपमा दिन सक्छन्।

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

दोस्रो चरणमा प्रमाणीकरण र म्याद सकिने

दोस्रो चरणले अझै सर्भर प्रमाणित गर्नुपर्छ। --authenticate ले छाप्ने FINGERPRINT pin-sha256: रूपको प्रमाणपत्र पिन हो, र त्यसलाई --servercert सँग सुरुङ आह्वानमा दिँदा प्रमाणीकरण तपाईंले प्रमाणित गरेको गेटवेमा लङ्गरिएको रहन्छ। स्क्रिप्ट सरल बनाउन प्रमाणपत्र जाँच बन्द गर्नु भनेको कुकी इच्छित होस्टलाई दिइएको छ भन्ने एकमात्र प्रमाण हटाउनु हो।

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

यसलाई स्वचालित गर्नुअघि चार कुरा जाँच्नुहोस्: सुरुङ सही खातामा चल्छ, कुकी stdin बाट आउँछ, प्रमाणपत्रको औंलाछाप पिन गरिएको छ, र सुरुङ बन्द हुँदा सत्र त्यागिन्छ। यीमध्ये कुनै छुटेमा स्वचालनले हातको प्रवाह पुनरुत्पादन गर्नुको सट्टा कुकीमाथिको विश्वास बढाएको छ।