Access Server થી Community OpenVPN: શું ફરી બનાવવું પડશે

Access Server અને Community OpenVPN એક જ પ્રોટોકોલ બોલે છે અને બાકી લગભગ કંઈ જ એકસરખી રીતે નહીં. હેન્ડશેક, સાઇફર વાટાઘાટ અને ટનલનો ડેટા પ્લેન સુસંગત છે, તેથી ક્લાયન્ટ ઘણી વાર પોતાની પ્રોફાઇલ બદલ્યા વિના બંનેમાંથી કોઈપણ સાથે જોડાઈ શકે છે. ફરક એ છે કે રૂપરેખા કોની માલિકીની છે: એક ઉત્પાદન સાથે નીતિ લખતું અને લાગુ કરતું મેનેજમેન્ટ સ્તર આવે છે, બીજું તમને રૂપરેખા ફાઇલ અને હૂકનો સમૂહ આપે છે અને ધારે છે કે તમે નિર્ણય લેશો.

એ જ ભેદ માઇગ્રેશન યોજના છે. જૂના ઉત્પાદને તમારા વતી નક્કી કરેલું દરેક વસ્તુ નવા ડિપ્લોયમેન્ટમાં ક્યાંક સ્પષ્ટ નિર્ણય બનવું પડશે.

જ્યાં બંને ડિપ્લોયમેન્ટ અદલાબદલી કરી શકાય તેવા રહેતા નથી

Access Server માં, વેબ એડમિનિસ્ટ્રેશન ઇન્ટરફેસ વપરાશકર્તાઓ, જૂથો, પ્રતિ-વપરાશકર્તા પરવાનગીઓ, પ્રમાણપત્ર ઇશ્યુ કરવું અને વ્યક્તિ ડાઉનલોડ કરે તે પ્રોફાઇલ બંડલ ધરાવે છે. નીચેનો ડીમન તે સ્તર દ્વારા ગોઠવાય છે, તેથી ચાલતી સેવા સંગ્રહિત સ્થિતિનું પરિણામ છે જેને તમે ભાગ્યે જ હાથે બદલો છો. Community OpenVPN માં રૂપરેખા ફાઇલ જ સ્થિતિ છે: તે લિસનર, પ્રમાણપત્ર સત્તાધિકારી, પ્રમાણીકરણ હૂક અને દરેક પુશ કરેલ વિકલ્પનું નામ આપે છે, અને કંઈ પણ તમારા વતી તેને ફરી લખતું નથી. એટલે એ જ TLS મશીનરી બે ખૂબ જ અલગ માલિકી મોડેલ હેઠળ રહે છે.

ટૂંકું મેપિંગ અંતરને મૂર્ત બનાવે છે. વપરાશકર્તાઓ અને જૂથો ફક્ત જૂના ડેટાબેઝમાં જ હોય છે જ્યાં સુધી તમે તેમને ફરી બનાવો નહીં. પ્રોફાઇલ બંડલ રૂપરેખા ફાઇલ અને તમે જ વિતરણ કરો તે પ્રમાણપત્રો બને છે. પ્રતિ-વપરાશકર્તા પરવાનગીઓ client-config-dir માં નિર્દેશો બને છે. એડમિનિસ્ટ્રેશન ઇન્ટરફેસ એ પ્રક્રિયા બને છે જે તમે પ્રમાણપત્રો ઇશ્યુ કરવા અને ફાઇલો સંપાદિત કરવા પસંદ કરો.

સર્વરને અડકતા પહેલા તે મેપિંગ લખી લો. તમે ભરી ન શકો તે દરેક હરોળ એ લક્ષણ છે જે તમે હમણાં જ ગુમાવવા જઈ રહ્યા છો, અને ચૂપચાપ ગુમાવવું એ જ રીતે બે અઠવાડિયા પછી માઇગ્રેશન વિક્ષેપ બને છે.

ઓળખ પ્રમાણપત્ર ફાઇલો સાથે સ્થાનાંતરિત થતી નથી

જૂની સત્તાધિકારીના પ્રમાણપત્રો નવી સેવામાં યોગ્ય રીતે પાર્સ થઈ શકે અને તો પણ ખોટી ઓળખ હોય, કારણ કે જૂના ઉત્પાદને તેમને એવી ખાતા સ્થિતિ સાથે જોડ્યા હતા જે નવું જોઈ શકતું નથી. પહેલા નક્કી કરો કે નવું ડિપ્લોયમેન્ટ ફક્ત પ્રમાણપત્રથી, PAM કે RADIUS સુધી પહોંચતા પ્લગઇનથી, કે બંનેના સંયોજનથી પ્રમાણીકરણ કરે છે, પછી ચકાસો કે દરેક વિકલ્પ તમને જરૂરી ગુણધર્મો જાળવી રાખે છે. પ્રતિ-વપરાશકર્તા ઓળખ વિનાનું વહેંચાયેલું પ્રમાણપત્ર તે ધરાવનાર દરેક માટે એક જ ઓળખપત્ર છે. રદ કરવાનું પણ પહેલા દિવસથી કામ કરવું જોઈએ, જે Community OpenVPN માં crl-verify દ્વારા સંદર્ભિત CRL ફાઇલ અને તેને ફરી બનાવતી પ્રક્રિયા એમ બે વસ્તુઓ દર્શાવે છે.

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

રૂટિંગ અને નામ-ઉકેલ રૂપરેખા લખનારને અનુસરે છે

માર્ગો, DNS સેટિંગ્સ અને પૂર્ણ-ટનલ વર્તન બંને ઉત્પાદનોમાં પુશ કરેલા વિકલ્પો છે, પણ તેમાંથી ફક્ત એક જ તમારા માટે તેની ગણતરી કરે છે. Community OpenVPN માં તમે પુશ નિર્દેશો જાતે લખો છો, redirect-gateway સર્વર પર રહે કે ક્લાયન્ટ પર તે નક્કી કરો છો, અને ખાતરી કરો છો કે હોસ્ટ પર ફોરવર્ડિંગ અને NAT છે. પૂર્ણ થયેલો હેન્ડશેક ફોરવર્ડિંગ, સરનામા અનુવાદ કે ક્લાયન્ટને ખરેખર મળેલા માર્ગો વિશે કંઈ કહેતો નથી.

પ્રતિ-ક્લાયન્ટ વર્તન માટે client-config-dir અને ક્લાયન્ટના પ્રમાણપત્રના common name પરથી નામ ધરાવતી ફાઇલ જરૂરી છે, અને સાઇટ-થી-સાઇટ પીઅર માટે તેની પાછળના પ્રીફિક્સ માટે iroute પ્રવેશો જરૂરી છે. નામ ખોટું હોય તો વિકલ્પો કોઈ ભૂલ વિના અવગણવામાં આવે છે. પોતાના સરનામા પૂલમાં એક બિન-ઉત્પાદન ક્લાયન્ટ સાથે પરીક્ષણ કરો, પછી તેને આપેલું સરનામું, તેને મળેલા માર્ગો અને તે જે રિઝોલ્વર સેટિંગ્સ સાથે પૂરો થયો તે વાંચો.

કટઓવરને એવી રીતે ગોઠવો કે જૂની સેવા પાછી આવી શકે

નવું લિસનર બીજા પોર્ટ કે સરનામા પર ચલાવો, અને બદલી સાબિત કરતી વખતે જૂનાને ટ્રાફિક આપતી રાખો. એક જ સોકેટ પર બે ડીમન રોલબેક યોજના નથી.

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

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

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