본문 바로가기
Network

[Network] IPSec VPN

미르-0604 2024. 3. 30. 14:31

해당 내용은 실제로 NCP, AWS - VPN 연동을 하며 알아야하는 기초지식과 실제 사례를 작성한 글입니다.

 

IPSec 이란

IPSec 은 장치간 암호화된 연결을 구성하는데 사용되는 프로토콜 세트입니다.

주로 공용네트워크를 통해 전송되는 데이터를 안전하게 보호하는데 도움이 됩니다. (네트워크 계층)

 

IPSec 프로토콜은 표준화된 3계층 터널링 프로토콜로 종종 VPN 을 구성하는 데 사용됩니다.

IP 패킷을 암호화하고 해당 데이터의 출처를 인증하는 방식으로 작동합니다.

 

IPSec 의 터널 동작모드

Transport Mode : IP Packet에서 Payload 만 보호

Turnel Mode : IP Packet 전체를 보호

 

 

IPSec 의 구성

인증 헤더(AH) :

  • AH 프로토콜은 변조를 방지하는 프로토콜로 해당 데이터가 변조되지 않았음을 보장합니다. 따라서 이는 어떠한 암호화나 데이터를 숨기는 역할은 하지않습니다. 
  • 위와같은 무결성을 보장하는 방식은 MAC 을 사용합니다.

AH 헤더가 부착된 IP 패킷 (출처 : https://networklessons.com)

 

위의 그림이 초기상태의 패킷이고, 아래 패킷은 AH 헤더가 부착되어있습니다. AH 헤더는 기존 IP Header 와 Payload 를 인증한 후, 이를 해시화 해서 인증데이터를 넣어두었습니다. 따라서 이를 통해 데이터가 변조되었는지 알수있습니다.

 

 

캡슐화 보안 페이로드(ESP)

  • MAC 을 이용하여 무결성을 보장하고, 암호화 또한 지원합니다.

ESP 헤더가 부착된 IP 패킷 (출처 : https://networklessons.com)

 

ESP Header는 AH Header의 인증기능을 더해 대칭키 암호화를 지원합니다. ESP Trailer 는 암호화를 하면 생성되는 페이로드와 인증데이터를 구분하기위한 Padding 과 내부 프로토콜 헤더에 관한 정보를 담고있습니다. 

ESP Header는 IP Header와 IP Payload, ESP Trailer 를 암호화합니다. 그리고 이들을 해쉬함수를 통과시켜 ESP Auth 를 만듭니다.

 

 

보안 연결(SA)

AH Header 나 ESP Header 에는 SPI(Security Parameter Index) 가 존재하는데 이는 AH 의 식별번호입니다. 

SA 란 키 협상 및 암호화 알고리즘에 사용되는 프로토콜 집합을 의미합니다. SA에는 VPN 간 서로를 인증할 방법, 터널의 유지기간, 해쉬 알고리즘, 대칭키 알고리즘, 터널 동작모드, AH/ESP 헤더 사용에 대한 합의등 내용이 있습니다.

 

 

IKE(Internet Key Exchange)

IKE 란 SA 를 생성 혹은 협의하는 프로토콜입니다.

SA를 안전하게 교환하기 위해 IPSec 터널을 생성하고, 상대방을 인증하며 패킷을 암호화 / 인증할 알고리즘과 암호화 키를 안정적으로 교환할 수 있는 과정을 정의한 프로토콜입니다.

IKE Phase 1

Phase1 은 상대방을 인증하고, 암호 알고리즘을 결정하고, 암호화 키를 교환합니다. 따라서 SA 를 협상하여 안전한 터널을 생성합니다.

 

협의사항은 다음과 같습니다.

  • Hash : 인증정보 교환 시 인증정보의 무결성을 증명하기 위한 해시 알고리즘
  • Authentication : 상대 VPN 을 인증하기위한 방법 (Pre-Shared Key, RSA Encryption, RSA Signature)
  • DH Group : 인증정보를 암호화할 키를 생성하는 대칭 키 교환 알고리즘
  • LifeTime : Phsae 1 Tunnel 이 유지되는 시간
  • Encryption : 키 교환 알고리즘과 함께 인증정보를 암호화할 알고리즘

위의 사진은 Phase 1 의 SA 교환 과정입니다.

 

1. VPN 간 사용 가능한 SA 를 협의합니다. 한쪽이 먼저 ISAKMP 세트를 제안하면 상대방이 확인 후, 자신이 사용가능한 ISAKMP 세트 중 일치하는 것을 확인하여 답변을 보냅니다.

2. 결정된 DH 키교환 알고리즘을 사용하여 키의 재료들을 교환하고, VPN 간의 대칭키를 생성합니다.

3. 결정된 해시 알고리즘, 대칭키 알고리즘을 이용하여 인증정보를 암호화합니다.

 

IKE Phase 2

Phase1 에서 생성 된 안전한 터널을 기반으로 패킷을 암호화/인증 할 실질적인 SA 를 협의하고 패킷을 암호화하여 전송할 터널을 생성하는것입니다. 여기서 오가는 패킷은 Phase1에서 합의했던 대칭키, 알고리즘 등으로 암호화가 된다는 것입니다.

 

협의사항은 다음과 같습니다.

  • IPSec Protocol : 패킷 인증/암호화를 위한 프로토콜 헤더 선택 (위의 AH 혹은 ESP)
  • Encapsulation Mode : IPSec 터널의 운용 모드 선택 (위의 Transport 혹은 Tunnel)
  • Encryption :  패킷을 암호화할 암호화 알고리즘
  • Authentication : 패킷을 인증할 해시 알고리즘
  • Lifetime : Phase 2 Tunnel 이 유지되는 시간

위의 사진은 Phase 2 의 SA 교환 과정입니다.

 

1. 한쪽 VPN 이 IPSec 세트를 제안하면 상대방 VPN 이 확인 후, 사용가능한 세트 중 일치하는 것을 답변합니다. 

2. 새로운 대칭 키를 생성하여 암호화된 패킷을 전송 및 전달 받을 수 있습니다.

 

암호화 키는 오래 사용되면 사용될수록 보안이 약화됩니다. 따라서 Phase 1 의 Lifetime 보다 실질적으로 중요 내용이 담긴 패킷을 전달하는 Phase 2 의 Lifetime 을 짧게 설정하는 것을 권장합니다.

 

 

 

이제 SiteToSite VPN 을 설정할 때 필요한 지식들을 소개한 뒤, 제가 실제로 연동했던 상황들을 소개하겠습니다.

CIDR

라우팅 효율을 향상시키는 IP 주소 할당방법입니다.

 

네트워크 주소 : 네트워크를 구분하여 주는 주소, 네트워크 주소가 같다는 의미는 같은 네트워크 상에 있다는 이야기입니다.

호스트 주소 : 해당 네트워크에 속한 사용자에게 부여하는 주소

클래스 기반주소

클래스 A : 네트워크 접두사 비트가 8개입니다.

ex) 44.0.0.1 -> 44 는 네트워크주소, 0.0.1 은 호스트주소

 

클래스 B : 네트워크 접두사 비트가 16개입니다.

ex) 128.16.0.2 -> 128.16 는 네트워크주소, 0.2 은 호스트주소

 

클래스 C : 네트워크 접두사 비트가 24개입니다.

ex) 192.168.1.100 -> 192.168.1 는 네트워크주소, 100 은 호스트주소

유연하지 않은 IP 주소 지정

클래스 기반 배치는 IP 주소를 할당하는 데 있어서 비효율적이었고 IP 주소 공간 낭비로 이어졌습니다.

예를 들어 디바이스가 300개인 조직에서는 디바이스를 254개만 허용하는 클래스 C IP 주소를 사용할 수 없었습니다. 따라서 6만 5,534개의 고유한 호스트 주소를 제공하는 클래스 B IP 주소를 신청해야 했습니다. 하지만 디바이스는 300개만 연결되었기 때문에 6만 5,234개의 IP 주소 공간은 사용되지 않은 채로 남게 되었습니다.

클래스 없는주소

이것이 CIDR 입니다. 가변길이의 서브넷 마스킹을 사용하여 네크워크 주소와 호스트 주소의 비율을 변경합니다.

네트워크 관리자는 VLSM 시퀀스를 통해 IP 주소공간을 다양한 크기의 서브넷으로 나눌 수 있습니다. CIDR IP 주소는 네트워크 주소 접두사 비트 수를 나타내는 접미사 값을 일반 IP 주소에 추가합니다.

 

ex) 192.0.2.0/24 는 처음 24비트 즉, 192.0.2 가 네트워크 주소입니다.

ex) 192.168.1.0/22 는 위에서 언급한 유연하지 않는 IP 주소 지정에 대한 해결책으로 제시될 수 있습니다.

가상 프라이빗 게이트웨이 

가상 프라이빗 게이트웨이는 액세스해야하는 리소스가 포함된 VPC 에 연결해야합니다.

가상 프라이빗 게이트웨이를 생성할 때 자율 시스템 번호(ASN)을 지정할 수 있습니다.

고객 게이트웨이 

고객 게이트웨이 디바이스는 Site-to-Site VPN 연결을 위해 고객 측에 설치된 애플리케이션입니다. 

고객 게이트웨이 디바이스는 IKE 협상 프로세스를 시작하여 Site-to-Site VPN 연결을 위한 터널을 표시해야합니다. 

 

고객 게이트웨이는 고객 게이트웨이 디바이스의 정보를 제공하여 AWS 에 나타내는 리소스입니다.

가상으로 우리 측 AWS에 생성하여 고객 측 장비랑 매핑을 시키게됩니다.

 

환경-1

우리 측에 VPN 장비가 있는경우
하나의 게이트웨이만 원하는경우

우리 측 원격 IP 대역 : W.W.W.W/C
우리 VPN 장비 IP : A.A.A.A
고객 측 서버 IP 대역 : B.B.B.B/C

 

환경-1 의 설계도

 

고객 게이트웨이, 가상 게이트웨이 생성

위와 같이 고객, 가상 게이트웨이를 생성해줍니다.

 

 

SiteToSite 연동

이제 방금 생성한 가상 게이트웨이와 고객 게이트웨이를 설정하고, 라우팅옵션을 동적으로 사용할게 아니기때문에 정적으로 주게됩니다.

그러면 고정 IP 접두사를 기입할 칸이 생기고, 상대 측 서버 IP 대역을 기입하면 됩니다.

터널 옵션에는 IKE Phase 1, Phase 2 에 원하는 알고리즘 및 설정들을 할 수 있습니다.

또한 모든 옵션을 넣어 완성 하였다면 터널 세부정보로 탭을 옮겨 터널의 상태를 볼 수 있습니다.

상태를 위로 올리려면 라우팅테이블에 등록이되어 전파가 되야합니다.

 

추가로 우리 측 원격 IP 대역을 "원격 IPv4 네트워크 CIDR" 기입할 수 있습니다. (선택사항)

 

이제 구성정보 다운로드를 하여 고객 측에 관련 자료들을 넘기게되면 터널링을 시작하게됩니다.

  • 외부 IP 주소 : 고객 측에서 바라보는 우리 측 터널 IP 입니다.

환경-2

상대 측에 VPN 장비가 있는경우
두개의 게이트웨이를 원하는경우

우리 측 원격 IP 대역 : W.W.W.W/C

고객 측 게이트웨이 IP - 1 : A.A.A.1
고객 측 게이트웨이 IP - 2 : A.A.A.2
고객 측 서버 IP 대역 : X.X.X.X/C

 

환경-2 의 설계도

 

 

고객, 가상 게이트웨이를 만드는건 위와 같습니다. 하지만 이번 조건에선 고객이 원하는 게이트웨이는 2개이기 때문에 고객 게이트웨이와 SiteToSite VPN 은 2개씩 만들고 연동해야합니다.

설정은 위에서 설명한 환경 -1 에서의 설정대로 고객 게이트웨이 IP 만 다르게해서 하나씩 해주시면됩니다.

 

사설 IP 로 통신 (전반적인 설명)

AWS 측과 NCP의 IPSec VPN 의 설정을 완료하게되면 5분정도 안에 터널상태가 UP 으로 변경됩니다.

 

*** 주의할 점

NCP 의 공공기관용 콘솔은 SECUI 라는 벤더사가 제공하는 게이트웨이만 사용할 수 있습니다.

하지만 AWS 는 SECUI 벤더사가 제공하는 게이트 웨이를 지원하지않습니다.

그렇기에 NCP <-> AWS IPSec VPN 을 연동하기 위해선 NCP는 공공기관용 콘솔을 사용하면 안됩니다.

 ***

 

이제 각각의 클라우드에서 만든 인스턴스 내부의 서버끼리 통신을 해야하는데 어떤식으로 할 수 있을까요?

이제부턴 NCP 이건 AWS 이건 관계없이 조금의 네트워크 이해도만 있으면 됩니다.

 

 

아래는 NCP, AWS 구분없이 플랫폼대 플랫폼으로 구조도를 그린것입니다.

 

먼저 특정 인스턴스에서 통신하고싶은 인스턴스의 Private IP 로 요청을 보내게됩니다. 그럼 미리 설정한 라우팅테이블을 타게됩니다.

이때, 라우팅테이블에는 "특정 IP 대역으로의 요청이면 게이트웨이를 타게해" 라는 내용이 들어있어야합니다. 그리고 여기서 말하는 특정 IP 대역이란 "상대 인스턴스의 Private IP 를 포함하는 모든 IP 대역"입니다. (=CIDR 값 조절가능)

 

그럼 라우팅테이블에서 게이트웨이를 타고 상대측 게이트웨이로 터널을 거쳐 요청이 전달되게 됩니다. 

그렇게해서 상대 VPC 로 요청이 갔다면 "요청의 목적지 IP"로 이동을 해야하는데 이는 VPC 대역 내의 IP 일것입니다. (그렇게 설정해놨으니까요)

그럼 VPC 내부에서 내가 통신하고자 했던 인스턴스의 사설 IP 로 요청을 했으면 위와 같은 루트를 거쳐 인스턴스를 찾아 가게됩니다.

 

 

추가적으로 해야하는 사항들

  • SiteToSite 의 정적 경로
    • 상대측 GateWay 공인 IP 
    • 상대측 VPC 네트워크 대역
  • Ping 혹은 Http 통신 테스트
    • 방화벽
    • Route Table 확인
      • 터널링이 되고 상태가 Up이 되면 자동으로 라우팅테이블에 추가가 됩니다.
      • 상태가 Up이 되지않으면 라우팅테이블에 추가되지않습니다.
    • 서비스 포트 LISTEN 상태 체크
      • netstat -an | grep LISTEN | grep {원하는 포트}
    • 인스턴스 내부의 설정확인
      • /proc/sys/net/ipv4/icmp/echo_ignore_all 이 0이면 허용, 1이면 차단
    • VPC의 네트워크 ACL
      • 네트워크 ACL 은 서브넷에 유입되는 트래픽과 서브넷으로 부터 나가는 트래픽을 제어합니다. 따라서 "사설 IP 로 통신" 에서 제공한 그림을 참고하였을 때, Ping, Http 관련 트래픽을 허용해야 합니다.
    • Targer 인스턴스의 보안 그룹
      • 네트워크 ACL 과 마찬가지로 Ping, Http 관련 트래픽을 허용합니다.

 

 

 

'Network' 카테고리의 다른 글

[Network] Apache vs Tomcat vs Netty  (0) 2024.11.17
[Network] DMZ 존  (0) 2023.04.09
[Network] URI, URL, URN  (0) 2023.02.15
[Network] HTTP/x.x  (2) 2023.01.22
[Network] 브라우저에 www.naver.com을 입력하면 어떻게 될까?  (0) 2023.01.21

'Network' Related Articles

티스토리툴바