VPC보다 VPN(Virtual Private Network) 먼저

회사 내부의 네트워크

VPN은 한국어로 “가상사설망"이라합니다. 앞에 “가상"이라는 단어에서 알 수 있듯 실제 사설망이 아닌 가상의 사설망입니다. 만약 위 그림과같이 회사의 네트워크가 구성되어있고 보안상의 이유로 직원간 네트워크를 분리하고싶다면 기존 인터넷선 선공사도 다시해야하고 건물의 내부선을 다 뜯어고쳐야하며 다시 전용선을 깔아주어야합니다. 이를위해 가상의 망 VPN을 사용하게됩니다.

VPN을 구축한 네트워크

VPN은 네트워크A와 네트워크B가 실제로 같은 네트워크상에 있지만 논리적으로 다른네트워크인것처럼 동작합니다. 이를 우리는 ‘가상사설망'이라고합니다.

VPC(Virtual Private Cloud)

VPC가 없는구조

VPC가 없다면 EC2 인스턴스들이 서로 거미줄처럼 연결되고 인터넷과 연결됩니다. 이런 구조는 시스템의 복잡도를 엄청나게 끌어올릴뿐만 아니라 하나의 인스턴스만 추가되도 모든 인스턴스를 수정해야하는 불편함이 생깁니다. 마치 인터넷 전용선을 다시까는것과 같습니다.

VPC가를 적용한구조

VPC를 적용하면 위 그림과같이 VPC별로 네트워크를 구성할 수 있고 각각의 VPC에따라 다르게 네트워크 설정을 줄 수 있습니다. 또한 각각의 VPC는 완전히 독립된 네트워크처럼 작동하게됩니다.

VPC를 구축하는 과정

VPC를 구축하기위해서는 VPC의 아이피범위를 RFC1918이라는 사설아이피대역에 맞추어 구축해야합니다. 사설아이피란 무엇일까요? 인터넷을 위해 사용하는것이 아닌 우리끼리 사용하는 아이피주소 대역입니다. 예를들어보겠습니다. 누군가 “안방에서 리모컨좀 가져다달라”하면 저는 옆집을 가는게 아닌 우리집에 있는 “안방”으로 찾아갑니다. 안방이 프라이빗아이피(사설아이피) 우리집 주소가 퍼블릭아이피입니다.

옆집도 안방이 있고 우리집도 안방이 있지만 서로 안방을 들었을때 헷갈리지 않습니다. “안방”, “작은방”, “큰방”처럼 내부에서 쓰는 주소를 사설아이피 대역이라고 부르며 내부 네트워크내에서 위치를 찾아갈때 사용합니다. 물론 내 친구나 혹은 동생의 친구가 찾아올때는 도로명주소(퍼블릭아이피)를 알려주면되고 같은집(우리집)에사는(동일한 네트워크 상 존재하는) 내가 동생하테갈때는 동생방(사설아이피)로 찾아갑니다.

VPC에서 사용하는 사설 아이피 대역은 아래와같습니다.

- 10.0.0.0 ~ 10.255.255.255(10/8 prefix)

- 172.16.0.0 ~ 172.31.255.255(182.16/12 prefix)

- 192.168.0.0 ~ 192.168.255.255(192.168/16 prefix)

한번 설정된 아이피대역은 수정할 수 없으며 각 VPC는 하나의 리전에 종속됩니다. 각각의 VPC는 완전히 독립적이기때문에 만약 VPC간 통신을 원한다면 VPC 피어링 서비스를 고려해볼 수 있습니다.

서브넷

VPC를 만들었다면 이제 서브넷을 만들 수 있습니다. 서브넷은 VPC를 잘개 쪼개는 과정입니다. 서브넷은 VPC안에 있는 VPC보다 더 작은단위이기때문에 연히 서브넷마스크가 더 높게되고 아이피범위가 더 작은값을 갖게됩니다. 서브넷을 나누는 이유는 더 많은 네트워크망을 만들기 위해서입니다.

각각의 서브넷은 가용영역안에 존재하며 서브넷안에 RDS, EC2와같은 리소스들을 위치시킬 수 있습니다.

라우팅 테이블과 라우터

네트워크 요청이 발생하면 데이터는 우선 라우터로 향하게됩니다. 라우터란 목적지이고 라우팅테이블은 각 목적지에 대한 이정표입니다 데이터는 라우터로 향하게되며 네트워크 요청은 각각 정의된 라우팅테이블에따라 작동합니다. 서브넷A의 라우팅테이블은 172.31.0.0/16 즉 VPC안의 네트워크 범위를 갖는 네트워크 요청은 로컬에서 찾도록 되어있습니다. 하지만 그 이외 외부로 통하는 트래픽을 처리할 수 없습니다.이때 인터넷 게이트웨이를 사용합니다.

인터넷게이트웨이

인터넷게이트웨이는 VPC와 인터넷을 연결해주는 하나의 관문입니다. 서브넷B의 라우팅테이블을 잘보면 0.0.0.0/0으로 정의되어있습니다. 이뜻은 모든 트래픽에 대하여 IGA(인터넷 게이트웨이) A로 향하라는뜻입니다. 라우팅테이블은 가장 먼저 목적지의 주소가 172.31.0.0/16에 매칭되는지를 확인한 후 매칭되지 않는다면 IGA A로 보냅니다.

인터넷과 연결되어있는 서브넷을 퍼블릭서브넷, 인터넷과연결되어있지않는 서브넷을 프라이빗서브넷이라고합니다.

네트워크 ACL과 보안그룹

네트워크 ACL과 보안그룹은 방화벽과 같은 역활을 하며 인바운드 트래픽과 아웃바운드 트래픽 보안정책을 설정할 수 있습니다. 먼저 보안그룹은 Stateful한 방식으로 동작하는 보안그룹은 모든 허용을 차단하도록 기본설정 되어있으며 필요한 설정은 허용해주어야합니다. 또한 네트워크ACL과 다르게 각각의 보안그룹별로도 별도의 트래픽을 설정할 수 있으며 서브넷에도 설정할 수 있지만 각각의 EC2인스턴스에도 적용할 수 있습니다.

네트워크 ACL은 Stateless하게 작동하며 모든 트래픽을 기본설정되어있기때문에 불필요한 트래픽을 막도록 적용해야합니다. 서브넷단위로 적용되며 리소스별로는 설정할 수 없습니다. 네트워크ACL과 보안그룹이 충돌한다면 보안그룹이 더 높은 우선순위를 갖습니다.

NAT 게이트웨이

NAT 게이트웨이는 프라이빗서브넷이 인터넷과 통신하기위한 아웃바운드 인스턴스입니다. 프라이빗 네트워크가 외부에서 요청되는 인바운드는 필요없더라도 인스턴스의 펌웨어나 혹은 주기적인 업데이트가 필요하여 아웃바운드 트래픽만 허용되야할 경우가 있습니다. 이때 퍼블릭 서브넷상에서 동작하는 NAT 게이트웨이는 프라이빗서브넷에서 외부로 요청하는 아웃바운드 트래픽을 받아 인터넷게이트웨이와 연결합니다.

마치며

VPC의 목적은 다양할 수 있지만 일반적으로 보안을위해 AWS 리소스간 허용을 최소화하고 그룹별로 손쉽게 네트워크를 구성하기위해 많이사용합니다.이외에도 독립적인 VPC간 네트워크 통신을 위한 VPC피어링, 기존 사용하는 온프레미스와 VPC를 연결하는 AWS Diarect Connect, VPC에서 발생하는 로그를 기록하는 VPC FLow Logs와같은 서비스가있습니다.

- 출처 : medium.com/harrythegreat/aws-%EA%B0%80%EC%9E%A5%EC%89%BD%EA%B2%8C-vpc-%EA%B0%9C%EB%85%90%EC%9E%A1%EA%B8%B0-71eef95a7098

Harry The Great

#9 11.82 npm ERR! code ENOENT
#9 11.83 npm ERR! path git
#9 11.83 npm ERR! errno -2
#9 11.83 npm ERR! enoent Error while executing:
#9 11.83 npm ERR! enoent undefined ls-remote -h -t ssh://git@github.com/eligrey/FileSaver.js.git
#9 11.83 npm ERR! enoent
#9 11.83 npm ERR! enoent
#9 11.83 npm ERR! enoent This is related to npm not being able to find a file.
#9 11.85
#9 11.85 npm ERR! A complete log of this run can be found in:
#9 11.85 npm ERR!     /root/.npm/_logs/2020-11-10T14_49_13_350Z-debug.log

이거로 한참을 헤매었다.... 아오~

FROM node:14.15-alpine
WORKDIR /app
COPY ["package.json", "package-lock.json*", "npm-shrinkwrap.json*", "./"]
RUN npm install
COPY . .
EXPOSE 3000
CMD ["npm", "start"]

dockerfile이다... 별 문제 없어 보인다. 그러니 저런 에러가 나오면 멘붕이지...

alpine 이미지의 특성인지는 모르겠지만 "git@github.com/eligrey/FileSaver.js.git" 이 repository를 땡겨오는데 문제가 생겼고 path git 이라는 문구도 보인다... 설마설마... alpine에 git이 없나??? (npm install인데 git에서도 땡겨오는지는 몰랐음....)

RUN git --verion을 추가하기에 이르렀다. 예상대로 git 명령어 없음.

RUN npm install 전에 아래 추가하여 git 설치 했더니 문제 없이 docker image가 build되었다.

RUN apk update && apk upgrade && apk add --no-cache bash git openssh

docker build 후에 docker-compose 설정해서 실행하는데 "sh: react-scripts: not found"를 못찾는 상황이 생겼다.

VS code의 docker plug-in을 통해 Dockerfile을 생성했는데 이 부분에서 문제 였다.

RUN npm install -g react-scripts

위처럼 docker container상에는 react-scripts가 설치 되어 있지 않아서 발생한 문제다.

docker-compose 문제가 아니라 dockerfile 문제로 자동 생성한 것은 역시나 꼼꼼히 다시 봐야 겠다는 생각이 들었다.