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

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

शेवटी उरते ते मूळ नोंदवलेले सत्र मेटाडेटाचे लहान, मर्यादित तुकडे: क्लायंट त्याचा दावा करतो, सर्व्हर ते नोंदवतो, आणि प्रवेशाबद्दल काहीही त्यावर अवलंबून नाही। हीच वैशिष्ट्याची उपयुक्त आवृत्ती आहे, आणि तिथपर्यंत पोहोचण्यासाठी नवीन क्रेडेन्शियलची गरज नाही।