블로그 릴레이 - Client VPN을 연결해도 통신이 되지 않는다면?
안녕하세요! 클래스메소드의 이수재입니다.
본 블로그는 당사의 한국어 블로그 릴레이의 2025년 31번째 블로그입니다.
이번 블로그의 주제는「Client VPN을 연결해도 통신이 되지 않는다면?」입니다.
ClientVPN과 같은 네트워크 계열 서비스를 추가한 후에 네크워킹이 생각한대로 네트워킹이 되지 않는 경우가 있습니다.
저도 이번에 ClientVPN을 추가한 후 통신이 제대로 되지 않았던 프로젝트가 있었습니다.
이 글에서는 문제가 발생한 경우 어떤 부분을 확인해나가면서 원인을 파악 해나가면 되는지를 알아봅니다.
확인해나가는 순서
가장 먼저 확인할 자료는 AWS 에서 제공하고 있는 트러블 슈팅 페이지입니다.
여기서 현재 상황과 같은 문제가 기재되어 있다면 확인해봅시다.
이후 저는 다음과 같은 순서로 문제점을 확인해나갔습니다.
- AWS 내부 설정 확인
- 보안 그룹 및 NACL
- 라우팅 테이블
- ClientVPN 자체 설정
- Reachability Analyzer
- AWS 위의 서버 측 확인
- 로그 확인
- 서버 내의 방화벽
- 액세스 대상 소프트웨어의 설정 확인
- 온프레미스 측 설정 확인
- DNS 서버 및 라우팅 확인
제가 담당했던 안건에서는 액세스 대상 소프트웨어에서 ClientVPN이 연결된 서브넷으로부터의 연결을 허용하지 않았던 것이 문제였습니다.
보통은 위의 내용들을 검토하는 것으로 액세스 문제는 해결할 수 있다고 생각합니다.
AWS 내부 설정 확인
보안 그룹 및 NACL 확인
우선 ClientVPN을 통해 액세스하기 위한 리소스와 그 리소스에 연결된 보안 그룹을 확인합니다.
허용하는 포트와 소스가 제대로 되어있는지 확인합니다.
주의할 내용으로 ClientVPN을 통해 연결하는 경우 ClientVPN 자체의 CIDR가 아닌 ClientVPN이 연결된 서브넷의 CIDR를 허용할 필요가 있다는 점입니다.
Client VPN 네트워크 인터페이스
서브넷을 Client VPN 엔드포인트와 연결하면 해당 서브넷에 Client VPN 네트워크 인터페이스가 생
성됩니다. Client VPN 엔드포인트에서 VPC로 전송된 트래픽은 Client VPN 네트워크 인터페이스를
통해 전송됩니다. 그런 다음 클라이언트 CIDR 범위의 소스 IP 주소가 Client VPN 네트워크 인터페
이스 IP 주소로 변환되는 소스 네트워크 주소 변환(SNAT)이 적용됩니다. - ClientVPN 관리자 안내서
즉, ClientVPN이 연결된 서브넷에 ENI가 생성되고, 유저는 해당 ENI를 통해 리소스에 접근하는 방식입니다.
따라서 보안 그룹의 규칙에 ClientVPN의 CIDR를 허용하도록 설정한 항목이 있다면 수정이 필요합니다.
NACL도 설정하여 엄격한 보안을 설정하여 사용하고 있다면 NACL의 규칙도 같은 문제가 없는지 확인합니다.
라우팅 테이블
하나의 VPC를 사용하는 환경이고 ClientVPN도 해당 VPC의 서브넷과 연결되어 있다면 라우팅 테이블 문제는 발생할 가능성이 적습니다.
다만 여러 VPC를 사용하고 VPC 피어링이 설정된 환경이라면 ClientVPN 이 설정된 VPC와 제대로 피어링이 설정되어 있고 라우팅 테이블도 해당 피어링 연결을 사용하도록 설정되어 있는지 확인합니다.
ClientVPN의 설정
ClientVPN에서 설정 가능한 권한과 라우팅 테이블에 문제가 없는지 확인합니다.
상호 인증 방식이라면 문제 없지만 다른 방식의 경우 권한 설정에서 유저 별로 설정이 다른 경우가 있기 때문에 해당 설정에 문제가 없는지도 확인합니다.
특히 기존 환경의 설정에 따라 DNS와 연관된 문제가 발생하는 경우가 많습니다.
ClientVPN 설정의 DNS 지정에 잘못된 값이 없는지 확인합니다.
DNS 연결에 대해 참고가 될 글도 공유합니다.
Reachability Analyzer
AWS 내의 설정이 모두 문제없는 것으로 판단된다면 Reachability Analyzer을 사용하여 검출되는 이슈가 없는지 확인해봅니다.
Reachability Analyzer은 AWS의 네트워크 관리자에서 사용 가능하며 VPC 콘솔의 가장 아래에 "네트워크 관리자" 라는 메뉴에서 접근 가능합니다.
특정 소스나 포트 등에서 리소스에 접근이 가능한지 분석을 해주는 기능이며 실행에는 다소의 요금[1]이 발생합니다.
사용 방법 자체는 간단하므로 링크로 대체합니다.
AWS 위의 서버 측 확인
로그 확인
VPC Flow log나 서버 로그 등을 확인하여 액세스가 어느 레이어에서 막혔는지 확인합니다.
서버 내부의 로그에 액세스한 기록조차 남아있지 않다면 AWS 측이나 클라이언트 측 환경이 원인일 확률이 높습니다.
만약 서버 내부에 액세스한 기록이 있지만 차단되어 있다면 서버의 방화벽이나 소프트웨어 등을 확인해봅시다.
서버 내의 방화벽
AWS의 보안 그룹이나 NACL에서는 문제가 없어도 서버 내부의 방화벽이나 다른 설정에 의해서 접근이 막히기도 합니다.
보통 방화벽이 원인이 되는 경우가 많으므로 액세스를 허용할 IP나 포트 등에서 문제가 없는지 확인하는게 좋을 것 같습니다.
액세스 대상 소프트웨어의 설정 확인
액세스 대상이 별도의 소프트웨어를 사용하고 있고 해당 서비스에 액세스해야하는 경우 해당 소프트웨어의 설정을 변경해야하는 경우도 있습니다.
예로 들면 제가 담당한 케이스에서는 Samba를 이용하여 파일 서버를 배포하고 있었던 상황이었습니다.
samba의 설정 파일에 정의된 내용으로는 ClientVPN 서브넷으로부터 접근하는 유저를 허용하지 않도록 설정되어 있었기 때문에 설정 파일을 변경하고 samba를 재시작 할 필요가 있었습니다.
이렇듯 사용하는 소프트웨어에 따라 적절한 설정 변경이 되어 있는지 확인해주세요.
클라이언트 측 설정 확인
AWS 와 액세스 대상 서버에서도 문제가 없다면 액세스하는 클라이언트(혹은 온프레미스 환경) 측의 설정을 확인해볼 필요가 있습니다.
DNS 및 라우팅 확인
우선 ClientVPN에 연결한 후 nslookup커맨드를 실행하여 DNS를 확인해봅시다.
$ nslookup {확인 필요한 도메인명 혹은 ip}
Server: dns.google
Address: 8.8.8.8
DNS 해석이 정상적으로 진행된다면 해당 도메인이나 IP의 해석 결과를 확인할 수 있습니다.
혹시 정상적인 값이 표시되지 않는다면 DNS 서버의 주소가 의도한 곳인지 확인합니다.
내부 DNS를 사용하고 있는데 표시되지 않는다면 Client VPN의 사용자 지정 DNS 서버 옵션의 설정이 제대로 설정되어 있는지 확인합니다.[2]
만약 ClientVPN의 옵션은 제대로 설정되어 있는데 문제가 발생한다면 지정한 DNS 서버에서 특정 IP만 허용하도록 설정되어있는 등 내부 설정에 의한 통신 차단은 없는지 확인해봅니다.
그리고 라우팅도 문제가 없는지 확인해봅니다.
# 윈도우
route print
# 리눅스
netstat -nr
그리고 포트 번호도 확인해줍니다.
목적지로 향하는 라우팅에는 문제가 없는지, 포트는 사용되고 있지 않은지를 확인해봅니다.
혹시 라우팅이 잘못되었거나 이미 해당 주소로 포트가 사용되고 있다면 기존 경로를 정리하거나 다른 경로를 통해 접근하는 것을 검토해봅니다.
마무리
보통 여기까지 확인한다면 문제가 어디서 발생하고 있는지는 파악할 수 있다고 생각합니다.
문제의 원인을 파악할 수 있었다면 해결 방법은 금방 찾을 수 있을거라 생각합니다.
이상, 한국어 블로그 릴레이의 2025년 31번째 블로그 「Client VPN을 연결해도 통신이 되지 않는다면?」편이었습니다.
다음 32번째 블로그 릴레이는 9월 3주에 공개됩니다.
끝까지 읽어주셔서 감사합니다!
블로그에 대한 오탈자 및 내용 피드백은 must01940 지메일로 보내주시면 감사합니다.
문의 사항은 클래스메소드 코리아로!
클래스메소드 코리아에서는 다양한 세미나 및 이벤트를 진행하고 있습니다.
진행중인 이벤트에 대해 아래 페이지를 참고해주세요.
AWS에 대한 상담 및 클래스 메소드 멤버스에 관한 문의사항은 아래 메일로 연락주시면 감사드립니다!
Info@classmethod.kr
