EC2가 AWS Client VPN 노트북에 도달하지 못하는 이유
Client VPN은 IPv4 클라이언트 소스를 엔드포인트 인터페이스로 변환합니다. 그래서 응답은 동작하지만 EC2에서 시작한 새 연결은 동작하지 않습니다.
AWS Client VPN으로 연결된 노트북은 EC2 애플리케이션에 문제없이 도달합니다. 그다음 반대 방향, 즉 EC2에서 클라이언트에 할당된 주소로 시도하면 연결이 멈추거나 거부됩니다. 이 비대칭은 보안 그룹 규칙이 빠져서 생기는 경우가 드뭅니다. VPC 서브넷에 연결된 Client VPN 엔드포인트에서는 AWS가 IPv4 클라이언트 소스를 엔드포인트의 네트워크 인터페이스로 변환하므로, 노트북을 나타내는 인바운드 VPC 주소는 존재하지 않습니다.
캡처가 보여주는 것부터 시작하기
클라이언트가 연결되는 동안 EC2 호스트에서 캡처를 뜨고 애플리케이션이 실제로 보는 소스 주소를 읽습니다. 그것이 클라이언트 풀의 주소가 아니라 VPC 쪽 엔드포인트 인터페이스라면 규칙을 하나도 바꾸기 전에 변환이 확인된 것입니다.
클라이언트 풀은 할당 범위이며, 반환 경로가 있는 서브넷이 아닙니다. 바로 이 구분에서 이런 조사의 대부분이 잘못됩니다.
비대칭을 설명하는 변환
세 가지 흐름이 서로 혼동되며, 그중 하나만 사람들이 실제로 시험하는 흐름입니다.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Client VPN 구성 요소 설명은 IPv4 클라이언트 소스가 엔드포인트 인터페이스로 변환된다고 명시하며, 가운데 행에 일치할 것이 없는 이유를 보기에 충분합니다.
새 연결에는 경로, 주소 확인 단계, 인가 결정이 필요합니다. 다른 사람의 세션에 있는 변환 상태는 이 세 가지 중 어느 것도 제공하지 않습니다.
응답이 새 연결이 아닌 이유
TCP 응답은 기존 항목과 대조되므로 인바운드 규칙이 전혀 없어도 반환 경로가 동작합니다. EC2 호스트에서 나온 새 SYN은 대조할 항목이 없으므로 VPC가 도달 방법을 모르는 목적지로 향하는 평범한 아웃바운드 시도가 됩니다.
그래서 이것을 한 방향으로만 흐르는 트래픽이라고 설명하는 것은 오해를 낳습니다. 이 세션에서는 반환 트래픽이 계속 흐릅니다. 경로가 없는 쪽은 시작입니다.
동작해야 할 세션을 여전히 깨뜨리는 것
보안 그룹, 네트워크 ACL, 노트북 자체의 방화벽은 성공해야 하는 연결 모두에 중요합니다. 실패한 ping이 가장 적은 정보를 주는 이유는 ICMP 정책이 관심 있는 TCP 정책과 분리된 경우가 많기 때문입니다.
이 규칙들은 변환된 소스를 기준으로 작성하고, 클라이언트 주소를 기준으로 작성하지 마십시오. 네트워크에 절대 나타나지 않는 주소에 묶인 규칙이 이 설계에서 가장 흔한 자초한 실패입니다.
VPC가 정말로 대화를 시작해야 할 때
서비스가 워크스테이션에 알려야 한다면 방향을 뒤집고 클라이언트가 서비스가 응답하는 지속적인 아웃바운드 채널을 유지하게 하십시오. 전체 원격 네트워크를 VPC에서 접근할 수 있어야 한다면 Client VPN이 이미 그렇게 한다고 가정하지 말고 해당 프리픽스와 접근 정책을 게시하는 아키텍처를 선택하십시오. 클라이언트 간 접근은 자체 경로와 인가 객체를 가진 세 번째의 더 좁은 사례입니다. 이 중 어느 것도 기존 엔드포인트의 체크박스가 아닙니다.
IPv4 설명의 범위도 정직하게 유지하십시오. 현재 AWS 문서는 그 변환이 적용되지 않는 IPv6와 다르게 라우팅하는 다른 연결 모델을 구분합니다.
세 가지로 표시된 단계에서 시험하십시오. 클라이언트가 허용된 세션을 열고, VPC 서비스가 그 세션에 응답하며, VPC 호스트가 클라이언트를 향해 새 세션을 엽니다. 처음 두 단계가 성공하고 세 번째가 실패하는 것이 이 설계의 예상된 형태이며, 방화벽 규칙으로 쫓아가야 할 결함이 아닙니다.