ફક્ત એક મેનેજમેન્ટ ક્લાયન્ટ: તમારું મોનિટર GUI ને કેમ બહાર કાઢે છે
મેનેજમેન્ટ સોકેટ એક સમયે એક જ કનેક્શન લે છે. બીજો સબસ્ક્રાઇબર ક્યાં તો જોડાઈ શકતો નથી અથવા પ્રોમ્પ્ટ ધરાવતા ઘટક પાસેથી નિયંત્રણ ચોરી લે છે.
એક ડેસ્કટોપ GUI મેનેજમેન્ટ કનેક્શન રાખે છે, તેથી મોનિટરિંગ સ્ક્રિપ્ટ પોતાનું કનેક્શન ખોલવાનો પ્રયાસ કરે છે અને કંઈ વાંચતું નથી, અથવા તેનાથી ખરાબ, GUI પ્રોમ્પ્ટનો જવાબ આપવાનું બંધ કરે છે. સામાન્ય નિષ્કર્ષ એ નીકળે છે કે ડેમન અસ્થિર છે. કોમ્યુનિટી ડેમનમાં આ મર્યાદા જાણી જોઈને છે: કંટ્રોલ ઇન્ટરફેસ એક સમયે ફક્ત એક જ જોડાયેલા મેનેજમેન્ટ ક્લાયન્ટની સેવા કરે છે, અને આ સંખ્યાનો VPN કેટલા વપરાશકર્તા ઉપાડી શકે તેની સાથે કોઈ સંબંધ નથી.
એક સોકેટ, એક ધારક
મેનેજમેન્ટ ચેનલ એક જ જોડાયેલો ક્લાયન્ટ સ્વીકારે છે. જ્યારે પહેલો સક્રિય હોય ત્યારે બીજો આવે, તો તે રાહ જુએ છે અથવા નકારવામાં આવે છે, અને કોઈ વિકલ્પ પાછળ સમાંતર સબસ્ક્રાઇબર મોડ છુપાયેલો નથી. વર્તમાન ધારકનું કનેક્શન કાપવાથી ડેમન આગલાને સ્વીકારે છે, અને આ બીજી ચેનલ નહીં પરંતુ સ્થાનાંતરણ છે.
આ દરેક વધારાના સાધનને સ્પર્ધક બનાવે છે. જો GUI પાસે કનેક્શન હોય, તો પોલિંગ સ્ક્રિપ્ટ ક્યાં તો જોડાઈ શકતી નથી અથવા GUI હાર માન્યા પછી જ સફળ થાય છે, અને આગલા ફરી કનેક્શન પર આ ક્રમ ફરી વાર થાય છે. જો સ્ક્રિપ્ટ પહેલા જોડાય, તો GUI પોતાનો નિયંત્રણ માર્ગ ગુમાવે છે અને તેના પ્રોમ્પ્ટ કામ કરવાનું બંધ કરે છે. કોઈ પણ સાધન આ અથડામણની જાણ કરતું નથી, કારણ કે દરેક ફક્ત પોતાનો નિષ્ફળ આદેશ જુએ છે.
| What you need | Mechanism that fits | What it cannot do |
|---|---|---|
| Periodic list of connected clients | Status file written on an interval | Deliver events as they happen |
| Interactive prompts and session control | The single management connection | Serve two controllers at once |
| Multiple consumers of either | One owner process that fans out | Exist without you writing it |
નિયંત્રણનો માલિક કયો ઘટક છે તે નક્કી કરો
ઇન્ટરેક્ટિવ ચેનલ માટે એક માલિક પસંદ કરો અને તેને જ જોડાતી એકમાત્ર વસ્તુ બનવા દો. કનેક્શનનું સંચાલન કરતું GUI, પ્રમાણીકરણ પ્રોમ્પ્ટનો જવાબ આપતી સ્ક્રિપ્ટ અને સત્રો સમાપ્ત કરતું નિયંત્રક, બધા માલિક ગણાય છે, અને ફક્ત એક જ આ ભૂમિકા લઈ શકે છે.
જ્યારે GUI કનેક્શનનો માલિક હોય, ત્યારે તેની સાથે લડવાને બદલે તે GUI જે એકીકરણ પ્રદાન કરે છે તેનો ઉપયોગ કરો. સોકેટ માટે માલિક સાથેની હરીફાઈ એવી વારંવાર નિષ્ફળતાઓ ઉત્પન્ન કરે છે જે વપરાશકર્તાઓને અવ્યવસ્થિત લાગે છે, અને ડિબગ કરનાર વ્યક્તિ સામાન્ય રીતે દોડનો ફક્ત બીજો અડધો ભાગ જુએ છે. રીબૂટ પછી કઈ પ્રક્રિયા પહેલા જોડાય છે તે ધ્યાનમાં રાખો, કારણ કે તે ક્રમ દર વખતે કોણ જીતશે તે નક્કી કરે છે. GUI પહેલા શરૂ થતું મોનિટર GUI હાર ન માને ત્યાં સુધી ચેનલ રાખશે.
સંગ્રાહકો માટે સ્થિતિ સ્નેપશોટનો ઉપયોગ કરો
મોટાભાગની મોનિટરિંગને યાદી જોઈએ છે, વાતચીત નહીં. સામયિક સ્થિતિ ફાઇલ કંટ્રોલ ચેનલને સ્પર્શ કર્યા વિના તેનો જવાબ આપે છે, અને GUI જોડાયેલું રહે ત્યાં સુધી તે કામ કરતી રહે છે.
status /run/openvpn/server.status 10
management /run/openvpn/server.sock unixઅંતરાલ એ તાજગીનું બજેટ છે, તેથી તેને ડેશબોર્ડને ખરેખર જે જોઈએ તે પ્રમાણે સેટ કરો, સુરક્ષિત લાગતા સૌથી નાના મૂલ્ય પ્રમાણે નહીં. દર થોડી સેકન્ડે લખાતો સ્નેપશોટ સસ્તો છે; દર થોડી સેકન્ડે કંટ્રોલ સોકેટ સાથે ફરી જોડાતી સ્ક્રિપ્ટ સસ્તી નથી, કારણ કે દરેક ફરી કનેક્શન માલિક સાથે હરીફાઈ કરે છે.
સ્નેપશોટ ઇતિહાસ નથી અને ઘટના પ્રવાહ પણ નથી. એક અંતરાલની અંદર આવીને જતા કનેક્શન ક્યારેય દેખાતા નથી, તેથી સ્વયં પર ફરી લખાતી ફાઇલને પોલ કરીને ઓડિટની જરૂરિયાત પૂરી કરી શકાતી નથી. જો તમારે જાણવું હોય કે વપરાશકર્તા જોડાયો હતો કે નહીં, તો સ્નેપશોટ ખોટું સાધન છે.
ફેન-આઉટ એ ડિઝાઇન છે, મોડ નહીં
જો ઘણા ગ્રાહકોને ખરેખર જીવંત મેનેજમેન્ટ ડેટાની જરૂર હોય, તો સોકેટની સામે એક વિશ્વસનીય ઘટક મૂકો અને તેને બાકીના માટે કાળજીપૂર્વક પસંદ કરેલા અવલોકનો પ્રકાશિત કરવા દો. તે જ ઘટક ફરી કનેક્શન, પ્રમાણીકરણ પ્રોમ્પ્ટ અને શું જાહેર કરવું સુરક્ષિત છે તે નિર્ણયનો માલિક છે.
તેને જાણી જોઈને બનાવો: કઈ ક્વેરીની મંજૂરી છે તે વ્યાખ્યાયિત કરો, કોણે પૂછ્યું તે લોગ કરો, અને ફેન-આઉટ સ્તરને અજાણતાં રિમોટ કંટ્રોલ પેનલમાં ફેરવવાનું ટાળો. ડેમનમાં સક્ષમ કરવા માટે કોઈ મલ્ટી-ક્લાયન્ટ મોડ નથી, અને કોઈ કન્ફિગરેશન લાઇન તેને બનાવતી નથી. માલિકને સુરક્ષા સીમાનો ભાગ ગણો, કારણ કે તેની પાસે એવું ઇન્ટરફેસ છે જે લોકોને ડિસ્કનેક્ટ કરી શકે છે. તેને ફરી શરૂ કરવું દસ્તાવેજીકૃત રિકવરી માર્ગ સાથેનું નિયમિત કાર્ય હોવું જોઈએ.
સોકેટને વિશેષાધિકાર ગણો, મેટ્રિક્સ નહીં
મેનેજમેન્ટ ઇન્ટરફેસ વપરાશકર્તાઓને ડિસ્કનેક્ટ કરી શકે છે, સ્થિતિ બદલી શકે છે અને લોકોનાં નામ ધરાવતી ઘટનાઓ વાંચી શકે છે. તેનો પાસવર્ડ ક્લાયન્ટને પ્રમાણિત કરે છે અને પરિવહનને એન્ક્રિપ્ટ કરતો નથી, તેથી નેટવર્ક પરનો શ્રોતા વાતચીતને તે જોઈ શકે તેવા દરેકની સામે ખુલ્લી કરી દે છે.
સ્થાનિક સોકેટ અથવા કડક રીતે મર્યાદિત શ્રોતાને પ્રાધાન્ય આપો, અને તપાસો કે તમારો સંગ્રાહક ખરેખર કઈ પ્રક્રિયાને સંબોધે છે, કારણ કે સર્વર ઉત્પાદનો પોતાના મેનેજમેન્ટ API સાથે આવે છે જે અલગ રીતે વર્તે છે. ખોટા ડેમન તરફ નિર્દેશિત સંગ્રાહક આત્મવિશ્વાસપૂર્ણ અને ખોટા નિષ્કર્ષ આપે છે. કંઈ પણ પાછું ન આપતી ક્વેરીને ડિબગ કરતા પહેલા માર્ગ અને માલિક પ્રક્રિયા ખાતરી કરો.