Bakit ang muling pag-import ng sertipiko ng Client VPN ay nangangailangan ng bagong endpoint

Naputol ang koneksyon ng Client VPN, pinapalitan ang sertipiko sa ACM, at walang nagbabago. Ang object ng sertipiko ay hindi kailanman ang ginagamit ng endpoint. Nag-iimbak ang endpoint sa paggawa ng ugnayan sa isang sertipiko, kasama ang client CA na pagbabatayan nito, ang uri ng pagpapatunay, ang mga subnet at ang mga tuntunin ng awtorisasyon, at wala sa mga ugnayang ito ang may tawag sa pagbabago na tumatanggap ng kapalit na sertipiko. Ang pagpapalit ng mga byte sa likod ng ARN ay pagbabago sa sertipiko, hindi sa endpoint na kumuha nito.

Nag-iimbak ang endpoint ng mga sanggunian, hindi mga sertipiko

Sulit na sabihin ang mekanismong ito nang tumpak dahil ipinapaliwanag nito ang buong kabiguan. Kumukuha ang create-client-vpn-endpoint ng ARN ng sertipiko ng server at ARN ng kadena ng root certificate ng client, at pinapanatili ng resultang endpoint ang mga sangguniang iyon kasama ang mga opsyon sa pagpapatunay bilang mga fixed property. Walang iniaalok ang API na operasyong nagpapalit ng sertipiko ng server sa umiiral na endpoint.

Mapapatunayan mo ang ugnayan nang hindi nanghuhula. Ipinapakita ng aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 ang ARN ng sertipiko, ang ARN ng root chain ng client, ang uri ng pagpapatunay, ang CIDR ng client at ang mga kaugnay na subnet, na siyang buong hanay ng mga katangiang kailangan mong muling gawin. Patakbuhin ito bago at pagkatapos ng muling pag-import at hindi gumagalaw ang output. Iyon ang patunay na hindi kailanman makakatulong ang muling pag-import.

Bakit hindi maabot ng muling pag-import ang endpoint

Nagsusulat ang muling pag-import ng bagong katawan ng sertipiko sa ilalim ng umiiral na ARN. Lehitimong operasyon iyon kapag malapit nang mag-expire ang sertipiko, at tatanggapin ito ng ACM hangga't tumutugma ang pribadong susi at nagva-validate ang kadena. Ang hindi nito ginagawa ay patakbuhin muli ang pagpapatunay noong ginawa ang endpoint, kaya nananatili ang ugnayan at ang materyal sa likod nito tulad noong itinayo ang endpoint.

Kaya nga ang sintomas ay parang sira ng network. Nabigo o nag-reset ang TLS handshake bago pa man suriin ang awtorisasyon, kaya ang mga security group, ruta at tuntunin ng awtorisasyon ay mukhang inosente, at ganoon nga sila.

Bahagi ng sertipiko ng client ang kadena

Nasa sertipiko ng client ang ikalawang kalahati ng kabiguan, at mas madaling ipagwalang-bahala. Dapat i-import ang sertipiko ng client kasama ang kadenang naglabas nito, kahit ipinapakita ng form ng pag-import ang field na iyon bilang opsyonal. Kung walang kadena, hindi makakabuo ang endpoint ng landas mula sa sertipiko ng client hanggang sa root CA ng client na ginamit sa pag-configure, at nagtatapos ang koneksyon sa malambot na reset na parang firewall na nagtatapon ng mga packet. Sinasagot ng openssl verify -CAfile root-ca.pem client.crt ang tanong na iyon nang lokal sa isang segundo, at iyon dapat ang unang command na patakbuhin mo.

Ang muling pag-import kasama ang kadena ay tunay na pagwawasto para sa kalahating iyon, at hindi pa rin ito sapat nang mag-isa. Kapag nagbago na ang object sa ACM, ang endpoint na may lumang ugnayan ang maling bagay na patuloy na susubukan. Parehong hakbang ay kabilang sa isang pag-aayos, kaya hindi kontradiksiyon ang dalawang-bahaging pagwawasto.

Ang muling paggawa ng endpoint ay isang migrasyon

Ang paggawa ng kapalit na endpoint ay migrasyon, hindi bagong pagtatangka, at ang pagtrato dito bilang bagong pagtatangka ang paraan ng pagtatapos ng mga team sa dalawang kalahating-configure na endpoint. Nakakakuha ang bagong endpoint ng bagong ID at, maliban kung pinlano mo, bagong DNS name para sa bawat user. Panatilihing nakaturo ang profile ng client sa isang pangalan sa halip na address, para maging pagbabago ng record ang paglipat at hindi muling pamamahagi.

Maikli ang orden na nagpapanatili nitong ligtas: gumawa ng bagong endpoint na may parehong CIDR, subnet at tuntunin ng awtorisasyon, i-export ang sariwang profile gamit ang aws ec2 export-client-vpn-client-configuration, at i-verify sa isang user. Pagkatapos lang niyon ibinababa ang lumang endpoint.

May sariling orden ang pagretiro sa lumang endpoint. Bawiin ang mga sertipiko ng client na balak mong iretiro bago ito tanggalin, dahil ang bagong endpoint na nagtitiwala pa sa lumang CA ay patuloy na tumatanggap ng mga sertipikong akala mo ay wala na. Pagkatapos ay tanggalin ang lumang endpoint at alisin ang mga tuntunin ng awtorisasyon nito, para hindi makakonekta muli ang lumang profile sa target network na akala mo ay sarado. Isulat ang ID ng lumang endpoint at ang mga identifier ng ugnayan sa record ng pagbabago, dahil ang migrasyong inihambing sa memorya ang paraan ng paggawa muli ng gumaganang endpoint nang dalawang beses.

Ayusin ang diagnosis

Paghiwalayin ang tatlong kabiguan bago baguhin ang anumang configuration. Hindi makumpleto ng client ang TLS, nakumpleto ng client ang TLS at hindi awtorisado, o kumokonekta ang client at hindi naabot ang destinasyon. Ang ugnayan ng sertipiko ay sa una, ang tuntunin ng awtorisasyong hindi sumasaklaw sa address ng client ay sa pangalawa, at ang ruta o security group ay sa pangatlo, kung saan ang muling paggawa ng endpoint ay halos palaging maling hakbang.

Ang endpoint na gumana nang mga buwan at pagkatapos ay tumigil, nang walang pagbabago sa sertipiko o patakaran, ay sariling kaso. Maaaring maibalik ng muling paggawa nito na may parehong setting ang serbisyo, ngunit iyon ay dahilan para panatilihing maaaring muling gawin ang configuration, hindi dahilan para muling gawin sa bawat insidente.

Panatilihin ang apat na bagay sa ilalim ng version control para ang susunod na muling paggawa ay diff at hindi improvisasyon: ang mga parameter ng endpoint, ang ARN ng sertipiko at kadena, ang mga tuntunin ng awtorisasyon at ang CIDR ng client. Inililista ng dokumentasyon ng pagpapatunay ng Client VPN kung aling sertipiko ang gumaganap ng aling papel, na sulit suriin bago ipagpalagay na sertipiko ang problema. Kung walang binabago ang muling pag-import at nagre-reset pa rin ang endpoint, ang ugnayan ang pinaghihinalaan at ang sagot ay bagong endpoint na itinayo mula sa naitalang parameter. Kung tinatanggap nga ng endpoint ang bagong object, tama na ang ugnayan at nasa kadena ng client o layer ng awtorisasyon ang depekto.