안녕하세요. 인프랩 데브옵스 엔지니어 구피입니다!

다들 많이 사용하시다시피, 인프랩에서도 사설망 내부 자원에 대한 접근 관리를 위해 VPN을 쓰고 있습니다. VPN 구축을 위해 AWS Client VPN, Firezone을 사용하다 현재는 Tailscale을 선택하여 사용하고 있는데요.

이번 글에선 인프랩에서 VPN 툴을 선택하면서 고려했던 기준과 경험을 공유하고자 합니다.

VPN이란?

VPN(Virtual Private Network, 가상 사설망)은 공공 네트워크를 통해 사설 네트워크에 안전하게 접근할 수 있도록 해주는 기술입니다. VPN은 암호화된 연결을 통해 사용자의 기기와 사설 네트워크 간의 데이터를 보호하며, 인증된 사용자의 트래픽만 사설망에 접근 가능하도록 인가합니다.

기업에서는 회사에서 사용하는 리소스의 보안성을 지키고 네트워크 접근을 통제하기 위해 VPN을 사용합니다. 즉, 재택근무를 하거나 카페에서 인터넷을 사용할 때에도 개발 서버나 DB에 안전하게 접근할 수 있는 환경을 만듭니다.

AWS Client VPN

https://aws.amazon.com/vpn/client-vpn

처음 VPN 구축을 위해 사용했던 것은 AWS Client VPN이었습니다.

AWS Client VPN은 OpenVPN 프로토콜을 지원하는 AWS의 관리형 VPN 서비스입니다. OpenVPN 기반 VPN 클라이언트를 이용하여 AWS VPC 네트워크에 접속할 수 있도록 합니다.

AWS Client VPN을 선택한 이유

• AWS Client VPN은 AWS의 완전관리형 서비스이므로, OpenVPN 서버에 대한 공격에 직접 대응하지 않아도 되며 프로비저닝과 업데이트를 AWS가 해주므로 관리를 위한 공수가 적다는 장점이 있습니다.

• AWS Client VPN의 요금은 시간당 요금과 시간당 연결 요금 두가지로 청구 되는데, 고정 요금이 낮아 저렴하게 사용할 수 있었습니다.

• 또, 사용자 인증 시 Google Workspace 등에서 지원하는 SAML을 통한 SSO를 사용할 수 있어 편리하게 구축할 수 있었습니다.

아쉬웠던 점

AWS Client VPN을 1년 간 사용했으나 모바일 앱, 웹 QA를 진행할 필요성이 생기면서, AWS Client VPN의 모바일 클라이언트에서 SAML 기능을 지원하지 않는다는 점이 불편했습니다. 모바일에서 QA를 진행하거나 admin에 접근해야하는 경우가 많아졌기에 모바일 인증이 가능한 다른 VPN을 모색하였습니다.

Firezone

https://www.firezone.dev

그 다음으로 사용한 것은 WireGuard 프로토콜 기반 VPN 오픈소스인 Firezone이었습니다.

Firezone을 선택한 이유

• Firezone VPN은 모바일 브라우저에서 Google SSO를 이용해 로그인 후, Wireguard 앱을 통해 VPN 세션을 정상적으로 연결할 수 있었습니다.

• Hacker News에 소개되기도 하며 많은 사람이 관심갖는 오픈소스였기에 커뮤니티 지원을 기대할 수 있었습니다.

• 거기에 속도와 레이턴시가 우수하다는 장점도 있었습니다. WireGuard는 경량 암호화 알고리즘, 커널 레벨의 명령어셋을 활용해 OpenVPN 대비 3~4배 우수한 성능을 가지고 있습니다. Firezone을 사용함으로써 WireGuard의 성능상 이점을 쉽게 누릴 수 있었습니다.

아쉬웠던 점

Firezone을 2년간 만족스럽게 사용했지만, 아래와 같은 아쉬운 점이 있었습니다.

오픈소스 지원 중단

• 구축 당시 Firezone 최신 버전이 0.x 버전이었기에 안정적인 1.x 버전이 나오는 것을 기다렸습니다. 그런데 Firezone이 0.7 버전을 기준으로 Closed source 전환 및 유료화 계획을 발표했습니다. 따라서 지속적인 기능 지원 및 업데이트를 기대하기 어려웠습니다.

세션 및 권한

• Firezone VPN을 구축하며 네트워크 환경 보안성을 높이기 위해 prod, dev VPN을 분리하였습니다. 운영 환경에 모든 개발팀이 접근할 수 있으면 개인정보 및 보안 문제가 발생할 수 있기 때문에, prod 환경에는 인가된 사람만 접근할 수 있도록 구성한 것 입니다. 하지만 firezone은 세부 권한 지정이 불가능했기에 dev, prod vpn을 각각 구성했습니다.

  

• 보안성은 개선되었지만 개발 과정 중 두 환경에 모두 접근해야하는 경우 각 VPN에 device를 등록하고, 둘 중 하나씩만 키며 오가야 하는 불편이 있었습니다. 두 환경을 오가는 불편함 없이 인가된 사용자만 prod에 접근한다는 조건을 충족할 수 있는 효율적인 권한 설정 방법이 필요했습니다.

• 또, Firezone VPN은 로그인 세션 만료시 클라이언트에서 만료 여부를 확인할 수 없었습니다. VPN을 활성화해도 작동하지 않는다면 Firezone 웹페이지에 다시 접속하여 로그인해야 세션을 재활성화해야 했습니다. 이처럼 세션과 권한 관리에 사소한 불편이 있었습니다.

CloudFront에 대한 Split tunnel

• VPN 사용량이 많아지면서 불필요한 트래픽 절감을 위해 Split tunnel 기능을 사용하고자 했습니다. Split tunnel은 말 그대로 특정 IP 대역만 VPN을 거치도록 하고, 나머지는 일반 인터넷을 통하게 분리하는 것입니다.

• 개발, 운영 서버의 VPC IP 대역과 LB, CloudFront에 접근할 때만 VPN을 거치면 되기 때문에, 불필요한 트래픽이 VPN을 거치는 것을 막으면 비용을 줄일 수 있을 것으로 생각했습니다.

• 하지만 개발 서버 CloudFront에 대한 트래픽을 Split tunneling하기 위해선 AWS CloudFront에 사용되는 IP 대역 전체를 VPN 범위에 추가해야 했습니다. CloudFront 대역 전체를 포함하면 개발서버 외의 다른 트래픽도 VPN을 거칠 수 있다는 의미이기도 합니다. 따라서 Split tunnel이 있어도 불필요한 VPN 트래픽 비용이 일부 발생했습니다.

Tailscale

Firezone의 유료화를 계기로, 권한 및 세션 관리, Split tunnel 등 세부적인 요구사항을 같이 충족할 수 있는 솔루션을 탐색했습니다.

Tailscale과 Netbird

https://tailscale.com https://netbird.io

고민을 거쳐 찾은 두 개의 솔루션이 Tailscale과 Netbird였습니다. Tailscale은 SaaS 제품이고, Netbird는 BSD-3 라이센스의 오픈소스입니다. 두 서비스는 기능적으로 비슷한 특징이 많습니다.

기본 기능

• 둘 다 Firezone과 마찬가지로 WireGuard 기반 VPN 서비스입니다.
• 태그, 혹은 그룹 단위로 상세한 권한 설정이 가능합니다.

VPN 서버 구조

• AWS Client VPN과 Firezone은 중앙에 있는 하나의 VPN Server에 여러 클라이언트가 연결되었던 데 반해, Tailscale과 Netbird는 여러 클라이언트를 Private network로 묶어 구성하는 구조입니다.

• 기존 VPN을 구성했던 것처럼 한 클라이언트를 VPN Server 역할로 사용할 수도 있고, 연결된 클라이언트끼리 같은 네트워크에 연결된 것처럼 private IP로 통신할 수도 있습니다. 여러 상황에 따라 다양하게 구성할 수 있습니다.

도메인에 대한 Split tunnel

• 그리고 도메인 기준 Split tunnel이 가능합니다. 자세한 구현은 조금 다르지만, 도메인을 통한 Split tunnel은 VPN 클라이언트에서 DNS 서버를 프록싱함으로써 동작합니다. 간단한 동작 과정은 다음과 같습니다.

  1. VPN 클라이언트 설치시 도메인 서버 프록시가 실행된다. (DNS 쿼리가 프록시를 향하도록 /etc/resolv.conf 파일 내용이 자동으로 수정된다. )
  2. VPN이 도메인 서버 프록시 주소로 DNS 쿼리를 날린다.
  3. 프록시가 실제 도메인 서버로 쿼리한 후, 결과로 나온 IP를 VPN 범위에 추가한다.

• 도메인을 기준으로 VPN 통과 여부를 설정할 수 있기에 CF 대역의 IP를 전부 허용하지 않고 필요한 도메인만 VPN을 거치도록 설정할 수 있습니다. 주기적으로 도메인 쿼리를 다시 수행해 갱신하기에 대상이 바뀌어도 동작합니다.

Tailscale을 선택한 이유

• Netbird는 오픈소스이기 때문에 서버 호스팅 외 비용이 들지 않는다는 장점이 있습니다. 하지만 도메인을 대상으로 한 라우팅 기능이 최근(2024년 6월 초) 개발되었고, 내부 테스트시 iOS 및 안드로이드 클라이언트에서의 작동이 아직 불안정했습니다.

• 반면 Tailscale은 다양한 OS의 클라이언트에서 Split tunnel 및 세션 갱신 기능이 원활하게 동작했고, 세션 만료나 계정별 권한 정책을 관리하기 수월했습니다. 현재로선 관리 공수가 적은 SaaS를 사용하는 것이 비용 효율적이라 판단했기에 Tailscale을 도입하여 사용하고 있습니다.

마무리

결론적으로, 인프랩은 내부 자원 접근 관리를 위해 AWS Client VPN → Firezone → Tailscale로 VPN 솔루션을 발전시켜왔으며 각 단계에서는 아래 요구사항들의 필요성과 충족도를 고려하여 의사결정이 진행됐습니다.

1. 사용자 경험

   • 모든 운영체제(데스크톱, 모바일)에서의 안정적인 작동
   • SSO 등 편리한 계정 인증 방식 지원
   • 세션 갱신, 관리의 용이성

2. 관리

   • 운영 및 유지보수에 필요한 리소스
   • 업데이트 및 보안 패치의 안정성
   • 세부적인 접근 권한 관리 기능

3. 기술적 요구사항

   • Split tunneling 지원 및 도메인 옵션 지원 여부
   • 네트워크 성능 (속도와 레이턴시)

입사 후 Tailscale PoC 작업을 진행하며 VPN 솔루션 선택 시 고려했던 사항들에 대해 정리해보았는데요. 부족한 글이지만 참고하실 수 있는 인사이트를 드렸길 희망합니다.

여러분의 환경에서도 안전하고 효율적인 VPN을 구성하실 수 있길 바랍니다!

읽어주셔서 감사합니다 :)