Kial reimportado de Client VPN-atestilo postulas novan finpunkton

Client VPN-konekto rompiĝas, la atestilo en ACM anstataŭiĝas, kaj nenio ŝanĝiĝas. La atestila objekto neniam estis tio, kion la finpunkto uzis. Finpunkto konservas ĉe kreado asociiĝon al atestilo, kune kun la klienta CA kontraŭ kiu ĝi validigos, la aŭtentiga tipo, la subretoj kaj la rajtigaj reguloj, kaj neniu el tiuj asociiĝoj havas modifan alvokon, kiu akceptas anstataŭan atestilon. Anstataŭigi la bajtojn malantaŭ ARN estas ŝanĝo en la atestilo, ne en la finpunkto, kiu kaptis ĝin.

La finpunkto konservas referencojn, ne atestilojn

La mekanismon indas esprimi precize, ĉar ĝi klarigas la tutan malsukceson. create-client-vpn-endpoint prenas ARN de servila atestilo kaj ARN de klienta radika atestila ĉeno, kaj la rezulta finpunkto tenas tiujn referencojn kune kun la aŭtentigaj opcioj kiel fiksajn ecojn. La API ne proponas operacion, kiu interŝanĝas la servilan atestilon en ekzistanta finpunkto.

Vi povas konfirmi la ligon sen diveni. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 presas la atestilan ARN, la ARN de la klienta radika ĉeno, la aŭtentigan tipon, la klientan CIDR kaj la rilatajn subretojn, kio estas la plena aro de ecoj, kiujn vi devus reprodukti. Rulu ĝin antaŭ kaj post reimportado kaj la eligo ne moviĝas. Tio estas la pruvo, ke la reimportado neniam helpos.

Kial reimportado ne povas atingi la finpunkton

Reimportado skribas novan atestilan korpon sub ekzistanta ARN. Tio estas laŭleĝa operacio, kiam atestilo proksimas al eksvalidiĝo, kaj ACM akceptos ĝin kondiĉe ke la privata ŝlosilo kongruas kaj la ĉeno validiĝas. Kion ĝi ne faras, estas relanĉi la validigon de la krea momento de la finpunkto, do la asociiĝo kaj la materialo malantaŭ ĝi restas tiaj, kiaj ili estis kiam la finpunkto estis konstruita.

Tial ankaŭ la simptomo aspektas kiel reta paneo. La TLS-manpremo malsukcesas aŭ resetiĝas antaŭ ol la rajtigo entute taksiĝas, do sekurgrupoj, vojoj kaj rajtigaj reguloj ĉiuj aspektas senkulpaj, kaj ili estas.

La ĉeno estas parto de la klienta atestilo

La dua duono de la malsukceso estas en la klienta atestilo, kaj ĝi estas pli facile preteratentebla. Klienta atestilo devas esti importita kun la ĉeno, kiu eldonis ĝin, kvankam la importa formularo prezentas tiun kampon kiel laŭvolan. Sen la ĉeno la finpunkto ne povas konstrui vojon de la klienta atestilo al la klienta radika CA, kun kiu ĝi estis agordita, kaj la konekto finiĝas per mola reseto, kiu aspektas kiel fajroŝirmilo faliganta pakojn. openssl verify -CAfile root-ca.pem client.crt respondas tiun demandon loke en sekundo, kaj ĝi devus esti la unua komando, kiun vi rulas.

Reimportado kun la ĉeno estas vera riparo por tiu duono, kaj ĝi ankoraŭ ne sufiĉas sola. Post kiam la ACM-objekto ŝanĝiĝis, la finpunkto tenanta la malnovan asociiĝon estas la malĝusta afero por daŭre testi kontraŭe. Ambaŭ paŝoj apartenas al la sama riparo, kaj tial la duparta riparo ne estas kontraŭdiro.

Rekrei finpunkton estas migrado

Krei anstataŭan finpunkton estas migrado, ne reprovo, kaj trakti ĝin kiel reprovon estas kiel teamoj finiĝas kun du duonagorditaj finpunktoj. La nova finpunkto ricevas novan ID kaj, se vi ne planis tion, novan DNS-nomon por ĉiu uzanto. Tenu la klientan profilon montranta al nomo anstataŭ al adreso, por ke la anstataŭigo fariĝu rikorda ŝanĝo anstataŭ redistribuo.

La ordo, kiu tenas tion sekura, estas mallonga: kreu la novan finpunkton kun la sama CIDR, subretoj kaj rajtigaj reguloj, eksportu freŝan profilon per aws ec2 export-client-vpn-client-configuration, kaj kontrolu per unu uzanto. Nur poste la malnova finpunkto malsupreniĝas.

Maldaŭrigi la malnovan finpunkton havas sian propran ordon. Revoku la klientajn atestilojn, kiujn vi intencis emeritigi, antaŭ ol forigi ĝin, ĉar nova finpunkto, kiu ankoraŭ fidas la malnovan CA, daŭre akceptas atestilojn, kiujn vi kredis malaperintaj. Poste forigu la malnovan finpunkton kaj forigu ĝiajn rajtigajn regulojn, por ke eksdata profilo ne povu rekonektiĝi al celreta reto, kiun vi pensis fermita. Skribu la ID de la malnova finpunkto kaj la asociigajn identigilojn en la ŝanĝan rikordon, ĉar migrado komparata kun memoro estas kiel funkcianta finpunkto rekonstruiĝas dufoje.

Ordigu la diagnozon

Apartigu tri paneojn antaŭ ol ŝanĝi ajnan agordon. La kliento ne povas fini TLS, la kliento finas TLS kaj ne estas rajtigita, aŭ la kliento konektiĝas kaj ne povas atingi celon. Atestila asociiĝo apartenas al la unua, rajtiga regulo, kiu ne kovras la klientan adreson, apartenas al la dua, kaj vojo aŭ sekurgrupo apartenas al la tria, kie rekrei finpunkton preskaŭ ĉiam estas la malĝusta movo.

Finpunkto, kiu funkciis monatojn kaj poste haltis, sen atestila aŭ politika ŝanĝo, estas aparta kazo. Rekonstrui ĝin kun identaj agordoj povas restarigi la servon, sed tio estas kialo teni la agordon reproduktebla, ne kialo rekonstrui ĉe ĉiu okazaĵo.

Tenu kvar aferojn sub versikontrolo, por ke la sekva rekonstruo estu diff anstataŭ improvizado: la parametroj de la finpunkto, la atestilaj kaj ĉenaj ARN-oj, la rajtigaj reguloj kaj la klienta CIDR. La dokumentaro pri aŭtentigo de Client VPN listigas, kiu atestilo ludas kiun rolon, kion indas kontroli antaŭ ol supozi, ke atestilo estas la problemo. Se reimportado ŝanĝas nenion kaj la finpunkto ankoraŭ resaltas, la asociiĝo estas la suspektato kaj la respondo estas nova finpunkto konstruita el la registritaj parametroj. Se la finpunkto tamen prenas la novan objekton, la asociiĝo jam estis ĝusta kaj la paneo estas en la klienta ĉeno aŭ la rajtiga tavolo.