Kodėl iš naujo importuojant Client VPN sertifikatą reikia naujo galinio taško

Client VPN ryšys nutrūksta, sertifikatas ACM pakeičiamas, ir niekas nesikeičia. Sertifikato objektas niekada nebuvo tai, ką naudojo galinis taškas. Galinis taškas kūrimo metu išsaugo siejimą su sertifikatu, kartu su kliento CA, pagal kurią jis tikrins, autentifikavimo tipu, potinkliais ir autorizavimo taisyklėmis, ir nė vienas iš šių siejimų neturi keitimo iškvietimo, kuris priimtų pakaitinį sertifikatą. Baitų už ARN pakeitimas yra sertifikato pakeitimas, o ne galinio taško, kuris jį užfiksavo.

Galinis taškas saugo nuorodas, o ne sertifikatus

Mechanizmą verta suformuluoti tiksliai, nes jis paaiškina visą gedimą. create-client-vpn-endpoint paima serverio sertifikato ARN ir kliento šakninio sertifikato grandinės ARN, o gautas galinis taškas išsaugo šias nuorodas kartu su autentifikavimo parinktimis kaip fiksuotas savybes. API nesiūlo operacijos, kuri pakeistų serverio sertifikatą esamame galiniame taške.

Siejimą galite patvirtinti neatspėdami. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 išspausdina sertifikato ARN, kliento šakninės grandinės ARN, autentifikavimo tipą, kliento CIDR ir susijusius potinklius, tai yra visas savybių rinkinys, kurį turėtumėte atkartoti. Paleiskite jį prieš ir po pakartotinio importo, ir išvestis nejudės. Tai įrodymas, kad pakartotinis importas niekada nepadėtų.

Kodėl pakartotinis importas negali pasiekti galinio taško

Pakartotinis importas įrašo naują sertifikato turinį po esamu ARN. Tai teisėta operacija, kai sertifikatas artėja prie galiojimo pabaigos, ir ACM ją priims, jei privatus raktas atitinka ir grandinė patikrinama. Ko ji nedaro, tai iš naujo nevykdo galinio taško kūrimo metu atlikto tikrinimo, todėl siejimas ir medžiaga už jo lieka tokie, kokie buvo statant galinį tašką.

Štai kodėl simptomas atrodo kaip tinklo gedimas. TLS rankos paspaudimas nepavyksta arba atstatomas dar neįvertinus autorizavimo, todėl saugos grupės, maršrutai ir autorizavimo taisyklės atrodo nekalčiausios, ir tokios yra.

Grandinė yra kliento sertifikato dalis

Antroji gedimo pusė yra kliento sertifikate, ir ją lengviau atmesti. Kliento sertifikatas turi būti importuojamas su jį išduodančia grandine, nors importo forma tą lauką pateikia kaip neprivalomą. Be grandinės galinis taškas negali nutiesti kelio nuo kliento sertifikato iki kliento šakninės CA, su kuria buvo sukonfigūruotas, ir ryšys baigiasi švelniu atstatymu, kuris skamba kaip paketus metantis ugniasienė. openssl verify -CAfile root-ca.pem client.crt atsako į šį klausimą vietoje per sekundę, ir tai turėtų būti pirmoji komanda, kurią paleisite.

Pakartotinis importas su grandine yra tikras tos pusės pataisymas, ir vis tiek jo vieno nepakanka. Kai ACM objektas pasikeitė, galinis taškas su sena sąsaja yra netinkamas dalykas, su kuriuo toliau testuoti. Abu žingsniai priklauso tam pačiam remontui, todėl dviejų dalių pataisymas nėra prieštaravimas.

Galinio taško atkūrimas yra migracija

Pakaitinio galinio taško kūrimas yra migracija, o ne pakartotinis bandymas, ir traktavimas kaip pakartotinio bandymo yra kelias, kuriuo komandos atsiduria su dviem pusiau sukonfigūruotais galiniais taškais. Naujas galinis taškas gauna naują ID ir, jei to neplanavote, naują DNS vardą kiekvienam vartotojui. Laikykite kliento profilį nukreiptą į vardą, o ne į adresą, kad keitimas taptų įrašo pakeitimu, o ne perskirstymu.

Tvarka, kuri tai išlaiko saugu, trumpa: sukurkite naują galinį tašką su tuo pačiu CIDR, potinkliais ir autorizavimo taisyklėmis, eksportuokite naują profilį su aws ec2 export-client-vpn-client-configuration ir patikrinkite su vienu vartotoju. Tik po to senas galinis taškas nuimamas.

Seno galinio taško išėmimas iš eksploatacijos turi savo tvarką. Atšaukite kliento sertifikatus, kuriuos ketinote išimti, prieš jį ištrindami, nes naujas galinis taškas, vis dar pasitikintis sena CA, toliau priima sertifikatus, kuriuos manėte dingus. Tada ištrinkite seną galinį tašką ir pašalinkite jo autorizavimo taisykles, kad pasenęs profilis negalėtų vėl prisijungti prie tikslo tinklo, kurį manėte uždarytą. Įrašykite seno galinio taško ID ir siejimų identifikatorius į pakeitimų įrašą, nes migracija, lyginama su atmintimi, yra kelias, kuriuo veikiantis galinis taškas atstatomas du kartus.

Sudėliokite diagnostiką

Atskirkite tris gedimus prieš keisdami bet kokią konfigūraciją. Klientas negali užbaigti TLS, klientas užbaigia TLS ir nėra autorizuotas, arba klientas prisijungia ir nepasiekia paskirties. Sertifikato siejimas priklauso pirmajam, autorizavimo taisyklė, neapimanti kliento adreso, antrajam, o maršrutas ar saugos grupė trečiajam, kur galinio taško atkūrimas beveik visada yra neteisingas žingsnis.

Galinis taškas, veikęs mėnesius ir tada sustojęs, be jokių sertifikato ar politikos pakeitimų, yra atskiras atvejis. Atstatymas su identiškais nustatymais gali atkurti paslaugą, bet tai priežastis laikyti konfigūraciją atkartojamą, o ne priežastis atstatyti kiekvieno incidento atveju.

Laikykite keturis dalykus versijų kontrolėje, kad kitas atstatymas būtų diff, o ne improvizacija: galinio taško parametrus, sertifikato ir grandinės ARN, autorizavimo taisykles ir kliento CIDR. Client VPN autentifikavimo dokumentacija išvardija, kuris sertifikatas atlieka kokį vaidmenį, ir tai verta patikrinti prieš darant prielaidą, kad sertifikatas apskritai yra problema. Jei pakartotinis importas nieko nekeičia ir galinis taškas vis tiek atsistato, įtariamasis yra siejimas, o atsakymas yra naujas galinis taškas, pastatytas iš užfiksuotų parametrų. Jei galinis taškas vis dėlto paima naują objektą, siejimas jau buvo teisingas, o gedimas yra kliento grandinėje arba autorizavimo sluoksnyje.