AWS 공식 문서가 아닙니다. 개인 실습 기록이며 AWS의 입장을 대변하지 않습니다(기준일 2026-10-25). 정확한 정보는 AWS 공식 문서를 확인하세요. 테스트 계획: 테스트 계획. 실행일 2026-10-25(UTC 2026-10-24 23:40~2026-10-25 01:27), 실습 전용 단일 계정, 서울 리전. 시각은 UTC입니다. 증거로 든 원본 출력은 비공개 실습 저장소에 보관하고 있습니다.
10.100.0.34)를 소스로 보여 줬고, 소스 포트도 보존됐습니다(T03, T05, T10).10.40.1.235, 10.40.1.129)로 바뀝니다(T04).--transit-gateway-id, --availability-zone-list)가 실제 CLI에 없습니다(T02).InternalError가 반환됩니다(T06).| ID | 테스트 | 실행 시각 | 결과 | 핵심 증거 | 문서와의 차이·관찰 |
|---|---|---|---|---|---|
| T01 | 엔드포인트 생성과 client-vpn 연결 | 23:40~00:24 | 통과(주의) | ResourceType=client-vpn 연결 자동 생성(23:42, 약 1.5분 만에 available). VpcId·SecurityGroupIds 비어 있음. 고객 VPC에 엔드포인트 ENI 없음. 기본 연결을 끈 TGW에서 연결의 Association은 null. rt-spoke·rt-egress에 10.100.0.0/22와 /25 5개가 propagated |
엔드포인트 상태는 문서의 pending-associate가 아니라 pending. TransitGatewayConfiguration에 문서에 없는 TransitGatewayAttachmentId 필드. 엔드포인트 available까지 22분(CloudFormation 기준 23:42~00:04). CloudFormation이 00:04:28에 동시에 요청한 라우트 2개 중 10.10.0.0/16이 API 성공(CloudTrail) 뒤 라우팅 테이블에 나타나지 않음. 00:20:31에 수동으로 다시 만든 뒤 스택 완료(전체 44분). 원인은 동시 생성으로 추정(1회 관찰) |
| T02 | CLI 매개변수와 AZ 기본값 | 00:28~00:29 | 통과 | --transit-gateway-id는 Unknown options. --transit-gateway-configuration TransitGatewayId=...(AZ 미지정)로 만들자 apne2-az3·apne2-az2 2개 자동 선택 |
문서 CLI 예시의 --transit-gateway-id, --availability-zone-list가 실제 CLI(2.36.47)에 없음. 자동 선택 시 AZ 이름 대신 AvailabilityZoneIds로 표시 |
| T03 | 소스 IP 보존 | 00:25~00:26 | 통과 | client1 tun 10.100.0.34 → app-a 응답 seen_src=10.100.0.34:47050, nginx 로그 동일, tcpdump IP 10.100.0.34.52790 > 10.10.1.10.80 |
없음 |
| T04 | VPC 연결 방식 비교(SNAT) | 23:59 | 통과 | client2 tun 10.104.0.2 → seen_src=10.40.1.235(cvpn-legacy ENI) |
없음 |
| T05 | 동시 접속과 소스 포트 | 00:00, 00:27 | 통과 | TGW: 10.100.0.34:40000, 10.100.1.2:40000 모두 보존. legacy: 10.40.1.235:40000, 10.40.1.129:40000 |
legacy에서 두 클라이언트가 서로 다른 ENI로 SNAT되어 포트 변환이 관찰되지 않음. 문서는 “동시 사용자가 같은 대상에 접속할 때 PAT”라고 함 [D2]. 같은 ENI를 공유하는 경우는 시험하지 않음 |
| T06 | 보안 그룹 | 00:28 | 통과 | sg-app-a를 10.100.0.34/32로 좁히자 client1만 성공, client2 시간 초과. 원복 후 정상 |
문서대로 TGW 설정과 --vpc-id/--security-group-ids를 함께 지정할 수 없음. 다만 검증 오류가 아니라 InternalError로 거부(조합 3가지 모두, CloudTrail Server.InternalError) |
| T07 | 분할·전체 터널 라우트 | 00:29~00:54 | 통과(블로그와 다름) | 라우트 10.20.0.0/16 삭제 후 재접속하면 클라이언트 라우트에서 빠짐(삭제 반영 105초, 재생성 90초). 0.0.0.0/0 권한 부여 규칙만 둔 전체 터널에서는 client1의 인터넷(SSM)이 끊김. 0.0.0.0/0 라우트 추가 후 새로 접속한 client2의 출구 IP = NAT 게이트웨이의 EIP | 블로그의 “전체 터널은 권한 부여 규칙만 필요”와 달리 0.0.0.0/0 라우트도 필요. 라우트가 활성화된 뒤(00:40:40) 약 10분 동안 client1의 SSM이 복구되지 않아 00:51:23에 재부팅함. 기존 세션이 라우트 추가를 반영하는지는 미확인. 전체 터널에서는 redirect-gateway def1과 block-outside-dns가 푸시됨 |
| T08 | 권한 부여 규칙과 다중 VPC | 00:54~00:58 | 통과(주의) | 라우트가 있어도 미승인 VPC-B는 시간 초과. 승인 후 app-a·app-b 모두 seen_src=10.100.2.2 |
규칙 상태가 authorizing인 동안(00:58:12, 00:58:26) 모든 클라이언트에 server-pushed-connection-reset이 발생했고, 규칙은 00:58:39에 active. 재접속 뒤 client1 IP가 10.100.2.34에서 10.100.2.2로 바뀜. 연결 로그에도 connection-reset(종료 00:58:17)이 남음. 시험 뒤 VPC-B 규칙은 회수해 템플릿 상태로 되돌림 |
| T09 | TGW 복귀 경로·분할 | 00:59~01:01 | 통과 | rt-spoke에서 client-vpn 전파를 끊자 시간 초과, 다시 켜자 즉시 복구. rt-cvpn에서 VPC-B 전파를 끊자 app-b 차단, 다시 켜자 복구. TGW 흐름 로그: app-a 응답 10.10.1.10:80 → 10.100.2.2가 VPC-A 연결에서 packets-lost-blackhole 8+2, 분할 시 10.100.2.2 → 10.20.1.10:80이 client-vpn 연결에서 5 |
없음. 패킷 캡처는 SSM 명령이 끝날 때 tcpdump도 함께 끝나 실패했고, 흐름 로그로 대신 확인 |
| T10 | 흐름 로그·연결 로그 상관 | 00:25~01:24 | 통과(주의) | TGW 흐름 로그: tgw-attachment-id=client-vpn 연결, srcaddr=10.100.0.34. app-a ENI의 VPC 흐름 로그: srcaddr=pkt-srcaddr=10.100.0.34. TGW 연결 ENI의 VPC 흐름 로그는 srcaddr가 TGW ENI IP, pkt-srcaddr가 client IP. 연결 로그의 client1.cvpn-lab.internal/10.100.0.34/00:25:25로 사용자 특정. legacy는 흐름 로그에 ENI IP만 남음 |
연결 로그는 약 17~23분 늦게 들어옴(00:25:25 기록이 00:42:58에, 00:36:47 기록이 01:00:13에, 00:54:14 기록이 01:13:23에 들어옴). 01:24 확인 시점에 client1 00:31 재접속, client2 00:51 접속, 00:58 재접속, client2 리셋 기록은 아직 없음. 끊긴 세션(client1 00:36:47, 10.100.1.130)이 describe-client-vpn-connections에 active로 남아 있음 |
| T11 | DNS | 00:51, 00:54 | 블로그와 다름 | 전체 터널에서 dig @10.10.0.2 amazon.com → NOERROR. 분할 터널에서 NOERROR, 사설 DNS 이름 ip-10-10-1-10.ap-northeast-2.compute.internal → 10.10.1.10 |
블로그는 “VPC 리졸버(+2)는 TGW 연결로 닿지 않음”이라고 하지만 응답함. 첫 시도의 시간 초과는 세션이 끊겨 있었기 때문 |
| T12 | 제약 사항 음성 테스트 | 00:36~00:57 | 통과(관찰 2건) | a: SubnetId cannot be provided when Client VPN endpoint is associated with Transit Gateway. d: There is no IPv4 or IPv6 CIDR block associated with the Transit Gateway. e: Client cidr block must be at least a /22 range. f: 다른 리전은 InvalidTransitGatewayID.NotFound |
b(VPC-A와 겹침 10.10.0.0/22), c(TGW CIDR과 겹침 10.255.0.0/22)는 거부되지 않고 약 20분 뒤 available(00:57 삭제). 이 두 엔드포인트는 TGW 라우팅 테이블에 연결하지 않았는데도 available이 됨 |
| T13 | TGW IP 예약 관찰 | 00:38 | 관찰 불가 | 10.255.0.0/24 주소를 쓰는 ENI나 흐름 로그 기록 없음 | 직접 확인할 수단 없음 |
| T14 | 비용 확인 | - | 미확인 | 공개 시점까지 Cost Explorer 결과를 확인하지 않음 | client-vpn 연결의 TGW 연결 시간 요금 여부는 미확정 |
scripts/eice.sh). client1은 재부팅으로 복구했습니다. T07의 측정(00:51)은 EICE 추가 전에 SSM으로 했습니다.inactive로 보였지만 저널에는 정상 시작 기록만 있었습니다. 다시 시작한 뒤로는 정상이며 원인은 모릅니다.infra/endpoint-tgw.yaml에서 RouteVpcB가 RouteVpcA에 DependsOn하도록 고쳤습니다. 배포한 스택에는 아직 반영하지 않았고 효과도 검증하지 않았습니다.describe-client-vpn-connections를 시각과 함께 맞춥니다. 보안 그룹에 사용자별 /32 규칙을 두는 방식은 피합니다.