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를 완료했지만 권한이 없거나, 연결은 되지만 목적지에 도달하지 못합니다. 인증서 연결은 첫 번째, 클라이언트 주소를 포함하지 않는 권한 부여 규칙은 두 번째, 경로나 보안 그룹은 세 번째에 속하며, 세 번째에서는 엔드포인트 재생성이 거의 항상 잘못된 선택입니다.

몇 달 동안 작동하다가 인증서나 정책 변경 없이 멈춘 엔드포인트는 별개의 사례입니다. 같은 설정으로 다시 만들면 서비스가 복구될 수 있지만, 그것은 구성을 재현 가능하게 유지할 이유이지 사고마다 다시 만들 이유가 아닙니다.

다음 재구성이 즉흥이 아니라 diff가 되도록 엔드포인트 매개변수, 인증서와 체인의 ARN, 권한 부여 규칙, 클라이언트 CIDR의 네 가지를 버전 관리하십시오. Client VPN 인증 문서는 어떤 인증서가 어떤 역할을 하는지 나열하며, 인증서가 문제라고 단정하기 전에 확인할 가치가 있습니다. 다시 가져와도 아무것도 바뀌지 않고 엔드포인트가 계속 재설정되면 의심 대상은 연결이며, 답은 기록된 매개변수로 만든 새 엔드포인트입니다. 엔드포인트가 새 객체를 실제로 받아들이면 연결은 이미 올바랐고 장애는 클라이언트 체인이나 권한 부여 계층에 있습니다.