OpenVPN push-peer-info: पहुँच दिए बिना क्लाइंट को लेबल करें

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

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

चर सेट करें और रास्ता सक्षम करें

क्लाइंट प्रोफ़ाइल में दो पंक्तियाँ काम करती हैं, और दोनों आवश्यक हैं। पहली के बिना भेजने को कुछ नहीं; दूसरी के बिना क्लाइंट पीयर जानकारी बिल्कुल नहीं देता। क्रम मायने नहीं रखता, और यह जानना अच्छा है क्योंकि दोनों पंक्तियाँ अक्सर बनाई गई प्रोफ़ाइल के अलग-अलग हिस्सों में पहुँचती हैं। मायने यह रखता है कि क्लाइंट के पढ़ने से पहले प्रोफ़ाइल को जो भी फिर से लिखे, दोनों बची रहें।

setenv UV_DEPLOY field-support
push-peer-info

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

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

सर्वर हुक से फ़ील्ड पढ़ें

सर्वर की ओर, प्राप्त पीयर जानकारी को मान्य किया जाता है और कनेक्शन वर्कफ़्लो के परिवेश में डाला जाता है, और यही उसे आपके किसी प्रोटोकॉल काम के बिना हुक से पढ़ने योग्य बनाता है। सर्वर को नियंत्रण चैनल पार्स करने या आपके लिए कुछ संग्रहीत करने की ज़रूरत नहीं; कनेक्शन सेट होते समय मान बस मौजूद रहता है। प्रमाणित नाम के पास लेबल दर्ज करने वाला न्यूनतम client-connect स्क्रिप्ट ऐसा दिखता है।

#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
  >> /var/log/openvpn/deploy-labels.log

लॉग पार्स करने के बजाय परिवेश के माध्यम से चर पढ़ें, और उसे हमेशा डिफ़ॉल्ट मान दें। ${UV_DEPLOY:-unset} उन क्लाइंट के लिए स्क्रिप्ट को चालू रखता है जो फ़ील्ड कभी नहीं भेजते, जो चरणबद्ध तैनाती के दौरान सामान्य स्थिति है। नाम खोजने के लिए पूरा परिवेश लॉग में न उँडेलें; उसमें लेबल से कहीं अधिक होता है, जिनमें वे मान भी शामिल हैं जिन्हें आप सहेजना नहीं चाहते थे।

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

जाँचें कि वास्तव में क्या पहुँचा

लेबल के साथ एक क्लाइंट और बिना लेबल दूसरा जोड़ें, फिर फ़ाइल पढ़ें। जोड़ी ही परीक्षण है: एक पंक्ति में मान होना चाहिए और दूसरी में डिफ़ॉल्ट, और दोनों को वही प्रमाणित पहचान बतानी चाहिए जिसकी आप अपेक्षा करते हैं।

tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset         legacy-laptop-02

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

कनेक्शन के लिए सर्वर लॉग भी जाँचें। पीयर जानकारी वहाँ दिख सकती है, जो डिबगिंग के लिए सुविधाजनक है और मानों को उबाऊ रखने का कारण है: लोगों के नाम नहीं, टिकट संख्या नहीं, ऐसा कुछ नहीं जो लॉग पढ़ने वाला देखे तो आपको बुरा लगे।

लेबल को दावा मानें, पहचान नहीं

जो भी क्लाइंट प्रोफ़ाइल संपादित कर सकता है वह टैग बदल सकता है, और टनल का प्रमाणित होना टैग को आधिकारिक नहीं बनाता। ट्रांसपोर्ट मान को रास्ते में सुरक्षित रखता है; यह दावे को प्रमाणित नहीं करता। प्राधिकरण अब भी प्रमाणित पहचान और सर्वर के स्वामित्व वाले नामांकन रिकॉर्ड का है, और जब मायने रखता है तब लेबल की उस रिकॉर्ड से तुलना होती है।

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

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

case "${UV_DEPLOY:-}" in
  field-support|field-qa|lab) : ;;
  *) UV_DEPLOY=unknown ;;
esac

इसे साफ़-सुथरे ढंग से वापस लें

सुविधा हटाना दो विलोपन और एक सत्यापन है। क्लाइंट प्रोफ़ाइल से setenv और push-peer-info पंक्तियाँ हटाएँ, फिर सर्वर पर हुक और उसका लॉग लक्ष्य हटाएँ या अक्षम करें।

grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log

बाद में एक क्लाइंट फिर से जोड़ें और पुष्टि करें कि लॉग पंक्ति दिखना बंद हो गई। प्रोफ़ाइल बदलाव के बाद भी चलता रहने वाला हुक आम तौर पर परीक्षण डिवाइस पर अभी तैनात दूसरी प्रोफ़ाइल होती है, और उसे अब खोजना ऑडिट के दौरान खोजने से सस्ता है।

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