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

બે ઉમેદવારો જુદી જુદી વસ્તુઓ ધરાવે છે

સમર્થિત કન્ફિગરેશન સ્રોત એ છે જેને ઉપકરણ ઇનપુટ તરીકે ગણે છે: GUI ફીલ્ડ, આયાત કરેલ પ્રોફાઇલ, દરેક ક્લાયન્ટ માટે દસ્તાવેજીકૃત ડિરેક્ટરી, મેનેજમેન્ટ પેકેજ વાંચતો સેટિંગ્સ ડેટાબેઝ. જનરેટ થયેલ server.conf આઉટપુટ છે. આઉટપુટ સંપાદિત કરવું ત્યાં સુધી કામ કરે છે જ્યાં સુધી જનરેટર ફરી ન ચાલે, અને તે સેવ પર, રીબૂટ પર અને અપગ્રેડ પર થાય છે.

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

QuestionSupported config sourcePost-generation script
Survives a GUI saveYesOnly if the save does not regenerate the file
Survives a package upgradeUsually, when the field is documentedNo guarantee; the wrapper can be replaced
Supportable by the vendorYesNo
Obvious to the next adminYes, it is in the UINo, it lives in a wrapper

ઉપકરણ શું ફરીથી જનરેટ કરે છે, અને ક્યારે

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

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

સમર્થિત માલિકે શું વ્યક્ત કરવું જોઈએ

શાખા પ્રીફિક્સને એક નહીં, ત્રણ વિધાનોની જરૂર છે. ક્લાયન્ટે માર્ગ શીખવો જોઈએ, સર્વરે જાણવું જોઈએ કે કયો પ્રમાણિત ક્લાયન્ટ પ્રીફિક્સ ધરાવે છે, અને શાખા બાજુએ ટ્રાફિક તેને આપેલા ટનલ સરનામે પરત મોકલવો જોઈએ. OpenVPN શબ્દોમાં તેનો અર્થ થાય છે પુશ કરેલ route, ક્લાયન્ટ સાથે બંધાયેલ મેળ ખાતું iroute, અને બીજી બાજુએ પરત માર્ગ.

અહીં ઉપકરણ UI ભ્રમિત કરે છે. “ક્લાયન્ટને સર્વરના LAN માં પ્રવેશ આપો” લેબલવાળું ચેકબોક્સ સર્વરના પોતાના નેટવર્ક તરફના ટ્રાફિકનું વર્ણન કરે છે. તમારી શાખા વિરુદ્ધ દિશા છે: એક ક્લાયન્ટની પાછળનું નેટવર્ક, સર્વર બાજુથી પહોંચી શકાય તેવું. એ જ લેબલ તેના માટે સમર્થન સૂચવતું નથી, અને ફાઇલમાં માન્ય ડાયરેક્ટિવ એ વચન નથી કે પેકેજ તેને સાચવશે.

જ્યારે કોઈ સમર્થિત નિયંત્રણ ન હોય

ક્યારેક સ્થાપિત આવૃત્તિ ખરેખર સાથી-વિશિષ્ટ માર્ગ વ્યક્ત કરી શકતી નથી. પછી પ્રામાણિક વિકલ્પો છે તમે નિયંત્રિત કરો છો તેવું બીજું ગેટવે, અથવા બંને છેડે સમર્થિત સાઇટ-થી-સાઇટ મોડ. બંને છેડાએ તે બોલવું પડે. સાઇટ-થી-સાઇટ કહેતું ઉત્પાદન પૃષ્ઠ કોઈપણ OpenVPN પ્રોફાઇલને બીજા પ્રોટોકોલની ટનલ સાથે બદલી શકાય તેવું બનાવતું નથી, અને તે જોડીને ફરજિયાત કરવાથી સામાન્ય રીતે અડધું જોડાયેલી ટનલ બને છે જે સ્થિતિ પૃષ્ઠ પર સારી દેખાય છે.

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

હેતુને ઓડિટયોગ્ય બનાવો

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

કંઈક તૂટે ત્યારે જનરેટ થયેલ પરિણામની તે રેકોર્ડ સાથે સરખામણી કરો, અસ્પષ્ટ લાઇન પુનઃસ્થાપિત કરી આશા રાખવાને બદલે.OpenVPN 2.6 સંદર્ભ એ UI સાથે દલીલ કરતા પહેલા route અને iroute કેવી રીતે પરસ્પર ક્રિયા કરે છે તેની પુષ્ટિ કરવાની જગ્યા છે.

આગલા ફેરફાર માટે ચેકલિસ્ટ: માલિકનું નામ આપો, ત્રણ-ભાગનો કરાર જણાવો, હેતુ નિકાસ કરો, અને તમારા સંપાદન પછી નહીં, ઉપકરણની પોતાની જીવનચક્ર ઘટનાઓ પછી ફરી પરીક્ષણ કરો.

સંબંધિત લેખો