AWS Client VPN: servila atestilo kontraŭ la rolo de klienta atestilo

Client VPN-finpunkto ĉiam bezonas TLS-servilan atestilon. Tio estas la identeco, kiun la administrata finpunkto prezentas, kiam kliento konektiĝas. Ĝ i estas alia objekto ol la atestiloj, kiujn unuopaj klientoj prezentas, kiam uziĝas reciproka aŭtentigo. Konfuzi tiujn du estas la plej ofta kialo, ke alie ĝusta ACM-agordo tamen malsukcesas ĉe la unua konekto.

Jen trairo de la konzolo eksteren, laŭ la ordo, kiun konekto efektive trapasas.

Du roloj, unu finpunkto

La finpunkto posedas servilan identecon kaj, laŭvole, manieron kontroli klientajn identecojn. Tiuj estas agordataj aparte. Unu decidas ĉu la kliento povas fidi la servon; la alia decidas, ĉu la servo akceptas la klienton.

Legu la tabelon kiel tri sendependajn postulojn anstataŭ kiel unu atestilon. La servila atestilo kaj ĝia privata ŝlosilo restas ĉe la servo. Klienta atestilo kaj la kongrua privata ŝlosilo vivas sur la aparato. La CA-materialo estas tio, kion kontrolanto uzas por kontroli la ĉenon. Nur la meza vico iam apartenas al tekkomputilo.

Kion faras la ACM-servila atestilo

Kiam vi kreas la finpunkton, la servila atestilo devas esti havebla en ACM en la sama regiono kiel la finpunkto. La konzolo petas ARN, kaj tiu ARN devas solviĝi tie. ACM povas teni atestilon, kiun vi provizis kun domajna validigo, aŭ unu, kiun vi importis kune kun ĝia ŝlosilo kaj ĉeno. Ambaŭ funkcias en ĉi tiu rolo; ili diferencas pri renovigo kaj pri tio, kiu tenas la privatan ŝlosilon.

Elektu la provizan vojon, kiu kongruas kun tiu, kiu povas renovigi la atestilon, ne tiun, kiu hazarde produktis ŝajne validan dosieron.

Kion aldonas reciproka aŭtentigo

Elekti atestilbazan klientan aŭtentigon aldonas duan demandon: kiuj klientoj rajtas konektiĝi. Ĉiu kliento prezentas sian propran atestilon kaj pruvas posedon de la kongrua privata ŝlosilo. Apartaj identecoj estas tio, kio ebligas poste selekteman revokon. Kopii unu klientan ŝlosilon al ĉiu aparato kviete forĵetas tiun econ, eĉ kiam la servila atestilo estis akirita perfekte.

La aŭtentiga metodo de la finpunkto estas elekto, ne universala postulo.

Active Directory kaj federita aŭtentigo respondas la saman demandon per aliaj rimedoj. Recepto kun reciproka atestilo ne estas aŭtomate la ensaluta dezajno por tiuj deplojoj, kaj la TLS-kontrolo de la servilo restas sendepende de tio, kiel la uzanto estas enlasita.

Kial la sama CA-ARN ne estas ŝlosildivido

AWS dokumentas, ke kiam la servila kaj klienta atestiloj estas eldonitaj de la sama CA, la ARN de la servila atestilo ankaŭ povas esti uzata por la elekto de la klienta atestilo. Tiu frazo temas pri tio, kiun ĉenon la finpunkto fidas ĉe kontrolo. Ĝ i ne diras al klientoj uzi la privatan ŝlosilon de la servilo. Tekkomputilo ankoraŭ bezonas sian propran klientan atestilon kaj sian propran kongruan ŝlosilon.

Kiam la CA de la kliento estas alia eldonanto, la dokumentita vojo estas importi tiun CA en ACM kaj elekti ĝin por la klienta rolo.

Retroiru la fiaskon al stadio

Antaŭ ol anstataŭigi ion ajn, determinu, kiu stadio fiaskas. Se la kliento rifuzas la finpunkton, la ARN de la servilo aŭ ĝia ĉeno estas la suspektato. Se la finpunkto rifuzas la klienton, rigardu la klientan atestilon, ĝian eldonanton kaj la elektitan aŭtentigan metodon. Se la tunelo leviĝas kaj trafiko ankoraŭ fiaskas, vi jam preteris la atestilojn.

Anstataŭigu unu objekton samtempe, ĉar interŝanĝi ambaŭ finojn samtempe reproduktas la ambiguecon, kun kiu vi komencis.

Kontrolu ankaŭ la subtenatajn ŝlosilalgoritmojn kaj postulatajn etendojn de la servo por la koncerna rolo. Atestilo, kiu kontentigas publikan retejon, ne estas pruvo, ke ĉiuj identecpostuloj de Client VPN estas plenumitaj.

Notu, kiun ARN tenas ĉiu kampo, kiu CA eldonis la klientan atestilon kaj kiun aŭtentigan metodon la finpunkto efektive uzas. Tri linioj da registro transformas la sekvan renovigon en taskon anstataŭ enketon.