VPN પ્રમાણપત્ર સત્તાધિકારી બદલો ત્યારે શું થાય છે

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

એક બદલી, બે અલગ ફેરફાર

પ્રમાણપત્ર સત્તાધિકારી એ એક નામ, એક જાહેર કી અને સહી કરતી ખાનગી કી છે. માન્યકર્તા કદી અમૂર્ત રીતે ‘CA’ પર ભરોસો રાખતા નથી. તેઓ ભરોસા સંગ્રહમાં પહેલેથી પડેલા એક ચોક્કસ પ્રમાણપત્ર પર ભરોસો રાખે છે, અને જારીકર્તાને ફક્ત ત્યારે સ્વીકારે છે જ્યારે સહીઓની સાંકળ એ સંગ્રહિત નકલ સુધી પહોંચે. તેથી CA બદલવાથી એવી બે વસ્તુઓ બદલાય છે જે સ્વતંત્ર રીતે નિષ્ફળ જાય છે: કયા એન્કર સ્વીકારવામાં આવે છે અને કઈ સાથી ઓળખ તેમની નીચે જારી થઈ છે.

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

માન્યકર્તા શું ચકાસે છે, ક્રમમાં

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

એ ફેરો ઑફલાઇન ફરી કરવા માટે, -CAfile ને તમે જમાવશો તે ચોક્કસ બંડલ તરફ નિર્દેશ કરો, સિસ્ટમ સંગ્રહ તરફ નહીં. નહીં તો તમે ફેરફાર નહીં, યજમાન ચકાસી રહ્યા છો:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

એ આદેશ ફક્ત ગેટવેના HTTPS સંચાલન પૃષ્ઠ જેવા સાદા TLS શ્રોતા સામે કામ કરે છે; OpenVPNની નિયંત્રણ ચેનલ TLS પહેલાં આવે છે, તેથી s_client ટનલની હેન્ડશેક તપાસી શકતું નથી.

એ ભૂલો પાછળના માર્ગ-નિર્માણના નિયમો RFC 5280 વિભાગ 6 માં છે. તેઓ એ નિષ્ફળતાઓ સમજાવે છે જે નહીં તો મનસ્વી લાગે: કોઈને યાદ ન રહેલું સમાપ્ત વચ્ચેનું પ્રમાણપત્ર, જેનો કી ઉપયોગ સહી પર પ્રતિબંધ મૂકે છે તેવું પ્રમાણપત્ર, અથવા તમે ચકાસી રહ્યા છો તે યજમાનને બાદ કરતી નામ મર્યાદા.

જૂની ટનલ કેમ કામ કરતી રહે છે

TLS અને OpenVPN બંને હેન્ડશેક પૂરી થયા પછી સ્થાપિત સત્રને જીવંત રાખે છે. કંઈ પણ દરેક પેકેટે પીઅર પ્રમાણપત્ર ફરી ચકાસતું નથી, તેથી ફેરફાર પહેલાં જોડાયેલો ક્લાયન્ટ ફરી વાટાઘાટ, ફરી જોડાણ અથવા ટનલ પડે ત્યાં સુધી ટ્રાફિક પસાર કરતો રહે છે. એ જ અંતરને કારણે CA બદલી એક કલાક સારી લાગી શકે અને પછી સૌથી ખરાબ ક્ષણે નિષ્ફળ જાય: લેપટોપ ઊંઘમાંથી જાગે, NAT મેપિંગની મુદત પૂરી થાય, ગેટવે ફરી શરૂ થાય.

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

સ્થિર-કી સ્તરને આથી અલગ રાખો. tls-auth નિયંત્રણ ચેનલમાં HMAC ઉમેરે છે, tls-crypt તેને એન્ક્રિપ્ટ અને પ્રમાણિત કરે છે, અને બંનેથી કોઈ પ્રમાણપત્ર સામગ્રી વહન કરતું નથી, તેથી બંનેથી કોઈનું પણ પરિભ્રમણ પોતાની નિષ્ફળતા-રીત સાથે અલગ ફેરફાર છે. જે જમાવટ બંનેને ભેળવી દે છે તે એવા ક્લાયન્ટ પર પૂરી થાય છે જેની સ્થિર કી બરાબર છે, પ્રમાણપત્ર જૂનું છે અને ભૂલ સંદેશ બંનેથી કોઈનો ઉલ્લેખ કરતો નથી.

વિષય નામ ફરી વાપરવાની જાળ

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

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

નેતવર્ક પાડી ન નાખતું પરિભ્રમણ

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

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

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

પરિણામ ચકાસો, ફાઇલોની યાદી નહીં

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

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

એવા ક્લાયન્ટ સાથે પૂરું કરો જે કદી જોડાયો નથી: તેની પ્રોફાઇલ સ્થિતિ ભૂંસો, જોડાઓ અને વાટાઘાટ થયેલી સાંકળ વાંચો. કેશ થયેલું સત્ર પુનઃસ્થાપિત કરતો સાથી આનંદથી જાહેર કરશે કે સ્થળાંતર સફળ થયું, જ્યારે તેણે કંઈ ચકાસ્યું જ નથી.