728x90

서버의 환경을 해치지 않으면서
이미지로 공급되는 어플리케이션간의 통신을 
구현해야 하는 경우가 많이 있습니다. 

외부로 노출은 nginx로 제한하고
실제 각 어플리케이션 접근을
nginx의 location 지시자를 이용하는 경우가 
대표적인 시나리오입니다. 

사용자에 대한 노출은 nginx endpoint 만하고 싶다면?

docker-compose로 다수 컨테이너 구동하기

이 구성을 위해서는 docker-compose를 이용해서 
복수의 컨테이너를 하나의 설정으로 만들어
컨테이너를 배포하는 것이 눈에 잘 들어오고 편리합니다. 

속도 측정을 위한 오픈소스 어플리케이션인
librespeed를 별도의 컨테이너로 띄워두고
nginx도 별도로 구동하기 위해서는 
다음과 같은 설정을 활용할 수 있습니다. 

version: "2"
services:
  nginx:
    container_name: nginx-test
    image: nginx
    ports:
    - 443:443
  speedtest:
    container_name: speedtest
    image: adolfintel/speedtest
    environment:
    - MODE=standalone
    ports:
    - 80:80

nginx의 설정파일은 아래와 같습니다.

upstream speedtest {
    server speedtest:80;
}

server {
    listen      443 ssl;
    server_name example.com;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    ssl_certificate /etc/nginx/cert/fullchain.crt;
    ssl_certificate_key /etc/nginx/cert/private.key;

    access_log  /var/log/nginx/access.log main;
    error_log /var/log/nginx/error.log debug;

    location / {
        proxy_pass http://speedtest;
    }
}

컨테이너가 잘 뜰까요? 그렇지 않습니다. 
nginx는 speedtest 이름을 찾을 수 없어서 
업스트림 호스트를 찾을 수 없다는 에러를 뿜습니다.

2022/06/18 03:16:21 [emerg] 1#1: host not found in upstream "speedtest:80" in /etc/nginx/conf.d/default.conf:7
2022/06/18 03:20:00 [emerg] 1#1: host not found in upstream "speedtest:80" in /etc/nginx/conf.d/default.conf:7
2022/06/18 03:34:04 [emerg] 1#1: host not found in upstream "speedtest:80" in /etc/nginx/conf.d/default.conf:7

docker-compose 파일을 수정하여 
별도의 bridge 네트워크를 만들어
두 컨테이너가 서로 통신하도록 해보겠습니다. 

docker bridge 네트워크 구성하기

docker는 다양한 네트워크를 구성을 제공합니다. 
그 중에서 우리의 요건에 맞는 것은 bridge 네트워크입니다. 
말그대로 다리처럼 컨테이너들이 소통할 수 있는 구조입니다. 

네, 그렇다고 합니다 (출처 : https://docs.docker.com/network/bridge/)

앞서 만들었던 docker-compose 파일에 
아래와 같이 network 설정을 추가했습니다. 

version: "2"
services:
  nginx:
    container_name: nginx-test
    image: nginx
    ports:
    - 443:443
    networks:
    - backbone
  speedtest:
    container_name: speedtest
    image: adolfintel/speedtest
    environment:
    - MODE=standalone
    networks:
    - backbone
    ports:
    - 80:80
networks:
  backbone:
    driver: bridge

이번엔 잘 될까요?
설레는 마음으로 sudo docker-compose up을 해봤습니다. 
그리고 브라우저에서 도메인에 접속해보니...

떴다!

 

네, 다행히 기대한 대로 잘 동작했습니다. 
nginx 설정에서도 업스트림 서버 이름으로 
컨테이너 이름을 사용할 수 있어서 편리합니다.
컨테이너간 통신, 어렵지 않네요!

728x90
728x90

두 번의 포스팅을 통해 VPC 와 Gateway 를 생성했습니다. 그럼 EC2 를 바로 만들면 되나요? 라고 생각하실 수 있겠습니다만 일단은 생성한 VPC 가 Gateway 를 통해 인터넷과 교감을 할 수 있도록 라우팅 테이블 Routing Table 을 설정하는 작업을 먼저 진행해 보겠습니다. 사실 순서는 큰 상관이 없지만 <네트워크에 대한 작업> 을 마무리하고 <서버에 대한 작업>을 한다고 생각하시면 좋겠습니다. 

 

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

코로나 바이러스의 두번째 웨이브가 한창입니다. 다행히 오늘(9/3) 기준으로 확진자 수가 200명 밑으로 내려오긴 했지만, 긴장의 끈을 놓기에는 여전히 확진자 수가 많습니다. 많은 기업들이 원격

ondemand.tistory.com

 

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

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

ondemand.tistory.com


1.4 Routing Table 조정

라우팅 테이블 Routing Table 은 VPC 로 들어오는 트래픽과 나가는 트래픽에 대한 경로를 지정해 주는 역할을 합니다. 물론 라우팅 테이블만 설정했다고 하여 모든 통신이 정상적으로 이루어지는 것은 아닙니다. 말 그대로 경로에 대한 지정일 뿐, 실제 트래픽을 허용할 것인지는 Network ACL 과 Security Group 을 통해 IP 주소 대역, 포트 단위로 결정됩니다.

VPC 하위의 Route Tables 메뉴입니다

라우팅 테이블을 설정하기 위해서는 VPC 제품 하위 메뉴에 위치한 <Route Tables> 를 통해 진행할 수 있습니다. 기본적으로 VPC 가 생성되면 VPC 에 대한 기본 라우팅 테이블이 자동으로 생성됩니다. 기본 라우팅 테이블은 VPC 에 할당된 IPv4, IPv6 주소를 대상으로 VPC 내에서 (=local) 통신이 가능하도록 하는 정책만 들어 있는 상태입니다.

우리가 해야하는 일은 위 이미지의 핑크색 상자에 들어 있는 내용과 같이 외부로 부터의 트래픽 송수신을 위한 정책을 추가하는 것입니다. IGW (Internet Gateway) 로는 SSH 접근을 위해 IPv4 에 대한 정책을 추가했고, EIGW (Egress Only Internet Gateway) 에는 실제 v6 주소 목적지에 대한 VPN 터널링을 위해 IPv6 주소에 대한 정책을 추가했습니다.

정책 추가를 위해 라우팅 테이블 목록에서 IPv6 용으로 만든 VPC 에 할당된 기본 라우팅 테이블을 선택합니다. Actions 버튼을 누르지 않아도 화면 아랫쪽에서 <Routes> 탭을 선택하면 라우팅 테이블에 대한 상세 정책 목록이 출력됩니다. 정책 추가를 위해 <Edit routes> 버튼을 누르겠습니다. 

IPv4 의 모든 주소를 나타내는 CIDR block 은 0.0.0.0/0 으로 표기되며, IPv6 의 모든 주소를 나타내는 CIDR block 은 ::/0 으로 표기합니다. 목적지 주소에 v4, v6 에 대한 CIDR block 을 추가하고 v4 는 IGW 로, v6 는 EIGW 를 이용하도록 대상(Target) 제품을 지정해 줍니다. 이미 생성한 IGW 와 EIGW 가 드롭 다운 목록에 노출되기 때문에 설정은 쉽게 하실 수 있습니다. 경로 입력이 끝나면 우측 하단의 <Save Routes> 버튼을 누릅니다. 

라우팅 테이블 업데이트가 완료되었습니다!

 

1.5 IPv6 주소를 갖는 EC2 인스턴스 배포

네트워크의 구성이 끝났으니 이제 실제 OpenVPN 바이너리가 구동되고 목적이 v6 주소까지 터널링을 해줄 EC2 인스턴스를 생성해 보도록 하겠습니다. 사용자가 얼마나 많은지, 트래픽 규모가 어떠한지에 따라 인스턴스 타입이 결정되어야 하겠지만, 이 포스팅에서는 AWS 무료 티어에서도 사용할 수 있는 t2.micro 타입의 인스턴스를 사용하도록 하겠습니다. 소규모의 사용량이라면 이 인스턴스로도 큰 문제가 없습니다. 

EC2 인스턴스의 생성은 많이들 해보셨을 작업이기 때문에 주의할 점을 중심으로 설명드리겠습니다. EC2 생성 마법사의 세번째 단계에는 IP 주소 할당에 대한 정책을 선택하도록 되어 있습니다. 우리가 진행하는 OpenVPN 은 단일 인스턴스 환경이기 때문에, 해당 서버가 사용자들로부터 IPv4 를 통해 VPN 연결을 시도할 수 있어야 하고, IPv6 주소를 보유하여 v6 주소를 갖고 있는 목적지 서버와 연결할 수 있어야 합니다. 

 

이 목적을 달성하기 위해서는 <3. Configure Instance> 단계에서 하단에 있는 <Auto-assign Public IP> 와 <Auto-assign IPv6 IP> 를 Enable 로 선택하여 v4 와 v6 를 통해 공인 IP 를 사용할 수 있도록 해야 합니다. 그런데 IPv6 는 왜 <Public> 이라는 말이 없을까요? 기본적으로 IPv6 주소 체계는 Private / Public 를 가지고 있지 않습니다. 따라서 옵션의 이름도 단순히 <Auto-assign IPv6 IP> 라고 되어 있다는 점 참고하시기 바랍니다!

EC2 생성 마법사를 완료하고 인스턴스 생성을 기다립니다. 생성이 완료되면 위와 같은 화면을 볼 수 있게 됩니다. 다른 기본적인 사항은 특별히 확인할 내용이 없고, 네트워킹 Networking 탭을 중심으로 살펴보면 됩니다. 설명했던 것처럼 v4 는 Private, Public 의 주소가 할당되지만 v6 는 하나의 주소만 할당된 것이 보입니다. 이제 인프라의 준비가 끝났습니다. 


 

다음 포스팅에서는 OpenVPN 을 인스턴스에 설치하는 작업을 해보도록 하겠습니다. 

728x90
728x90

9월에 첫 포스팅을 올리고 시간이 너무 많이 흘렀습니다. 기억이 더 가물가물 해지기 전에 OpenVPN 구축 포스팅을 마무리 해볼까 합니다. 지난 포스팅에서 우리는 `IPv6 대역을 갖고 있는 VPC 생성` 을 했고 `VPC 내에 Public Subnet 생성` 까지 완료했습니다. 자세한 내용은 아래 링크를 통해 지난 포스팅을 참고하시기 바랍니다!

 

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

코로나 바이러스의 두번째 웨이브가 한창입니다. 다행히 오늘(9/3) 기준으로 확진자 수가 200명 밑으로 내려오긴 했지만, 긴장의 끈을 놓기에는 여전히 확진자 수가 많습니다. 많은 기업들이 원격

ondemand.tistory.com

 

  • AWS 환경 준비
  • OpenVPN 설치 및 구성
  • VPN 접속 시험
  • 기타
    • 라우팅 조정

1.3. Gateway 구성

1.3.1. Internet Gateway

OpenVPN 을 이용한 IPv6 VPN 구성시 VPC 에는 두개의 Gateway 가 필요합니다. 보통 v4 주소 환경에서 인터넷으로 나가고 들어오는 트래픽 처리를 위해 사용하는 Internet Gateway 가 첫번째 요소입니다. v4 주소라고 명기한 것은 다 이유가 있겠죠? Internet Gateway 는 나가는 트래픽, 즉 아웃바운드 트래픽에 대하여 IPv6 주소를 처리하지 못합니다. 이 때문에 별도로 Egress Only Gateway 를 구성해야 합니다.

정리를 잘 해두기 위하여 위의 내용은 취소선으로만 표기하고 나두었습니다. AWS 에서 제공하는 Gateway 에는 Internet Gateway 와 Egress Only Internet Gateway 가 있습니다. Internet Gateway 는 양방향 (Inbound, Outbound) 의 인터넷 트래픽을 위해 사용하는 구성 요소이고 Egress Only Internet Gateway 는 단방향 (Outbound) 전용 게이트웨이 입니다. 

왜 그렇게 기억하고 있었는지 모르겠지만 OpenVPN 을 통해 실제 IPv6 를 사용하는 서버까지 터널링을 위해서 꼭 Egress Only Internet Gateway 를 사용할 필요는 없습니다. 다만, 각 인스턴스로 IPv6 로 요청이 들어오지 않도록 확실히 분리할 필요가 있다면 IPv6 터널링 용으로 Egress Only Internet Gateway 를 사용하면 됩니다.

Internet Gateway : OpenVPN EC2 인스턴스로 SSH, OpenVPN 접속을 처리하기 위한 목적
Egress Only Internet Gateway : 터널링을 통해 IPv6 목적지로 연결 (EC2 <-> Dest. IPv6 서버) 하기 위한 용도

Internet Gateway 를 생성하기 위해 VPC 제품 페이지에서 Internet Gateway 메뉴로 들어갑니다. 별도의 VPC 를 만들었기 때문에 Default VPC 에 있는 Internet Gateway 를 사용할 수는 없습니다. Internet Gateway 는 VPC 단위로 연결할 수 있다는 것도 기억해 두면 좋겠습니다. 제 경우 구분을 위해 Tag 에 "ipv6" 를 넣어주었습니다.

Internet Gateway 가 생성되면 어떤 VPC 와도 연결되어 있지 않은 상태입니다. 아래의 화면에서 보이는 것처럼 Detached 라는 메세지가 연결된 VPC 가 없다는 것을 알려줍니다. 우측 상단의 "Actions" 버튼을 눌러 앞서 생성한 VPC 에 연결(Attach) 해보도록 하겠습니다. 

State 는 Detached, VPC ID 도 공란입니다. 
Attach to VPC 를 선택합니다.

앞서 가이드 했던 것처럼 VPC 생성시에도 Tag 를 잘 달아두었다면 Attach to VPC 를 하는 과정에 어려움 없이 VPC 를 잘 선택할 수 있습니다. 물론 제 경우 VPC 가 하나라서 Tag 가 있고 없고 상관은 없습니다만 규모가 좀 되는 인프라를 운영중이시면 Tag 가 확실히 도움이 될 겁니다. VPC 를 선택후 <Attach internet gateway> 버튼을 눌러 연결 작업을 마무리 합니다. 

IPv6 용으로 만든 VPC 를 선택합니다

연결 작업이 정상적으로 완료되면 아래와 같은 Summary 화면을 보게 됩니다. 연결한 내용에 이상이 없는지 한 번 살펴보고 지나가시면 됩니다. 

생성한 Internet Gateway 의 State 가 Attached 로 바뀌었습니다.

 

1.3.2. Egress Only Internet Gateway

설명했던 것처럼 VPN 연결은 IPv4 로만 허용하고 터널링은 IPv6 를 쓰기 위해 Egress Only Internet Gateway 를 따로 만들어 보도록 하곘습니다. AWS 의 제품 설명 페이지를 유심히 읽어 보셨다면 아시겠지만 Egress Only Internet Gateway 는 IPv6 전용입니다. IPv4 를 터널링 한다면 Internet Gateway 만 사용하는 것으로 충분합니다. 

VPC 화면의 메뉴중 <Egress Only Internet Gateway> 를 선택합니다. 새로운 Egress Only Internet Gateway 를 아래 화면처럼 생성하도록 하겠습니다. 일반 Internet Gateway 와 특별히 차이가 없기 때문에 Tag 지정만 유의해서 진행하시면 되겠습니다. VPC 목록에도 Tag 가 표시되기 때문에 VPC 생성시 Tag 를 잘 달아두었다면 어려움 없으실 겁니다. 

생성된 Egress Only Internet Gateway 는 eigw 로 시작되는 고유 ID 를 갖게 됩니다. Internet Gateway 의 생성 화면과 달리 생성 할때 이미 VPC 를 지정했기 때문에 별로도 Attach 하는 과정이 나오지는 않습니다. 비슷한 제품인데 담당 조직이 다른지 생성 화면과 절차가 차이가 있네요? Egress Only Internet Gateway 가 훨씬 편한 것 같습니다 ^^


이번 포스팅에서는 두개의 Internet Gateway 를 생성해 보았습니다. 다음 포스팅에서는 VPC 의 라우팅 테이블을 설정하여 OpenVPN 트래픽이 정상적으로 EC2 를 통해 연결되고 터널링 될 수 있도록 해보겠습니다. 

728x90
728x90
인터넷에 연결되어 있는 컴퓨터에 쉽게 접근하기 위해 우리는 DNS 를 사용합니다. DNS 는 사람이 이해할 수 있는 체계로 된 주소를 네트워크가 이해하기 좋은 주소로 바꿔주는 역할을 합니다. 예를들어 www.naver.com 을 DNS 를 통해 조회를 하게 되면 72.247.151.60 과 같은 네트워크 주소를 돌려주게 됩니다. 이 주소를 얻기까지 많은 과정이 있지만 일단 이 포스팅의 주제는 아니므로 넘어가도록 하겠습니다 ^^

 
위의 스크린 샷처럼 1개의 IP 주소가 리턴되는 경우에는 컴퓨터나 웹 브라우저는 고민할 것 없이 해당 IP 주소를 이용해서 자원에 접근하게 될 겁니다. 그런데 만약, 대규모의 사용자 요청을 처리하기 위해서 여러대의 서버와 IP 를 이용하는 경우에는 어떤 주소값을 사용해야 할까요? 가령 아래와 같은 결과가 리턴된다면 컴퓨터나 브라우저는 어떤 IP 주소를 택하게 될까요?

 
 DNS 조회 결과를 활용하는 방법에 대해서도 RFC 표준이 존재하고 있고 IPv6 의 도입등에 따라 표준도 지속적으로 개정이 되고 있습니다. 이 말은, 운영체제에 따라서 DNS 가 A 레코드를 여러개 리턴했을 경우 활용하는 방법이 달라진다는 것을 의미합니다. 가령 윈도우XP 의 경우 굉장히 오래된 운영체제로 리턴된 여러개의 A 레코드 중에서 가장 먼저 리턴된 값을 이용하게 됩니다.

반면 윈도우Vista 라던가 윈도우7과 같은 비교적 근래에 출시된 운영체제들은 개정된 RFC 표준에 맞추어 IP 주소를 선택하게 됩니다. RFC 3484 (http://www.ietf.org/rfc/rfc3484.txt, Default Address Selection for IPv6) 는 IPv6 환경에서 주소를 선택하는 방법에 대한 가이드이지만 많은 운영체제 개발사들은 IPv4 환경에서도 이런 룰을 적용하고 있어서 한 번 읽어볼 필요가 있습니다

 
영어로 가득한 내용이라 울렁울렁 하겠습니다만, 친절한 NoPD 의 요약에 따르면 "프리픽스 부분이 가장 긴 주소를 선택한다" 라고 합니다. 왜 이런 로직을 적용하게 되었는지는 RFC 문서를 직접 읽어보시고 공유해 주시면 감사하겠습니다 ;;; 여튼, 우리가 알아야 할 중요한 내용은 근래의 운영체제들은 이 로직을 대부분 따르고 있다는 사실입니다. 마이크로소프트 테크넷 블로그에 등록된 아래 글이 그 내용을 잘 요약해 주고 있습니다. 역시 친절한 NoPD 의 발췌본을 읽어보시겠습니다 (http://blogs.technet.com/b/networking/archive/2009/04/17/dns-round-robin-and-destination-ip-address-selection.aspx)

 
특정한 도메인에 대하여 5개의 A 레코드가 리턴됐다고 했을때, 사용자의 IP 주소와 비교하여 NetMask 를 몇 비트를 사용해야 하는가가 핵심입니다. 예제는 무척 간단한 상황을 가정해서 쉽게 계산이 됩니다만 실제 상황에서는 조금 더 복잡할 수 있겠죠? IP 주소를 하나 선택하는데 있어서도 영향을 주는 것들이 무척 많습니다. DNS 관련된 이슈를 트러블 슈팅 하실 때 이런 내용도 알고 계시면 도움이 많이 될 것 같아서 공유해 봅니다. 아래의 주소들을 방문해서 보다 자세한 내용을 확인해 보시기 바랍니다.

 
728x90

+ Recent posts