Miksi Client VPN -varmenteen uudelleentuonti vaatii uuden päätepisteen

Client VPN -yhteys katkeaa, ACM:n varmenne vaihdetaan, eikä mikään muutu. Varmenneobjekti ei ollut koskaan se, mitä päätepiste käytti. Päätepiste tallentaa luontihetkellä liitoksen varmenteeseen sekä asiakas-CA:n, jota vasten se validoi, todennuksen tyypin, aliverkot ja valtuutussäännöt, eikä yhdelläkään näistä liitoksista ole muutospyyntöä, joka hyväksyisi korvaavan varmenteen. ARN:n takana olevien tavujen korvaaminen on muutos varmenteessa, ei päätepisteessä, joka sen tallensi.

Päätepiste tallentaa viittauksia, ei varmenteita

Mekanismi kannattaa muotoilla täsmällisesti, koska se selittää koko vian. create-client-vpn-endpoint ottaa palvelinvarmenteen ARN:n ja asiakkaan juurivarmenneketjun ARN:n, ja syntyvä päätepiste pitää nämä viittaukset sekä todennusvaihtoehdot kiinteinä ominaisuuksina. API ei tarjoa operaatiota, joka vaihtaisi palvelinvarmenteen olemassa olevassa päätepisteessä.

Voit vahvistaa liitoksen arvaamatta. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 tulostaa varmenteen ARN:n, asiakkaan juuriketjun ARN:n, todennuksen tyypin, asiakkaan CIDR:n ja liittyvät aliverkot, eli täyden joukon ominaisuuksia, jotka sinun pitäisi toistaa. Aja se ennen uudelleentuontia ja sen jälkeen, eikä tuloste liiku. Se on todiste siitä, ettei uudelleentuonnista ollut koskaan apua.

Miksi uudelleentuonti ei voi tavoittaa päätepistettä

Uudelleentuonti kirjoittaa uuden varmenneosan olemassa olevan ARN:n alle. Se on laillinen toimenpide, kun varmenne on lähellä vanhenemista, ja ACM hyväksyy sen, kunhan yksityinen avain täsmää ja ketju validoituu. Mitä se ei tee, on päätepisteen luontihetken validoinnin ajamien uudelleen, joten liitos ja sen takana oleva materiaali pysyvät sellaisina kuin ne olivat päätepistettä rakennettaessa.

Siksi oirekin näyttää verkkohäiriöltä. TLS-kättely epäonnistuu tai nollautuu ennen kuin valtuutusta edes arvioidaan, joten suojausryhmät, reitit ja valtuutussäännöt näyttävät kaikki viattomilta, ja sitä ne ovat.

Ketju on osa asiakasvarmennetta

Vian toinen puoli on asiakasvarmenteessa, ja se on helpompi sivuuttaa. Asiakasvarmenne on tuotava sen myöntäneen ketjun kanssa, vaikka tuontilomake esittää kyseisen kentän valinnaisena. Ilman ketjua päätepiste ei voi rakentaa polkua asiakasvarmenteesta asiakasjuuri-CA:han, jonka kanssa se määritettiin, ja yhteys päättyy pehmeään nollaukseen, joka kuulostaa paketteja pudottavalta palomuurilta. openssl verify -CAfile root-ca.pem client.crt vastaa tähän kysymykseen paikallisesti sekunnissa, ja sen pitäisi olla ensimmäinen komento, jonka ajat.

Ketjun kanssa tehty uudelleentuonti on todellinen korjaus sille puolelle, eikä se silti yksin riitä. Kun ACM-objekti on muuttunut, vanhan liitoksen säilyttävä päätepiste on väärä asia, jota vasten testaamista jatkaa. Molemmat vaiheet kuuluvat samaan korjaukseen, minkä vuoksi kaksiosainen korjaus ei ole ristiriita.

Päätepisteen uudelleenluonti on migraatio

Korvaavan päätepisteen luominen on migraatio, ei uusintayritys, ja sen kohteleminen uusintayrityksenä on se tapa, jolla tiimit päätyvät kahteen puoliksi määritettyyn päätepisteeseen. Uusi päätepiste saa uuden ID:n ja, ellet suunnitellut sitä, uuden DNS-nimen jokaiselle käyttäjälle. Pidä asiakasprofiili osoittamassa nimeen eikä osoitteeseen, jotta vaihdosta tulee tietueen muutos eikä uudelleenjako.

Järjestys, joka pitää tämän turvassa, on lyhyt: luo uusi päätepiste samalla CIDR:llä, aliverkoilla ja valtuutussäännöillä, vie tuore profiili komennolla aws ec2 export-client-vpn-client-configuration ja varmista yhdellä käyttäjällä. Vasta sen jälkeen vanha päätepiste poistetaan käytöstä.

Vanhan päätepisteen käytöstä poistamisella on oma järjestyksensä. Peruuta asiakasvarmenteet, jotka aioit poistaa, ennen kuin poistat päätepisteen, koska uusi päätepiste, joka edelleen luottaa vanhaan CA:han, hyväksyy jatkossakin varmenteita, joiden luulit kadonneen. Poista sitten vanha päätepiste ja sen valtuutussäännöt, jotta vanhentunut profiili ei voi yhdistää uudelleen kohdeverkkoon, jonka luulit olevan kiinni. Kirjaa vanhan päätepisteen ID ja liitosten tunnisteet muutoskirjaukseen, koska muistiin verrattava migraatio on se tapa, jolla toimiva päätepiste rakennetaan uudelleen kahdesti.

Järjestä diagnoosi

Erottele kolme vikaa ennen kuin muutat mitään kokoonpanoa. Asiakas ei saa TLS:ää valmiiksi, asiakas saa TLS:ää valmiiksi eikä ole valtuutettu, tai asiakas yhdistää eikä tavoita kohdetta. Varmenteen liitos kuuluu ensimmäiseen, valtuutussääntö, joka ei kata asiakkaan osoitetta, toiseen, ja reitti tai suojausryhmä kolmanteen, jossa päätepisteen uudelleenluonti on lähes aina väärä siirto.

Päätepiste, joka toimi kuukausia ja pysähtyi sitten ilman varmenne- tai käytäntömuutosta, on oma tapauksensa. Sen uudelleenrakentaminen samoilla asetuksilla voi palauttaa palvelun, mutta se on syy pitää kokoonpano toistettavana, ei syy rakentaa uudelleen joka tapauksessa.

Pidä neljä asiaa versionhallinnassa, jotta seuraava uudelleenrakennus on diff eikä improvisaatio: päätepisteen parametrit, varmenteen ja ketjun ARN:t, valtuutussäännöt ja asiakkaan CIDR. Client VPN -todennuksen dokumentaatio luettelee, mikä varmenne pelaa mitä roolia, ja se kannattaa tarkistaa ennen kuin olettaa varmenteen olevan ongelma. Jos uudelleentuonti ei muuta mitään ja päätepiste nollautuu edelleen, epäilty on liitos ja vastaus on tallennetuista parametreista rakennettu uusi päätepiste. Jos päätepiste kuitenkin ottaa uuden objektin, liitos oli jo oikein ja vika on asiakasketjussa tai valtuutuskerroksessa.