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

પછી એક ક્લાયન્ટ ફરીથી જોડો અને ખાતરી કરો કે લોગ લીટી દેખાવાનું બંધ થઈ ગયું છે. પ્રોફાઇલ ફેરફાર પછી પણ ચાલુ રહેતું હૂક સામાન્ય રીતે ટેસ્ટ ઉપકરણ પર હજી તૈનાત બીજું પ્રોફાઇલ હોય છે, અને તેને હમણાં શોધવું ઓડિટ દરમિયાન શોધવા કરતાં સસ્તું છે.

અંતે જે રહે છે તે નાનો, મર્યાદિત સેશન મેટાડેટાનો ટુકડો છે જેનું મૂળ દસ્તાવેજીકૃત છે: ક્લાયન્ટ તેનો દાવો કરે છે, સર્વર તેને નોંધે છે, અને ઍક્સેસ વિશે કંઈપણ તેના પર આધારિત નથી. આ સુવિધાનું ઉપયોગી સ્વરૂપ છે, અને ત્યાં પહોંચવા માટે કોઈ નવું ક્રેડેન્શિયલ જરૂરી નથી.