Cloud Computing On Demand

코로나 바이러스의 두번째 웨이브가 한창입니다. 다행히 오늘(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 주소를 할당 받습니다. 이렇게 되는 이유는? 저도 조금 더 공부를 해보고 포스팅으로 정리해 보도록 하겠습니다. (요약 : 아직 잘 모르겠습니다) 

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 와 묘하게 다른 점들이 있는데, 조금 더 공부하고 포스팅으로...

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

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

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

Stay tuned..!

인터넷을 구성하는 많은 요소들 중 도메인 Domain 은 가장 널리 사용되는 것 중 하나입니다. 도메인은 기억하기 어려운 IP 주소를 사람에게 친숙한 방식으로 제공해주는 기술이지요. 안전한 데이터 교환을 위해 사용되는 HTTPS 와 SSL 인증서 역시 도메인 이름을 적극 사용하고 있습니다. 

도메인 이름에는 보통 알파벳과 숫자, 그리고 몇 가지 기호가 사용되는데요, 오늘은 그 중 알파벳에 대한 이야기를 하고자 합니다. 알파벳은 잘 아시는 것처럼 대문자 Uppercase 와 소문자 Lowercase 로 구분됩니다. 도메인 이름의 규격은 알파벳의 대문자와 소문자 중 어떤 것을 사용하도록 하고 있을까요?

도메인 이름에 관한 규격, RFC 1034

도메인 이름에 대한 규격은 RFC 1034 문서에 기술되어 있습니다. 문서의 제목은 `DOMAIN NAMES - CONCEPTS AND FACILITIES` 로 도메인, 그리고 도메인을 다루는 시스템을 설계할 때 따라야 하는 규격들에 대한 이야기를 하고 있는 문서입니다. 

문서의 초두에 나오는 목적 Goal 절을 읽어보면 도메인 이름의 규격이 왜, 어떻게 정해졌는지를 가늠할 수 있는 내용들이 나옵니다. 그 중에서도 가장 눈에 띄는 것은 역시 영어는 두괄식이다라는 것을 느끼게 해줍니다. 첫번째 문단에 나온 내용은 아래와 같습니다. 

The primary goal is a consistent name space which will be used for referring to resources. (RFC 1034, p2)

DNS 와 도메인을 사용하는 이유는 명확합니다. 네트워크에 연결되어 있는 자원들 중 내가 필요로 하는 리소스를 쉽게, 일관성 있게 찾을 수 있도록 해주기 위함입니다. 이를 위해서 일관된 규칙을 갖는 네임스페이스를 만드는 것이 설계의 목적입니다.

대문자와 소문자를 허용하는 것, 그리고 실제로 그것이 어떤 리소스를 지칭하도록 해야 하는가? 에 대한 답은 이미 여기서 나왔다고 생각합니다. 미국 뉴욕의 엠파이어 스테이트 빌딩을 이야기 할 때, EMPIRE STATE BUILDING 이든 empire state building 이든 상관이 없어야겠죠? (문법적으로 고유명사는.... 과 같은 이야기는 일단 자치합시다!)

대소문자 모두 사용할 수는 있지만 둘은 동일하다!

우리가 궁금해 하는 대소문자 사용에 대한 이야기는 문서의 10 페이지에 언급됩니다. 3.5 절의 뒷 부분에 가면 Note that 으로 시작하는 문장이 나옵니다. 여기서 문서는 도메인을 다루는 시스템에서 도메인 이름은 대소문자를 모두 사용할 수 있다고 이야기 하고 있습니다. 

하지만 중요한 것은 이어지는 문장입니다. "No significance is attached to the case" 대소문자 구분은 별로 의미 없다는 말입니다. 그리고 혹시나 오해가 생길까봐 That is 로 한번 더 확인사살을 해주고 있습니다. 

Two names with the same spelling but different case are to be trated as if identical. (RFC 1034, p10)

즉, 대소문자를 자유롭게 사용할 수 있긴 하지만 동일한 것으로 취급해야 한다는 결론입니다. Stack Overflow 등에 올라오는 글들을 보다 보면 특정한 제품군 등에서는 대소문자를 구분하는 경우도 있고, 브라우저들이 어떻게 핸들링 하는가에 대한 이슈도 있긴 한 것 같습니다. 그렇지만 일단 규격이 이야기 하는 것은 대소문자에 관계 없이 동일한 것으로 취급해야 한다라는 점, 기억해 두시기 바랍니다!

AWS 를 사용하면서 만나는 Global 서비스들이 여럿 있습니다. CDN 제품인 CloudFront 가 가장 대표적인 Global 서비스이고 CF 에서 사용할 수 있는 WAF (Web Application Firewall) 역시 Global 서비스 입니다. 이런 제품들의 특징은 사용자에게 가까운 곳에서 동작해야 효과가 좋다(?)는 점이죠.

최근 WAF 는 Version 2 를 출시하면서 기존의 WAF 는 WAF Classic 으로 부르기 시작했습니다. 몇 가지 변화들이 있지만 그 이야기를 하려는 것은 아니구요, 새로운 버전이 출시되면서 IAM Policy 에도 WAF v2 에 대응하는 부분이 추가되었고 Console 접근을 하려다 보니 생겼던 에피소드를 IAM Policy 를 살펴보면서 간단히 이야기 해볼까 합니다. 

IAM 에서 미리 정의하여 제공되는 Policy 중 WAF 와 관련된 것은 두가지가 있습니다. 하나는 AWSWAFFullAccess 이고 다른 하나는 AWSWAFConsoleFullAccess 입니다. 이들 Policy 를 사용하여 권한을 부여해 두었다면 Action 항목에 "wafv2:*" 가 자동으로 추가, 적용이 되었고 WAFv2 의 사용에 문제가 없어야 합니다. 개별 정책을 JSON 으로 정의했다면 명시적으로 "wafv2" 를 넣어줘야 합니다. 

# Policy : AWSWAFFullAccess

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "waf:*",
        "waf-regional:*",
        "wafv2:*",
        "elasticloadbalancing:SetWebACL",
        "apigateway:SetWebACL"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

문제는 기존 WAF Classic 은 화면 진입은 잘 되면서 에러 메세지가 눈에 안 띄는 곳에 나오면서 콘솔 진입시 위 정책이 충분치 않다는 것을 인지하기가 조금 어려웠습니다. 그런데 WAF v2 에서는 Unauthorized 메세지가 대박 크게 나오면서 마치 wafv2 정책이 제대로 들어가지 않은 것처럼 보이는 제보가 들어왔던 것이지요. 결론을 먼저 말하면 위 정책으로는 WAF Classic 이든 WAFv2 든 제대로 동작하지 않는게 정상입니다. 

# Policy : AWSWAFConsoleFullAccess

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "apigateway:GET",
        "apigateway:SetWebACL",
        "cloudfront:ListDistributions",
        "cloudfront:ListDistributionsByWebACLId",
        "cloudfront:UpdateDistribution",
        "cloudwatch:GetMetricData",
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:ListMetrics",
        "ec2:DescribeRegions",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:SetWebACL",
        "waf-regional:*",
        "waf:*",
        "wafv2:*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

AWSWAFConsoleFullAccess 정책을 살펴보면 AWSWAFFullAccess 에 있는 정책들이 모두 들어가 있습니다. 추가로 WAF 적용의 주된 대상이 되는 API Gateway, CloudFront, ELB 관련한 항목들이 추가된 것이 보이는데요, 이들 정책이 있어야 AWS Console 화면 구성에 필요한 정보들을 가져올 수 있고 화면 접근시 Authorization 에러가 발생하지 않게 되는 것으로 생각됩니다. 한참을 헤메다 요 정책을 그룹에 추가해 주고나서 문제를 해소할 수 있었습니다. 

AWS 를 쓰다보면 IAM 에서 적절하고 충분한 권한을 주는 문제에 종종 부딪히게 됩니다. 적용된 정책을 확인하는 페이지도 제공하고 있긴 하지만 실제로 사용자들이 API 호출이나 Console 액세스시에 겪게 되는 문제와 연결고리를 찾기 힘든 경우도 종종 생깁니다. 결국은 경험치가 있어야 하는 것인가 하는 고민에 빠지게 되는 5월의 어느날입니다. 

[ AWS 자격증을 준비하신다면 - 3만명이 수강한 강의 추천드립니다! ]

[ WAF Classic 과 WAF v2 의 비교는 아래 블로그가 깔끔합니다! ]

본 포스팅은 소정의 수수료를 받을 수 있습니다.