AWS Client VPN 분할 터널: 어떤 경로를 게시해야 하는가

콘솔이 분할 터널 토글을 제공하므로 결정이 체크박스처럼 느껴진다. 그렇지 않다. 실제로 클라이언트에 도달하는 것은 엔드포인트가 게시한 경로 집합이며, 그 목록이 어떤 사설 프리픽스가 터널을 쓰는지, 일반 인터넷 트래픽이 로컬에 머무는지 AWS를 통해 나가는지, 클라이언트가 여전히 어떤 리졸버와 통신할 수 있는지를 결정한다. 세 가지 질문이 설계를 정하며, 각각은 연결이 성공한 채로도 잘못 답할 수 있다.

분할 터널 플래그는 목적지 목록이 아니다

AWS는 분할 터널링을 연결 설정 시 엔드포인트 경로를 클라이언트의 경로 테이블에 추가하는 것으로 설명한다. 사설 VPC 경로는 터널을 그 목적지로 제한하고, 나머지는 클라이언트의 평소 경로를 따른다. 기본 경로는 효과가 다른 별개의 지시이며, 그래서 분할 터널 문서 는 이 모드로 구성된 엔드포인트에서 0.0.0.0/0을 게시하지 말라고 경고한다. 게시하면 연결을 넓히기보다 대개 끊는다. 엔드포인트 경로 테이블이 정책이고, 클라이언트 경로 테이블은 확인할 수 있는 결과다.

엔드포인트 경로 테이블과 클라이언트에 설치된 경로를 함께 읽는다. 레이블은 의도를 설명하고, 경로는 실제로 일어나는 일을 설명한다.

첫 번째 결정: 일반 인터넷 트래픽을 로컬에 두어야 하는가

브라우징이 사용자 자신의 연결을 쓰게 하려면 업무에 필요한 사설 목적지만 게시하고 거기서 멈춘다. 전체 터널 자습서에 하나가 있었다는 이유로 인터넷 경로를 추가하지 말고, 추가 경로가 보안을 개선한다고 가정하지 않는다. 경로를 바꿀 뿐 정책을 더하지 않으며, 예산에 없던 지연을 치르게 된다.

인터넷 트래픽이 AWS를 통해 나가야 한다면 문서화된 인터넷 액세스 아키텍처를 만든다. 엔드포인트 경로, 권한 부여 규칙, 연결된 서브넷의 경로, 보안 정책, 그리고 동작하는 상위 이그레스다. 기본 경로만으로는 그중 어느 것도 제공하지 않는다.

두 번째 결정: 어떤 사설 프리픽스를, 누구의 승인으로 게시할 것인가

실제 작업 부하를 지원하는 가장 작은 목적지 집합을 게시하고, 연결된 각 서브넷이 그곳으로 라우팅할 수 있는지 확인한다. 엔드포인트의 경로 대상과 서브넷의 VPC 라우팅은 서로 다른 계층이며, 한쪽에 있는 경로가 다른 쪽의 증거는 아니다. 권한 부여도 별개다. 목적지에 도달할 수 있어도 클라이언트 그룹에 허용 규칙이 없으면 거부된다.

성공한 세션 하나를 시험하는 것은 경로 하나를 증명할 뿐이다. 연결된 각 서브넷을 확인한다. 나중에 추가된 서브넷 연결이 바로 빠진 경로가 숨어 있는 곳이기 때문이다.

목적지에 이름으로 도달해야 한다면 다음 질문은 경로가 아니라 이름 해석이라는 점에 주의한다.

세 번째 결정: 어떤 리졸버가 터널을 따르는가

클라이언트는 VPN으로만 도달할 수 있는 DNS 서버를 받을 수 있고, 그 리졸버는 자신의 주소가 승인된 경로 안에 있을 때만 동작한다. 두 절반을 모두 검증한다. 리졸버 주소가 게시된 경로를 따르는지, 그리고 서버가 애플리케이션이 묻는 이름에 응답하는지다. 주소로는 성공하지만 호스트 이름으로 실패하는 요청은 라우팅이 아니라 이름 지정의 문제를 가리키며, 그 상태에서 터널을 디버깅하면 오후를 낭비한다.

공개 이름은 연결 전과 같이 해석되어야 하며, 이것이 무엇을 게시하는지 정확해야 하는 또 하나의 이유다.

경로 집합을 바꾸고 나서 두 세계를 모두 검증한다

AWS는 분할 터널 엔드포인트에서 경로를 변경하면 클라이언트 연결이 재설정된다고 문서화한다. 이를 염두에 두고 변경을 계획한다. 적용하고, 지원되는 클라이언트로 다시 연결하고, 편집 전에 적용된 상태를 믿는 대신 설치된 경로를 다시 읽는다. 오래된 적용 상태가 올바른 변경이 깨져 보이는 가장 흔한 이유다.

사설 리소스 하나와 공개 목적지 하나가 모두 의도대로, 이름과 주소로, 실제로 지원하는 주소 체계에서 동작할 때만 설계를 받아들인다. 인증이 되는 터널과 올바르게 분할하는 터널은 같지 않다.

경로 목록을 근거 옆에 런북으로 적어 두어, 다음 사람이 의도적인 제외와 잊힌 제외를 구별할 수 있게 한다.