Securing a Network
strongSwan은 서버와 클라이언트에게 암호화와 인증을 제공하는 IPsec 솔루션으로 원격 네트워크와의 통신을 안전하게 보호한다. 이로서 원격 연결 네트워크를 로컬 연결 네트워크처럼 만들어준다.
Gateway
gateway는 방화벽으로 주로 사용되지만 네트워크 내의 모든 호스트가 될 수 있다. 이밖에도 DHCP, DNS를 사용하는 소규모 네트워크를 제공할 수도 있다. 위의 사진에서 host moon과 sun은 내부 host인 alice, venus 그리고 bob 각각을 위한 게이트웨이 역할을 한다.
Remote Access / Roadwarrior Clients
일반으로, roadwarriors는 gateway를 통해 우리들의 집 네트워크에 원격으로 연결되는 노트북이나 핸드폰과 같은 디바이스들이다. 위 사진에서 carol과 dave는 두 게이트웨이(moon & sun) 뒤에 있는 두 네트워크에 접근하고자 하는 roadwarrior를 나타낸다.
Remote Hosts / Host-to-Host
위 사진에서 호스트 winnetou와 게이트웨이 moon 및 sun 중 하나가 원격 웹 서버나 백업 시스템을 나타낼 수 있다. 두 호스트 간의 연결은 일반적으로 (호스트)둘중 하나에 의해서 시작된다.
Remote Sites / Site-to-Site
서로 다른 위치의 두 개 이상의 서브넷에 속한 호스트들이 서로 접근할 수 있어야 한다. 위 사진에서 게이트웨이 moon과 sun뒤에 각각 존재하는 10.1.0.0/16과 10.2.0.0/24 서브넷이 연결되어, alice와 bob과 같은 호스트들이 안전하게 통신할 수 있어야 한다.
IKE and IPsec Basics
strongSwan은 기본적으로 두 peer 간에 SA(Security Associations)를 만들고 SP(Security Policies)를 협상하기 위해 IKEv2 프로토콜을 사용하는 keying daemon이다.
Keying Daemon은 VPN 연결을 설정하고 관리하는 핵심 프로세스다. strongSwan에서는 charon 프로세스로 IKEv2 프로토콜 관련 모든 기능을 처리한다.
IKE는 VPN 피어 간 강력한 인증 과정 제공하며 암호화 및 인증에 사용되는 고유한 세션 키를 생성한다. 그리고 IPsec SA를 협상해 어떤 네트워크 트래픽을 보완할지, 어떻게 암호화 및 인증을 제공할지 결정한다.
IKE_SA는 IKE 세션 자체를 나타낸다. 이 세션은 인증과 키 생성을 담당한다.
CHILD_SA는 실제 IPsec 트래픽을 보호하는 보안 연결을 나타내며 IKE_SA 내에서 협상된다.
CHILD_SA의 구성 요소
트래픽을 암호화하고 인증하는 데 사용되는 알고리즘과 키를 정의하는 IPsec SA와 어떤 네트워크 트래픽이 해당 SA를 사용해야 하는지 정의하는 Policy로 구성된다. Policy는 양방향으로 적용되며, 일치하는 인바운드 policy가 없는 트래픽은 삭제된다.
IPsec 트래픽 처리
IPsec 트래픽은 운영 체제 커널의 네트워크 및 IPsec 스택에 의해 처리된다. strongSwan은 협상된 IPsec SA와 SP를 커널에 설치하는 역할을 한다.
Policy와 SA의 구분
위 사진에서 host moon이 host sun과 site-to-site connection을 갖고 있고, host carol이 host sun과 roadwarrior connection을 갖고 있으며 sun이 포워딩이 가능하다해도 carol은 alice와 통신할 수 없다.
그 이유는 carol과 alice 사이에 traffic을 허용하는 IPsec Policy가 없기 때문이다. 이때 moon과 sun 사이 가상 서브넷을 연결하는 추가 SA가 있다면 carol과 alice의 통신이 가능하게 될 것이다. 이처럼 Policy는 CHILD_SA를 생성할 때 IKE를 통해 협상되는 traffic selectors(TS)에 의해서 파생된다.
Routing과 IPsec Processing의 관계
IPsec은 일반적으로 네트워크 스택에 투명하게 적용되어 policy에 따라 트래픽을 처리한다. 따라서 원격 TS로 향하는 어떤 경로를 사용해도 IPsec 처리가 가능하다. 그러나 VPN 호스트 자체에서 트래픽이 발생하는 경우, 소스 주소 선택이 문제가 될 수 있다. 로컬 TS에 public 주소가 포함되어 있지 않으면 기본 경로에 따라 선택된 소스 주소로 인해 IPsec 처리가 되지 않을 수 있다. 이는 가상 IP주소를 사용하는 경우에 특히 문제가 될 수 있다.
소스 주소 선택이 IPsec VPN에서 왜 문제가 될까?
IPsec VPN 터널을 통해 트래픽을 보내려면, 소스 주소가 로컬 TS에 포함되어 있어야 한다. 그렇지 않으면 트래픽이 IPsec 처리를 받지 못하고 일반 경로로 전달될 수 있기 때문이다.
이 문제를 해결하기 위해 strongSwan의 charon IKE daemon은 기본적으로 대부분의 CHILD_SA에 대해 원격 TS로의 특정 경로를 설치해 이를 통해 로컬 TS의 주소가 소스 주소로 선택될 수 있도록 한다.
대안으로 인터페이스와 explict route를 사용하여 IPsec 터널에 의해 처리될 트래픽을 제어하는 route-based IPsec를 사용하기도 한다.
Authentication Basics
To ensure that the peer with which an IKE_SA is established is really who it claims to be, it has to be authenticated.
IKE_SA가 설정되려면 peer가 인증이 필수적이다. IKE_SA를 통해 VPN 터널이 설정되면 양측 peer가 서로를 신뢰할 수 있어야 하고, peer 인증을 거치지 않으면 중간자 공격(MITM attack)에 취약해질 수 있기 때문이다.
그렇다면 어떻게 peer간 인증을 진행할까?
Public Key Authentication
- RSA, ECDSA 또는 EdDSA X.509 인증서를 사용해 peer의 진위 여부를 검증한다.
- 자체 서명된 인증서 혹은 인증 기관(CA)에서 서명된 인증서를 사용할 수 있다.
- CA 인증서만 있으면 모든 peer를 인증할 수 있어 배포와 구성이 간단해진다.
- 중간자 공격을 방지하기 위해 peer의 ID가 인증서의 subject DN 또는 subjectAltName 확장자와 일치해야 한다.
Pre-Shared-Key Authentication (PSK)
- 배포는 쉽지만 강력한 비밀 키가 필요하다.
- 많은 사용자가 PSK를 알고 있는 경우 누구나 게이트웨이를 가장할 수 있어 대규모 배포에는 적합하지 않다.
Extensible Authentication Protocol (EAP)
- EAP-MD5, EAP-MSCHAPv2, EAP-GTC, EAP-TLS 등 다양한 인증 방식을 지원한다.
- RADIUS 서버를 사용하여 사용자 인증을 위임할 수 있다.
- IKEv2에서만 사용 가능하다
IKEv2 프로토콜에서는 RFC 4739에 따라 Multiple Authentication Exchanges가 가능하다. 그렇기 때문에 한 번에 IKE_AUTH 교환 내에서 여러 번의 인증 과정을 수행할 수 있다. 그 예시로 첫 번째 authentication round에서 gateway를 인증서로 인증하고, 두 번째 authentication round에서 client를 username/password 기반 EAP 방식으로 인증할 수 있다.
다양한 인증 방식을 조합하는 것이 IKEv2 구현체의 특징이지만, 모든 IKEv2 구현체가 그런건 아니므로 사용 전 확인이 필요하다.
Configuration Files
strongSwan을 구성하는 가장 좋은 방법은 vici control interface나 swanctl command line tool을 사용하는 것이다.
swanctl.conf configuration file은 인증서와 private key와 함께 swanctl 디렉토리에 저장된다.
swanctl.conf 파일은 다음과 같은 주요 섹션으로 구성된다.
- connections: VPN 연결 설정 (IKE 및 IPsec parameter, 인증 방법, 암호화 알고리즘 등이 포함된다.)
- secrets: 공유 키, 개인 키 등의 비밀 정보
- authorities: 신뢰할 수 있는 인증 기관(CA) 정의
- pki: 인증서 관리 설정
'[AWS-FRF] > VPN' 카테고리의 다른 글
[중요][AWS] VPC와 fortigate VPN연동하기!! (12) | 2024.10.28 |
---|---|
[참고][AWS] AWS Site-to-Site VPN with Fortigate !! (15) | 2024.10.28 |
[중요][AWS] Site-to-Site #vpn #handson - #hybrid #network #connectivity between #onpremise and #amazon #vpc (30) | 2024.10.15 |
[Raspberry Pi] 라즈베리파이 이란? (13) | 2024.10.14 |
[참고][AWS] Direct Connect와 Site to Site VPN 비교하기!! (10) | 2024.09.12 |
댓글