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

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

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