Miks Client VPN-i sertifikaadi uuesti importimine nõuab uut lõpp-punkti

Client VPN-i ühendus katkeb, ACM-is olev sertifikaat asendatakse ja miski ei muutu. Sertifikaadi objekt ei olnud kunagi see, mida lõpp-punkt kasutas. Lõpp-punkt salvestab loomise hetkel seose sertifikaadiga koos kliendi CA-ga, mille vastu see valideerib, autentimise tüübi, alamvõrkude ja autoriseerimisreeglitega, ja ühelgi neist seostest pole muutmiskutset, mis võtaks vastu asendussertifikaadi. ARN-i taga olevate baitide asendamine on muudatus sertifikaadis, mitte lõpp-punktis, mis selle talletas.

Lõpp-punkt hoiab viiteid, mitte sertifikaate

Mehhanismi tasub täpselt sõnastada, sest see seletab kogu rikke. create-client-vpn-endpoint võtab serveri sertifikaadi ARN-i ja kliendi juursertifikaatide ahela ARN-i, ja sellest tekkiv lõpp-punkt hoiab neid viiteid koos autentimisvalikutega fikseeritud omadustena. API ei paku toimingut, mis vahetaks olemasolevas lõpp-punktis serveri sertifikaati.

Saate seost kinnitada ilma oletamata. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 prindib sertifikaadi ARN-i, kliendi juurahela ARN-i, autentimise tüübi, kliendi CIDR-i ja seotud alamvõrgud, mis on kogu omaduste kogum, mida peaksite taastama. Käivitage see enne ja pärast uuesti importimist ning väljund ei liigu. See on tõestus, et uuesti importimine ei saanud kunagi aidata.

Miks uuesti importimine ei jõua lõpp-punktini

Uuesti importimine kirjutab olemasoleva ARN-i alla uue sertifikaadi keha. See on seaduslik toiming, kui sertifikaat on aegumisele lähedal, ja ACM võtab selle vastu seni, kui privaatvõti sobib ja ahel valideerub. Mida see ei tee, on lõpp-punkti loomisaegse valideerimise uuesti käivitamine, seega seos ja selle taga olev materjal jäävad selliseks, nagu need lõpp-punkti ehitamise ajal olid.

Seetõttu kõlab sümptom nagu võrgu rike. TLS-i käepigistus ebaõnnestub või lähtestatakse enne, kui autoriseerimist üldse hinnatakse, seega turbegrupid, marsruudid ja autoriseerimisreeglid näivad kõik süütud, ja seda nad ongi.

Ahel on kliendi sertifikaadi osa

Rikke teine pool on kliendi sertifikaadis ja seda on lihtsam kõrvale jätta. Kliendi sertifikaat tuleb importida koos ahelaga, mis selle väljastas, kuigi impordivorm näitab seda välja valikulisena. Ilma ahelata ei saa lõpp-punkt ehitada teed kliendi sertifikaadist kliendi juur-CA-ni, millega see konfigureeriti, ja ühendus lõpeb pehme lähtestamisega, mis kõlab nagu pakette pillav tulemüür. openssl verify -CAfile root-ca.pem client.crt vastab sellele küsimusele kohapeal sekundiga ja see peaks olema esimene käsk, mille käivitate.

Ahelaga uuesti importimine on selle poole jaoks tõeline parandus ja jääb siiski üksi ebapiisavaks. Kui ACM-i objekt on muutunud, on vana seost hoidvast lõpp-punktist edasi testimine vale. Mõlemad sammud kuuluvad sama remondi juurde, mistõttu kaheosaline parandus ei ole vastuolu.

Lõpp-punkti uuesti loomine on migratsioon

Asenduslõpp-punkti loomine on migratsioon, mitte korduskatse, ja selle korduskattena käsitlemine on viis, kuidas meeskonnad jõuavad kahe pooleldi konfigureeritud lõpp-punktini. Uus lõpp-punkt saab uue ID ja, kui te seda ei planeerinud, uue DNS-nime igale kasutajale. Hoidke kliendiprofiil osutamas nimele, mitte aadressile, et vahetusest saaks kirje muudatus, mitte ümberjagamine.

Järjekord, mis hoiab selle turvalisena, on lühike: looge uus lõpp-punkt sama CIDR-i, alamvõrkude ja autoriseerimisreeglitega, eksportige värske profiil käsuga aws ec2 export-client-vpn-client-configuration ja kontrollige ühe kasutajaga. Alles pärast seda võetakse vana lõpp-punkt maha.

Vana lõpp-punkti kasutusest kõrvaldamisel on oma järjekord. Tühistage kliendi sertifikaadid, mille kavatsesite kasutusest kõrvaldada, enne selle kustutamist, sest uus lõpp-punkt, mis usaldab endiselt vana CA-d, võtab jätkuvalt vastu sertifikaate, mille arvasite kadunud olevat. Seejärel kustutage vana lõpp-punkt ja eemaldage selle autoriseerimisreeglid, et aegunud profiil ei saaks uuesti ühenduda sihtvõrguga, mille arvasite suletud olevat. Kirjutage vana lõpp-punkti ID ja seoste identifikaatorid muudatuste kirjesse, sest mäluga võrreldav migratsioon on viis, kuidas töötav lõpp-punkt kaks korda üles ehitatakse.

Järjestage diagnoos

Eraldage kolm riket enne mis tahes konfiguratsiooni muutmist. Klient ei saa TLS-i lõpule viia, klient viib TLS-i lõpule ja pole autoriseeritud, või klient ühendub ja ei jõua sihtkohta. Sertifikaadi seos kuulub esimese juurde, autoriseerimisreegel, mis ei kata kliendi aadressi, teise juurde, ning marsruut või turbegrupp kolmanda juurde, kus lõpp-punkti uuesti loomine on peaaegu alati vale käik.

Lõpp-punkt, mis töötas kuid ja siis seiskus ilma sertifikaadi või poliitika muutuseta, on omaette juhtum. Selle uuesti ülesehitamine samade seadetega võib teenuse taastada, kuid see on põhjus hoida konfiguratsioon reprodutseeritavana, mitte põhjus iga juhtumi korral uuesti ehitada.

Hoidke nelja asja versioonihalduses, et järgmine ülesehitus oleks diff, mitte improvisatsioon: lõpp-punkti parameetrid, sertifikaadi ja ahela ARN-id, autoriseerimisreeglid ja kliendi CIDR. Client VPN-i autentimise dokumentatsioon loetleb, milline sertifikaat millist rolli mängib, mida tasub kontrollida enne, kui üldse eeldate, et probleem on sertifikaadis. Kui uuesti importimine ei muuda midagi ja lõpp-punkt lähtestub endiselt, on kahtlane seos ja vastus on salvestatud parameetritest ehitatud uus lõpp-punkt. Kui lõpp-punkt siiski uue objekti üles võtab, oli seos juba korras ja viga on kliendi ahelas või autoriseerimiskihis.