728x90

코로나 바이러스의 두번째 웨이브가 한창입니다. 다행히 오늘(9/3) 기준으로 확진자 수가 200명 밑으로 내려오긴 했지만, 긴장의 끈을 놓기에는 여전히 확진자 수가 많습니다. 많은 기업들이 원격 근무를 진행하고 있고 코로나 바이러스 초기에 각 VPN 회사들이 제공해 주었던 임시 라이센스 등을 잘 활용해 왔습니다. 

비용 지불 여력이 되면 유료 계약으로 라이센스를 추가하는 경우도 있겠지만, 소규모 사업장이나 여력이 되지 않는 곳에서는 다른 옵션을 찾아보는 것도 방법이 되겠습니다. 몇 개의 포스팅으로 나누어 소개할 OpenVPN 은 은근 손이 가긴 하지만 저렴하게 VPN 을 구축하는 방법이 될 수 있습니다.


AWS EC2 - OpenVPN 서버 구축 개요

본 포스팅은 OpenVPN 을 설치하여 사용하는 환경으로 IPv4 와 IPv6 를 모두 제공하는 것을 목표로 합니다. VPN 서버를 어디에 구축하느냐에 따라 달라지는 부분들이 있겠습니다만, 널리 사용되는 AWS 의 EC2 를 OpenVPN 서버로 활용하는 방법을 설명하도록 하겠습니다. 작업 순서는 아래와 같습니다.

  1. AWS 환경 준비
    • IPv6 대역을 갖고 있는 신규 VPC 생성
    • VPC 내에 Public Subnet 생성
    • Gateway 구성 : Internet Gateway / Egress Only Gateway
    • Routing Table 조정
    • IPv6 주소를 갖는 EC2 배포
  2. OpenVPN 설치 및 구성
  3. VPN 접속 시험
  4. 기타
    • 라우팅 조정

OpenVPN 을 IPv4 전용으로 사용하는 경우에는 절차가 조금 더 간단합니다. 하지만, 미래 지향적인 작업을 추구하는 동시에 AWS 환경에서 IPv6 를 어떻게 활성화 하는지 공부해 본다는 관점에서 단계를 따라해 주시면 좋겠습니다 ^^


1-1. IPv6 대역을 갖고 있는 신규 VPC 생성

AWS 콘솔에 접속후 VPC 를 먼저 생성하겠습니다. VPC 생성시 몇 가지 옵션 항목이 나오는데 <IPv6 CIDR Block> 의 두번째 옵션인 "Amazon provided IPv6 CIDR block" 을 선택합니다. 

IPv4 와 달리 IPv6 는 AWS 에서 자동으로 할당하는 대역을 이용하게 되며, 공인 IPv6 주소를 할당 받습니다. 이렇게 되는 이유는? 저도 조금 더 공부를 해보고 포스팅으로 정리해 보도록 하겠습니다. (요약 : 아직 잘 모르겠습니다) 

IPv4 와 IPv6 를 모두 할당하여 VPC 를 생성합니다.
VPC 생성이 잘 되었네요
IPv4 는 지정한대로, IPv6 는 /56 으로 임의 배정되었습니다

 

1-2. VPC 내에 Public Subnet 구성

VPC 가 생성되었으니 이번엔 Public Subnet 을 구성하도록 하겠습니다. 서비스에서 쓸 서버들이라면 역할에 맞게 Public, Private Subnet 을 구성해야하지만 OpenVPN 서버는 외부 접근이 필수인 서버이니 Public Subnet 만 구성하도록 하겠습니다.

 

Sunet 생성시 VPC 가 IPv6 를 활성화 해 둔 VPC 가 맞는지 확인하셔야 하구요, 가장 마지막에 있는 <IPv6 CIDR block> 을 "Custom IPv6" 로 선택하여 해당 Subnet 에 할당할 /64 블럭을 입력해 주어야 한다는 정도만 잘 챙기시면 됩니다. 제 경우에는 00 으로 지정을 했습니다.

네~ 역시 잘 생성되었네요

 

Subnet 이 생성되었으면 Subnet 의 속성을 조정해 주어야 합니다. IPv6 를 지원해야 하기 때문에 Subnet 에 생성되는 자원에 IPv6 주소를 자동으로 할당하도록 해보겠습니다. 네, 유심히 보셨다면 아시겠지만 "Public" 이라는 단어가 나오지 않습니다. IPv6 주소 체계는 IPv4 와 묘하게 다른 점들이 있는데, 조금 더 공부하고 포스팅으로...

Subnet 을 선택 > Actions > Modify auto-assign IP settings 를 선택합니다.

자동 할당 정책들 중 가장 마지막에 있는 <Auto-assign IPv6> 의 체크박스를 체크해 줍니다. 이후 해당 Subnet 에 자원이 생성되면 IPv6 주소를 자동으로 할당 받게 되고, Network ACL, Security Group 에 문제가 없다면 할당된 주소로 Public 에서 접근할 수 있게 됩니다. 


여기까지 문제 없으셨나요? 다음 포스팅에서는 인터넷 구간으로의 통신을 위해 필요한 두가지 Gateway 설정을 해보도록 하겠습니다. 하나는 쉘 접근을 위한 Internet Gateway 이고, 다른 하나는 IPv6 터널링시 외부로의 통신에 필요한 Egress Only Internet Gateway 입니다. 왜 두개를 따로 써야 하는지는 다음 포스팅! 에서 말씀 드리겠습니다.

2020.12.25 - 다음 포스팅이 올라왔습니다. 아래의 링크로 고고!

 

AWS EC2 를 이용한 IPv6 지원 OpenVPN 구축 #2

9월에 첫 포스팅을 올리고 시간이 너무 많이 흘렀습니다. 기억이 더 가물가물 해지기 전에 OpenVPN 구축 포스팅을 마무리 해볼까 합니다. 지난 포스팅에서 우리는 `IPv6 대역을 갖고 있는 VPC 생성`

ondemand.tistory.com

Stay tuned..!

 

728x90
728x90

IPv4 의 주소 체계가 더이상 새로운 주소를 사용자들에게 주지 못할거라는 이야기가 나온지 참 오래된 것 같습니다. 마르지 않는 샘처럼 끊임없이 나오는 IPv4 주소 덕분에(?) 생명연장의 꿈을 꾸고 있습니다만 근래 애플(Apple)의 앱 검수 기준 변화는 IPv6 로의 트랜지션이 본격적으로 시작된 것이라는 느낌을 주기에 충분합니다.


IPv4 네트워크가 워낙에 광범위하게 사용되고 있기 때문에 어느날 갑자기 "오늘부터 IPv6 를 써야해!" 하기는 쉽지 않습니다. 때문에 많은 기술 표준과 이를 준수하는 어플라이언스를 통해 점진적인 트랜지션이 일어나고 있습니다. 개발을 하는 사람들은 사실 이걸 신경쓰지 않아도 됩니다만 이왕 세상이 변하고 있는것, 이해가 가는 부분까지 파보기로 했습니다.


NAT 라는 이야기는 많이 들어보셨을 겁니다. Network Address Translation 의 약자로 이 역할을 하는 장비들은 내부 주소(Private IP)를 외부 주소(Public IP)로 바꿔주는 역할을합니다. 당연한 이야기지만 내부 주소는 사적인 네트워크에서만 동작하기 때문입니다. 외부의 다른 인터넷 자원과의 통신을 위해서 주소 체계를 바꾸어 주는 것이지요. 이것을 IPv6 에 대응하여 IPv4 네트워크와 자연스러운 연결을 위해 만든 것이 바로 NAT64 입니다.


IPv6 체계가 퍼블릭 네트워크에 완전히 보급되는 것은 시간도 오래걸리고 어쩌면 불가능 할지도 모릅니다. 떄문에 IPv4, IPv6 는 한동안 혼용될 것입니다. 상대적으로 내부 네트워크는 IPv6 로의 전이가 쉬운 편이라 사내망에서는 이미 IPv6 를 쓰는 곳들이 꽤 많습니다. 내부에서 사용되는 IPv6 만 사용하는 기기들이 외부의 IPv4 로 구성된 기기에 접근하기 위해서 NAT64 를 활용한다고 보시면 되겠습니다. 시스코에서 게시해 둔 아래의 그림을 보면 이해가 빠를겁니다.


출처 : 시스코



IETF 에서는 NAT64 를 위해서 특정한 IPv6 주소를 활용할 수 있도록 규약을 정의해두었습니다. 이 주소를 활용하게 되면 패킷의 헤더 일부분에 실제 접근해야 하는 IPv4 주소를 포함시킬 수 있게 됩니다. NAT64 어플라이언스는 이 주소체계를 식별하여 IPv4 네트워크로 패킷을 전달할 때 목적지 주소로 활용할 수 있게 되는 것이죠. 실제 패킷의 응답을 다시 받아주기 위해서 NAT64 장비는 이 과정에 원본 주소로 활용할 IPv4 Pool 을 유지하면서 응답을 적절한 사용자에게로 리턴해 줄 수 있게 됩니다.


이러한 과정을 소화하기 위해서는 DNS 역시 AAAA 리소스 레코드로 IPv4 주소를 포함한 데이터를 가지고 있어야 하며 이는 다음글에서 DNS64 라는 주제로 살펴보도록 하겠습니다. NAT64 에 대해서 관심이 더 있으시다면 시스코의 아래 링크와 IETF 문서를 읽어보시면 ㄷ움이 되시겠습니다. 


시스코의 NAT64 관련 글 살펴보기 [바로가기]

IETF 의 RFC6146 (Stateful NAT64) 규약 살펴보기 [바로가기]



728x90
728x90

정말 오래전부터 이야기가 되어오던 것이 IPv4 자원의 소진입니다. 논리적으로 0.0.0.0 부터 255.255.255.255 까지의 주소를 갖게 되는 IPv4 는 한정된 IP 갯수로 인해 근래에 폭발적으로 증가하는 인터넷 접속 기기들을 소화하지 못할 것이라는 것이 그 내용입니다. 하지만 할당은 되었으나 사용되지 않는 IP 자원의 재활용과 NAT 등의 기술을 이용하여 사설 IP 를 통해 IP  자원이 절약되면서 상당기간 그 소진이 늦춰져 온것이 사실입니다.


하지만 최근 폭발적으로 증가하는 기기에 대한 이슈로 인해 IPv6 의 적용이 더이상 늦춰져서는 안될 것이라는 것이 많은 전문가들이 내놓는 공통적인 의견입니다. 정말로 이제는 IPv4 가 소진되었다는 이야기도 여기저기서 흘러나옵니다. 다행인것은 이런 분위기에 맞장구라도 치듯 IPv6 를 통한 인터넷 트레픽이 점차 증가하고 있다는 점입니다. 문제는 과연 우리는 IPv6 의 적용을 위하여 무엇을 고민했고 준비해왔냐 하는 것이 아닐까 싶습니다.




아카마이가 제공하고 있는 IPv6 트레픽 현황 페이지에 따르면 지난 3년간 IPv6 를 통해 발생한 인터넷 트레픽은 약 6배 정도 증가한 것으로 나타납니다. 아직까지 IPv4 를 통한 트레픽에는 한참 미치지 못하는 숫자이지만 하루에 IPv4 를 통한 트레픽 대비하여 10% 정도의 수준에 이르렀다는 이야기도 언뜻 기사에서 봤던 것 같습니다. 이제 IPv6 는 기술적이고 이론적인 이야기가 아니라 현실의 이야기가 되어가고 있는 것입니다.




아시아 지역은 상대적으로 북미 등에 비해서 IPv6 에 대한 적용이 낮은 것으로 데이터는 이야기하고 있습니다. 측정 시점에 따라 북미 지역은 5~60만건의 IPv6 요청이 들어오는 반면 아시아 지역에서는 피크일떄도 4만건에 이르지 못할 정도로 규모 자체가 작은 것 같습니다. 물론 북미 지역의 인터넷 트레픽 총량과 아시아 지역의 그것을 비교해봐야 하겠지만 자칫 IPv6 로의 이전이 늦어지면서 이슈가 되지는 않을까 우려되기도 합니다.


IPv6 인터넷 트레픽 현황 보러 가기 [바로가기]

 

728x90

+ Recent posts