EC2의 Access Server 전체 터널: 체크박스 하나로 충분하지 않은 이유

EC2 인스턴스에서 소스 및 대상 확인을 끄는 것은 Access Server의 인터넷 출구에 관한 질문에 가장 많이 반복되는 답변이지만, 그 자체로는 클라이언트에게 아무것도 해 주지 않습니다. 이 확인은 AWS의 포워딩 제약입니다. 인스턴스가 자신의 주소가 아닌 소스나 대상을 가진 패킷을 받아들이게 합니다. 클라이언트에게 인터넷 트래픽을 터널로 보내라고 지시하지 않고, 상위 경로를 만들지 않으며, NAT를 추가하지도 않습니다. 체크박스가 곧 기능이라는 것이 오해입니다.

확인이 실제로 제어하는 것

모든 EC2 네트워크 인터페이스는 자신에게 향하지 않은 트래픽을 버립니다. 인스턴스가 라우터, NAT 장치 또는 VPN 게이트웨이 역할을 하고 그 확인을 꺼 둔 경우는 예외입니다. 끄면 포워딩 권한이 생깁니다. 권한은 구성이 아닙니다. 인스턴스에는 여전히 인터넷 게이트웨이나 NAT 장치로 가는 경로가 필요하고, VPC 라우트 테이블에는 일치하는 항목이 필요하며, 보안 그룹은 흐름을 허용해야 하고, 서버는 반환 트래픽을 변환하거나 라우팅해야 합니다.

무엇이든 바꾸기 전에 aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck 로 현재 값을 확인하세요. 콘솔에서 바꾼다면 클라이언트가 인터넷에 닿지 않아서가 아니라 인스턴스가 다른 이를 위해 포워딩하기 때문에 바꾸는 것입니다.

클라이언트 라우팅 정책은 Access Server의 것

Access Server 3에서 Access Controls를 열고 Internet Access and DNS 섹션을 찾으세요. Internet Gateway 선택은 전체 터널 또는 분할 터널을 제공합니다. 전체 터널은 클라이언트에게 기본 트래픽을 VPN 안으로 라우팅하라고 지시하고, 분할 터널은 인터넷 트래픽을 클라이언트의 로컬 경로에 남깁니다. 제품 워크플로로 저장하고 적용한 뒤 테스트 클라이언트를 다시 연결하세요. 정책은 연결 시점에 전달되기 때문입니다.

오래된 릴리스는 다른 메뉴를 사용하고 일부 Community OpenVPN 빌드에는 동등한 제어가 없습니다. 존재하지 않는 화면을 찾기 전에 설치된 주 버전을 확인하세요. 그다음 클라이언트가 무엇을 받았는지 확인하세요. 전체 터널 프로필은 터널을 통한 기본 경로를 설치해야 하고, 분할 터널 프로필은 그렇게 해서는 안 됩니다.

터널 이후 패킷을 추적하세요

클라이언트가 인터넷 트래픽을 터널로 보내면 서버는 이를 포워딩해야 하고 보통 변환해야 합니다. Access Server는 자체 NAT 및 라우팅 규칙을 관리하므로 생성된 파일에 Community OpenVPN 규칙을 덧붙이지 말고 실제 구성를 읽으세요. 관리되지 않는 규칙은 다음 제품 업데이트에서 덮어써지거나 충돌합니다. sudo iptables -t nat -L -n -v 또는 nftables의 동등한 명령은 실제로 무엇이 변환되는지 보여 줍니다.

AWS 쪽은 별도의 경로입니다. 퍼블릭 서브넷의 인스턴스는 인터넷 게이트웨이에 직접 도달하고 퍼블릭 주소나 탄력적 IP를 유지합니다. 프라이빗 서브넷의 인스턴스는 NAT 게이트웨이나 NAT 인스턴스로 가는 경로가 필요하고, NAT 장치는 인터넷 게이트웨이로 가는 자체 경로가 필요합니다. 인터넷 게이트웨이를 VPC에 연결하는 것만으로는 어떤 프라이빗 소스에도 퍼블릭 반환 주소가 생기지 않습니다. 그래서 같은 Access Server 구성이 한 서브넷에서는 동작하고 다른 서브넷에서는 조용히 실패합니다.

인스턴스 서브넷에 연결된 라우트 테이블을 확인하세요. VPC의 메인 테이블만 보지 마세요. 서브넷 연결은 메인 테이블을 우선하며, 오래된 연결은 재구축 후 동작하던 구성이 멈추는 흔한 원인입니다.

IP 출구와 DNS를 분리하세요

같은 클라이언트 앱에서 먼저 주소 리터럴을, 다음으로 이름을 시험하세요. curl -4 https://checkip.amazonaws.com 가 퍼블릭 주소를 반환하는데 호스트 이름이 실패한다면 터널과 NAT 경로는 동작하고 문제는 DNS입니다. 푸시된 리졸버, 클라이언트의 리졸버 상태, 또는 리졸버를 막는 보안 그룹입니다. Access Server의 DNS 설정은 같은 Internet Access 영역에 있지만 다른 코드 경로를 지납니다.

반환된 주소를 의도한 출구와 비교하세요. 인스턴스의 퍼블릭 주소라면 인스턴스가 트래픽을 변환하는 것이고, NAT 게이트웨이 주소라면 프라이빗 서브넷 경로가 쓰이는 것입니다. 둘 다 올바를 수 있습니다. 확신할 수 없는 것은 서버의 브라우저가 클라이언트 포워딩을 증명한다는 점입니다.

체크박스 하나가 조사를 끝내게 두지 마세요

IPv6는 별도의 결정입니다. IPv4용 전체 터널 정책은 IPv6가 전달되는지, 차단되는지, 유출되는지에 대해 아무것도 말하지 않으며, 이중 스택 클라이언트는 IPv4가 터널에 있는 동안 로컬 IPv6 경로를 계속 쓸 수 있습니다. 실제로 중요한 주소 체계를 시험하고, 다른 하나를 비활성화해야 하는지 명시적으로 결정하세요.

마지막으로 연결이 끊긴 상태를 시험하세요. 전체 터널 선택은 연결된 동안의 라우팅 정책을 설명할 뿐, 터널이 끊겼을 때 벌어지는 일이 아닙니다. VPN 밖으로 어떤 트래픽도 새지 않아야 한다는 요구라면 그것은 kill-switch와 방화벽의 문제이며, 라우트 테이블에서 추론하는 대신 자체 시험이 필요합니다.