Чаму паўторны імпарт сертыфіката Client VPN патрабуе новага канчатковага пункта

Злучэнне Client VPN абрываецца, сертыфікат у ACM замяняецца, і нічога не змяняецца. Аб’ект сертыфіката ніколі не быў тым, што выкарыстоўваў канчатковы пункт. Канчатковы пункт пры стварэнні захоўвае сувязь з сертыфікатам, а таксама кліенцкі CA, супраць якога ён будзе правяраць, тып аўтэнтыфікацыі, падсеткі і правілы аўтарызацыі, і ні ў адной з гэтых сувязяў няма выкліку змянення, які прымае заменны сертыфікат. Замена байтаў за ARN — гэта змяненне сертыфіката, а не канчатковага пункта, які яго захаваў.

Канчатковы пункт захоўвае спасылкі, а не сертыфікаты

Механізм варта сфармуляваць дакладна, бо ён тлумачыць усю паломку. create-client-vpn-endpoint прымае ARN сертыфіката сервера і ARN ланцужка каранёвага сертыфіката кліента, і атрыманы канчатковы пункт трымае гэтыя спасылкі разам з параметрамі аўтэнтыфікацыі як фіксаваныя ўласцівасці. API не прапануе аперацыі, якая замяняе сертыфікат сервера ў існуючым канчатковым пункце.

Можна пацвердзіць сувязь без здагадак. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 выводзіць ARN сертыфіката, ARN каранёвага ланцужка кліента, тып аўтэнтыфікацыі, CIDR кліента і звязаныя падсеткі — поўны набор уласцівасцей, якія вам давядзецца ўзнавіць. Запусціце яго да і пасля паўторнага імпарту, і вывад не зрушыцца. Гэта і ёсць доказ таго, што паўторны імпарт не мог дапамагчы.

Чаму паўторны імпарт не можа дасягнуць канчатковага пункта

Паўторны імпарт запісвае новае цела сертыфіката пад існуючым ARN. Гэта законная аперацыя, калі сертыфікат блізкі да заканчэння тэрміну, і ACM яе прыме, калі прыватны ключ супадае і ланцужок праходзіць праверку. Чаго ён не робіць — не перазапускае праверку, выкананую пры стварэнні канчатковага пункта, таму сувязь і матэрыял за ёй застаюцца такімі, якімі былі пры стварэнні.

Менавіта таму сімптом выглядае як збой сеткі. Рукапоціск TLS не ўдаецца або скідваецца яшчэ да таго, як аўтарызацыя будзе ацэнена, таму групы бяспекі, маршруты і правілы аўтарызацыі выглядаюць невінаватымі — і яны такія і ёсць.

Ланцужок — частка кліенцкага сертыфіката

Другая палова паломкі ў кліенцкім сертыфікаце, і яе лягчэй праігнараваць. Кліенцкі сертыфікат трэба імпартаваць разам з ланцужком, які яго выдаў, хоць форма імпарту паказвае гэтае поле як неабавязковае. Без ланцужка канчатковы пункт не можа пабудаваць шлях ад кліенцкага сертыфіката да каранёвага CA кліента, з якім ён быў наладжаны, і злучэнне сканчаецца мяккім скідам, які выглядае як міжсеткавы экран, што скідвае пакеты. openssl verify -CAfile root-ca.pem client.crt адказвае на гэтае пытанне лакальна за секунду, і гэта павінна быць першая каманда, якую вы запусціце.

Паўторны імпарт з ланцужком — сапраўднае выпраўленне для гэтай паловы, і ўсё ж яго недастаткова самога па сабе. Пасля змянення аб’екта ACM канчатковы пункт са старой сувяззю — гэта няправільнае, супраць чаго працягваць тэставаць. Абодва крокі належаць аднаму рамонту, таму двухчастковае выпраўленне не супярэчнасць.

Перастварэнне канчатковага пункта — гэта міграцыя

Стварэнне заменнага канчатковага пункта — гэта міграцыя, а не паўтор, і стаўленне да яе як да паўтору — гэта шлях, якім каманды прыходзяць да двух напалову наладжаных канчатковых пунктаў. Новы канчатковы пункт атрымлівае новы ID і, калі вы гэтага не планавалі, новае імя DNS для кожнага карыстальніка. Трымайце кліенцкі профіль накіраваным на імя, а не на адрас, каб замена стала змяненнем запісу, а не пераразмеркаваннем.

Парадак, які робіць гэта бяспечным, кароткі: стварыце новы канчатковы пункт з тымі ж CIDR, падсеткамі і правіламі аўтарызацыі, экспартуйце свежы профіль праз aws ec2 export-client-vpn-client-configuration і праверце на адным карыстальніку. Толькі пасля гэтага стары канчатковы пункт здымаецца.

Вывад са службы старога канчатковага пункта мае свой парадак. Адклічце кліенцкія сертыфікаты, якія вы збіраліся вывесці, перш чым выдаляць яго, бо новы канчатковы пункт, які ўсё яшчэ давярае старому CA, працягвае прымаць сертыфікаты, якія вы лічылі зніклымі. Затым выдаліце стары канчатковы пункт і яго правілы аўтарызацыі, каб састарэлы профіль не мог паўторна падключыцца да мэтавай сеткі, якую вы лічылі зачыненай. Запішыце ID старога канчатковага пункта і ідэнтыфікатары сувязяў у запіс змяненняў, бо міграцыя, звераная з памяццю, — гэта шлях, якім працоўны канчатковы пункт перабудоўваюць двойчы.

Упарадкуйце дыягностыку

Раздзяліце тры збоі, перш чым змяняць любую канфігурацыю. Кліент не можа завяршыць TLS, кліент завяршае TLS і не аўтарызаваны, або кліент падключаецца і не можа дасягнуць пункта прызначэння. Сувязь з сертыфікатам належыць першаму, правіла аўтарызацыі, якое не пакрывае адрас кліента, — другому, а маршрут або група бяспекі — трэцяму, дзе перастварэнне канчатковага пункта амаль заўсёды няправільны крок.

Канчатковы пункт, які працаваў месяцы, а потым спыніўся без змяненняў сертыфіката або палітыкі, — асобны выпадак. Перабудова з тымі ж наладамі можа аднавіць працу, але гэта прычына трымаць канфігурацыю ўзнаўляльнай, а не прычына перабудоўваць пры кожным інцыдэнце.

Трымайце чатыры рэчы пад кантролем версій, каб наступная перабудова была дыфам, а не імправізацыяй: параметры канчатковага пункта, ARN сертыфіката і ланцужка, правілы аўтарызацыі і CIDR кліента. Дакументацыя аўтэнтыфікацыі Client VPN пералічвае, які сертыфікат якую ролю выконвае, і гэта варта праверыць, перш чым меркаваць, што праблема ўвогуле ў сертыфікаце. Калі паўторны імпарт нічога не змяняе і канчатковы пункт па-ранейшаму скідваецца, падазроная сувязь, і адказ — новы канчатковы пункт, пабудаваны з запісаных параметраў. Калі ж канчатковы пункт сапраўды падхоплівае новы аб’ект, сувязь ужо была правільнай, і няспраўнасць у кліенцкім ланцужку або ўзроўні аўтарызацыі.