Client VPN પ્રમાણપત્ર ફરી આયાત કરવા માટે નવા એન્ડપોઇન્ટની જરૂર કેમ છે

Client VPN કનેક્શન તૂટે છે, ACM માંનું પ્રમાણપત્ર બદલાય છે, અને કંઈ બદલાતું નથી. પ્રમાણપત્ર ઑબ્જેક્ટ એ ક્યારેય એ વસ્તુ ન હતું જે એન્ડપોઇન્ટ વાપરી રહ્યું હતું. એન્ડપોઇન્ટ બનાવવાના સમયે પ્રમાણપત્ર સાથે સંલગ્નતા સાચવે છે, સાથે જે ક્લાયન્ટ CA સામે તે માન્યતા ચકાસશે, પ્રમાણીકરણનો પ્રકાર, સબનેટ અને અધિકૃતિના નિયમો, અને આ સંલગ્નતાઓમાંથી કોઈમાં પણ બદલીનો કૉલ નથી જે રિપ્લેસમેન્ટ પ્રમાણપત્ર સ્વીકારે. ARN પાછળના બાઇટ્સ બદલવા એ પ્રમાણપત્રમાં ફેરફાર છે, જે એન્ડપોઇન્ટે તેને પકડ્યું તેમાં નહીં.

એન્ડપોઇન્ટ સંદર્ભો સાચવે છે, પ્રમાણપત્રો નહીં

આ મિકેનિઝમ ચોક્કસ રીતે કહેવા યોગ્ય છે, કારણ કે તે આખી નિષ્ફળતા સમજાવે છે. create-client-vpn-endpoint સર્વર પ્રમાણપત્રનું ARN અને ક્લાયન્ટ રૂટ પ્રમાણપત્ર સાંકળનું ARN લે છે, અને પરિણામી એન્ડપોઇન્ટ તે સંદર્ભોને પ્રમાણીકરણ વિકલ્પો સાથે નિશ્ચિત ગુણધર્મો તરીકે રાખે છે. API હાલના એન્ડપોઇન્ટ પર સર્વર પ્રમાણપત્ર બદલતું કોઈ કામગીરી આપતું નથી.

તમે અનુમાન કર્યા વિના જોડાણની ખાતરી કરી શકો છો. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 પ્રમાણપત્રનું ARN, ક્લાયન્ટ રૂટ સાંકળનું ARN, પ્રમાણીકરણનો પ્રકાર, ક્લાયન્ટ CIDR અને સંબંધિત સબનેટ છાપે છે, જે તમારે પુનઃઉત્પાદિત કરવા પડે તેવા ગુણધર્મોનો સંપૂર્ણ સમૂહ છે. ફરી આયાત પહેલાં અને પછી તેને ચલાવો, આઉટપુટ હલશે નહીં. એ જ પુરાવો છે કે ફરી આયાત ક્યારેય મદદ કરવાની ન હતી.

ફરી આયાત એન્ડપોઇન્ટ સુધી કેમ પહોંચી શકતી નથી

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

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

સાંકળ ક્લાયન્ટ પ્રમાણપત્રનો ભાગ છે

નિષ્ફળતાનો બીજો અડધો ભાગ ક્લાયન્ટ પ્રમાણપત્રમાં છે, અને તેને બાજુ પર મૂકવો સહેલો છે. ક્લાયન્ટ પ્રમાણપત્ર તેને જારી કરનાર સાંકળ સાથે આયાત કરવું જ પડે, જોકે આયાત ફોર્મ તે ક્ષેત્રને વૈકલ્પિક તરીકે દર્શાવે છે. સાંકળ વિના એન્ડપોઇન્ટ ક્લાયન્ટ પ્રમાણપત્રથી જે ક્લાયન્ટ રૂટ CA સાથે તેને ગોઠવવામાં આવ્યું હતું ત્યાં સુધીનો માર્ગ બનાવી શકતું નથી, અને કનેક્શન નરમ રીસેટમાં પૂરું થાય છે જે પેકેટ પડતા મૂકતા ફાયરવોલ જેવું લાગે છે. openssl verify -CAfile root-ca.pem client.crt એ પ્રશ્નનો સ્થાનિક રીતે એક સેકન્ડમાં જવાબ આપે છે, અને તમે ચલાવો તે પહેલો આદેશ એ જ હોવો જોઈએ.

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

એન્ડપોઇન્ટ ફરી બનાવવું એ સ્થળાંતર છે

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

આને સુરક્ષિત રાખતો ક્રમ ટૂંકો છે: એ જ CIDR, સબનેટ અને અધિકૃતિ નિયમો સાથે નવું એન્ડપોઇન્ટ બનાવો, aws ec2 export-client-vpn-client-configuration સાથે તાજી પ્રોફાઇલ નિકાસ કરો, અને એક વપરાશકર્તા સાથે ચકાસો. એ પછી જ જૂનું એન્ડપોઇન્ટ નીચે આવે છે.

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

નિદાનનો ક્રમ ગોઠવો

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

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

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