https://www.youtube.com/watch?v=R1UWYQYTPKo&t=925s
위 강의를 듣고 내용에 대해서 필기한 자료 (총 45분 강의 중 28분까지의 필기)
본 강연에서는 VPC개념과 설정 그리고 요구에 맞게 가상 네트워크를 설정할 수 있는 방법에 대해 다루고 있습니다.
AUSG 4기 오거님의 추천으로 강의를 듣게 되었습니다! (+테라폼 스터디)
목차
1.VPC란?
2.인터넷에 연결된 VPC설정
2-1. IP 주소선택
2-2. 서브넷
2-3. 인터넷 경로
2-4. 보안 정책
1. VPC란?
VPC(virtual private cloud)라는 컴포넌트가 왜 중요하냐?
- 리소스를 생성하게 되면 이 리소스를 어디에 위치시켜야되는지 결정해야되는데 이 위치를 결정할 수 있는 기본이 VPC이기 때문
- AWS를 시작하는데 제일 중요한게 VPC이다.
EC2 특정한 가상머신을 생성하게 되면 어디있는지도 모르게 생성되던 시절이 있었다. aws를 사용하는 인스턴스가 이전에는 랜덤하게 위치했으며, 여러 고객의 가상머신이 한 네트워크에 구성되었던 시절이 있었다. -> aws가 VPC 서비스를 2009년 출시함: 다른 고객들과는 완벽하게 격리된 우리만의 네트워크를 구성하고 마치 우리만의 가상 데이터 센터를 사용할 수 있게 되었다.
2. 연습 : 인터넷에 연결된 VPC 설정
총 단계
2-1. ip address 선택
2-2. 서브넷 나누기
2-3. 인터넷으로 연결되는 경로 routing과 internet gateway를 통해 길을 만들어줌
2-4. 방화벽인 보안그룹, NCL을 가지고 접속을 허용하는 조건들을 설정
VPC를 셋업하는, 인터넷에 연결된 VPC를 설정하는 방법을 순차적으로 살펴볼것임.
크게 4가지 단계이다.
1. VPC라고하는 가상의 데이터 센터를 만들기 위해서는 내부적으로 사용할 수 있는 사설망(private ip address)를 결정.
2. ip주소를 선택하고 하나 크게 만든 뒤, 작은 단위의 subnet단위의 boundary를 생성.
3. 인터넷으로 통신할 수 있는 경로인 routing table을 만들어 네트워크를 연결.
4. 길은 만들어놨으나 접속의 허용 여부에 따라 사용자를 차단 연결해야하는 방화벽 설정을 진행.
이렇게 4가지 단계를 가지고 VPC를 설정할 수 있다.
2-1. IP 주소 선택
AWS에서는 ip address를 표현하는 방식을 싸이더(CIDR_Classless Inter-Domain Routing)라고 한다. -> 국제적인 표준
예전에 ip address말할때 A_class,B_class -- 라는 ip address 범위를 얘기했던 클래스 방식이 있는데 이제는 클래스 방식이 아니라 클래스래스 방식인 싸이더 방식을 사용한다.
네트워크) 172.31.0.0/16 --> 16은 masking 값, 2^16=64K개의 IP주소 가능
IPv4 각각 8비트로 되어있는 총 32비트의 주소 체계들을 가지고 있다. 마지막에 /16의 의미는 앞에 있는 16비트는 언제나 고정이고 나머지 뒤에 있는 16비트가 변경가능하다라는 의미. 2^16 -> 총 65536개의 IP address를 가질 수 있는 커다란 네트워크를 정의할 수 있을 때 사이더로 표현을 한다.
=> VPC에서 사용할 사설망을 정의하는데도 싸이더를 사용하지만, 방화벽 설정할때도 싸이더 방식을 사용해 소스와 데스티네이션을 설정하게 된다.
📌꼭!!!!! RFC 1918에 명시되어있는 ip address를 VPC의 private ip address로 쓸것을 권장한다!
특별하게 네트워크를 작은걸 사용할 필요가없다면, 가능하면 /16 masking값을 가지는 커다란 VPC를 놓고 아주 많은 work road를 VPC속에서 운영할 수 있다.
RFC 1918를 강조하는 이유는 VPC는 하나만 동작하는게 아니라 데이터 센터와도 네트워크로 연결할거고, 또다른 서비스의 VPC와도 연결하여 데이터를 private하게 주고받을 수 있는 네트워크를 확장시키는 것을 사용하게 될텐데 연결할 곳의 주소와 내 주소가 겹치게 되면 찾아갈 수 있는 길을 잃어버리기 때문이다.
오버래핑(ip주소 충돌)이 되지않도록 완벽하게 분리된 그런 ip address를 사용하는것이 매우 중요하다.
"RFC 1918"에 명시되어있는것
public하게 인터넷을 사용하는 사용자들끼리 공인 ip address로 통신하는게 아니라 내부적인 용도로 사용하는 private ip address를 사용할때는 이 3가지 싸이더를 사용하라는게 RFC의 표준이다.
3가지 네트워크의 범위안에있는 네트워크를 사용하는 것을 추천함.
왜그러냐면 국내 고객 중 소수의 몇몇 고객들이 낭패를 당하는 경우가 생기기 때문
-> 오래전에 설계된 네트워크인데 RFC 규약을 지키지않은 경우
=> 옛날에는 54.으로 시작되는 ip address를 사용을 안했다 (ip4가 풍부할때는) 그래서 54로 시작되는 네트워크를 private ip address로 썼다 그러나 지금은 54를 public으로 사용하여 지금 영켜버리게 된것이다.
=> 어떤 고객이 회사 내 네트워크에서 AWS에서 운영되고 있는 EC2 instance의 애플리케이션 서버로 접속하려고 할때 웹 브라우져에 dns이름을 넣던지 ip address넣고 치면, 라우팅이 밖으로 안나가고 회사내에서 패킷이 계속 도는 경우가 발생할 수 있다!!!
때문에 이 규약을 꼭 지킬것을 당부함.
2-2. 서브넷
큰 가상의 데이터 센터 내에서 이러한 ip address range를 가지고 사용을 하겠다 결정하면, subnet이라고 작은 공간들을 만들게된다.
AWS는 region내의 복수개의 가용영역(avaliability zone)을 운영하며, 애플리케이션의 가용성을 극대화 할 수 있도록 지원하고 있다.
구체적으로 서울 region에는 ap-northeast-2a,ap-northeast-2c 이라는 두개의 가용영역을 가지고 있다. VPC는 가용영역과 상관없이 region단위로 굉장히 큰 네트워크를 만들 수 있지만! subnet은 가용영역 안에 서브넷을 각각 생성해야된다.
172.31.0.0/16이라고하는 굉장히 큰 네트워크 속에 subnet을 나누게 된다. 예를 들어 masking 값을 24(앞에 있는 24비트는 고정, 8비트는 변함. 2^8=> 256, 256개의 ip address를 사용가능_c class의 네트워크)로 하는 subnet을 만들었을때, 즉 서브넷 별로 서브넷팅을 위와 같이 만들 수 있다. 이때 서브넷이 중복되면 안된다. 서로 찾아가려면 즉 라우팅이 되려면 오버래핑이 되지 않기 위해 중복시키면 안된다.
서브넷을 만들때 VPC를 16으로 만들면, subnet은 여러개의 크기로 만들 수 있다.
굳이 24의 서브넷이 아니라 22, 20으로 만들어도 된다. 그러나 아주 익숙한 단위인 24 서브넷 마스크를 가지는 서브넷을 만드는걸 권장한당.
256개의 ip address라고 했는데 우리가 사용할 수 있는건 251개이다. 왜냐하면 맨 마지막에 있는 1개와 앞에 있는 4개를 AWS가 관리의 목적으로 reserve하기 때문!!!
((255는 broadcast ip(네트워크의 마지막 주소)인데 이것과 네트워크를 나타내는 ip 2개 빠지고 1,2,3을 관리의 목적으로 aws에서 사용한다.))
즉, masking값을 24로 설정했다면 사용할 수 있는 ip는 4부터 253까지 총 251개를 사용할 수 있다.
2-3. 인터넷 경로
subnet을 만들고 나면, 네트워크가 인터넷으로 나갈 수 있는 경로를 만들어야한다.
경로를 만드는걸 route table이라고 칭한다. 이후 라우트 정보를 만들어야한다.
VPC를 만들고 나면 기본적으로 route table이 존재하게 되는데, 하나의 route table을 모든 서브넷에 동일하게 적용시킬 필요가 없다.
왜냐하면 서브넷 별로 우리가 원하는 route table을 설정하게 되면 어떤 서브넷은 인터넷과 통신할수있고 어떤 서브넷을 할 수 없는 환경을 만들 수 있기 때문이다.
management console에 VPC메뉴에 가면 위와 같은 화면을 확인할 수 있다. 아랫부분은 VPC를 만들고나면 확인할 수 있는 화면이다. 우리가 사용하기로 결정한 ip address를 확인할 수 있다. 우리가 사용하는 ip address의 타겟은 local이다.
이는 외부로 패킷을 보내지 말고 내 VPC내로 라우팅을 하라라고 하는 기본적인 설정이다. 그래서 VPC와 서브넷을 만들고 인스턴스를 이곳 저곳에 만들어도 모든 인스턴스는 서로 통실 될 수 있도록 기본적인 routing table이 만들어진다.
내 VPC로 향하는 트래픽은 내 VPC 내에 머물러야한다는 조건이 아래에 있는 라우팅 테이블에 의해 만들어진것이다.
우리가 연습하고 있는건 인터넷과 연결된, 외부로 서비스를 할 수 있는 VPC를 만들려고했다.
데이터센터, 집도 마찬가지이다. 집이라고 하는 폐쇄적인 공간에서 바깥세상으로 나가려면 대문(gate way)을 열고 나가야되는 것 처럼 VPC에서도 internet gate way라는 것을 만들어서 해당 VPC에 연결을 시켜주고 나면! igw라고 하는 id를 가지는 internet gateway가 만들어진다. 특정한 서브넷에 있는 EC2 instance에서 인터넷으로 트래픽을 보내고자할때 경로를 만들어주게끔 라우팅 테이블을 만드는 것이다.
앞에서는 local이라고 하는 내부에서만 패킷을 보낼수있는 라우팅테이블만 있었는데 지금은 아래 하나가 더 생겼다.
0.0.0.0/0 (지구상에 존재하는 모든 네트워크_anywhere) 위에 있는 조건이 아니라 내가 사용하는 이 네트워크 범위가 아닌 다른 네트워크 범위로 패킷을 보내려면 아래의 규칙을 따르게 된다.
igw라고하는 VPC에서 인터넷으로 나가려고하는 관문(internet gate way)로 패킷을 보내고 나면, 우리가 할일은 끝난다. 그다음에는 인터넷에 존재하는 네트워크들이 서로서로 패킷을 주고 받으며 우리가 원하는 곳으로 패킷을 보내기도하고, 고객들은 경로를 통해서 우리의 애플리케이션 서버로 접속을 하게 된다.
VPC로 향하지 않는 모든 패킷을 인터넷으로 보내라고 하는것이 라우팅 테이블의 의미이다!
2-4. 보안 정책
경로를 만든 후 길을 뚫어놓고 모든 통신을 허용하는게 아니라 접속 허용여부에 따라 block을 하는 보안 정책을 만들어야한다!
AWS는 기본적으로 우리가 허용하기 전에 모든것을 불허하는 정책을 기본적으로 가지고 있다.
(방화벽 설정을 하지 않고 EC2 instance를 만들고 그 안에 apache를 띄워서 웹 애플리케이션을 탑재시키고 구동을 시키면 외부에서 절대 접속이 안된다. 꼭 apache 웹 서버로 접속할 수 있는 방화벽 설정을 통해 문을 열어줘야만 서비스가 가능하다!)
네트워크 방화벽 기능은 크게 2가지 이다.
1. Network ACLs(줄여서 NCL_넷클이라고도함)
- 서브넷 단위로 적용 가능: 서브넷 안에 ec2 instance가 200개가 있으면, 그 200개 인스턴스 모두가 서브넷 단위로 적용을 받게 된다.
- NCL은 동작하는 방식이 stateless로 작용함.
- 차례차례 위에서부터 rule을 검사하는데 여기는 all traffic에 대해 all protocol을 허용하라 라고 되어있다. NCL은 기본적으로 VPC를 만들고 나면 모든걸 허용하도록 함.
2. Security groups (우리에게 익숙한 방식)
- 앞에 프론트앤드 서버와 백엔드 서버가 있다고 했을때, 각각의 인스턴스에 본인이 정해놓은 mywebservers라는 security group을 설정,백엔드에는 mybackends라는 security group을 설정 해놓고나면, 우리는 트래픽을 받아오려고 할 것임 때문에 웹서버는 외부에서 들어오는 80, 433 포트로 들어오는 모든 트래픽을 받아드리고 싶을 것임 즉, 백엔드 서버는 다이렉트로 접속을 못하게 하고 유일하게 웹서버에 있는 웹 애플리케이션만 백엔드로 접속을 할 수 있게 열어주고 싶음.
백엔드가 데이터베이스 서버가 될수도있고 우리 애플리케이션 서버가 될수도있다.
- 동작방식이 statefull로 작용
- 모든걸 block하라고 만들어짐. 트래픽을 외부로 보낼수도 받을수도 없게 되어있다.
=> (권장하는 방식)이 방식을 설정하는 방법은 아래와 같음!
mywebservers 앞에 웹 서버 그룹의 할당된 security group의 rule을 보니 TCP HTTP이고 포트는 80, 0.0.0.0/0(anywhere)에서 오는 걸 allow하는 것들을 만들어줌. 그리고 백엔드에서는! sg-82ba7ee6 (갑자기 웹서버 그룹명을...이걸 눈으로 찍어라?...)
mybackends의 rule은 TCP 2345 포트로 접속을 허용하는데 소스가 sg-82ba7ee6이다. 근데 이건 웹서버에 할당된 security grou이름이다.
"Source를 Security group으로 사용하는 이유"
소스를 굳이 ip address로 명시해도 되지만 security group이 할당된 웹서버가 추가되었을때 security group을 자동으로 붙여주게 되면, 해당 security group이 붙여져있는 서버로부터 오는 모든 트래픽, 내지는 2345 트래픽으로 명시할 수 있다.-> 단단하게 방화벽 설정을 할 수 있다.원하는 곳에서 원하는 포트에서 들어오는 트래픽만 허용가능
(aws의 장점! 트래픽이 늘어나면 auto scaling이 되면서 서버가 쫙 늘어났다가 줄어든다. 서버가 하나가 추가되면 security group도 추가 삭제하며 ip address를 일일히 지정해야 하는 어려움이 있는데, aws는 auto scaling되어 이런걸 일일히 지정할 필요가 없다.)
mywebservers security group에서 속한 instance만 이 security group으로 접속이 가능하다라는 rule을 만들어준것!
Stateless (Network ACL-AWS에서 제공하는 Stateless 방화벽 서비스)
상태를 기억하지 않고 들어올때 나갈때 모두 열어줘야한다. 나가야할때 열어주는게 딱 정해진 포트만 열어줄수가 없다.
서버는 80,22, 3306 등 알려져있는 포트를 쓰지만 client는 ephemeral port라고 하는 os마다 다양한 port range를 사용한다.
통상적으로 1024 이하의 포트를 Well-Known-Ports라고 하여 서비스하는 daemon들이 사용하는 포트이고 1025번 부터는 client들이 주로 사용한다. 1025~65536 포트까지를 랜덤하게 사용하기 때문에 그 포트로 나가는걸 일반적으로 열어주게끔 network ACL을 설정해준다. 즉 들어오는 것과 나가는것을 동시에 설정해주지 않으면, 통신을 하지 못하는게 Stateless방화벽이다!
Statefull (Security groups)
강사님이 웹서버이고 앞에 있는 사람들이 웹서버에 접속하려는 수많은 클라이언트라고 하자.
inbound traffic 즉 80포트를 열어주면 사람들이 접속할 것임. Statefull 방화벽은 들어올때 connection을 그대로 기억 한 뒤 웹 서버가 processing을 해서 client에게 reponse를 그 채널로 보낼때, 나갈때는 들어올때 허용했기 때문에 나갈때도 그냥 허용해줄게! 하는 방식이라서 inbound rule만 설정해주면 된다.
체크 포인트
security group에 대한 2가지 권고 사항
- 필요없는 security group는 열어놓지 말자. 보안에 있어서 가장 중요한건 least privilege!!! 권한을 최소화하자.
예) 22번 포트, SSH 포트를 가지고 remote해서 관리를 하려고하는 목적으로 방화벽을 열어두면 source address를 우리 회사에 있는 관리자의 ip만 열어놓으면 되는거지, 모든 인터넷에 있는 모든 곳에서부터 22번 포트를 열어놓을 필요는 없다!
- VPC가 있기 전에는 inbound traffic 설정만 할 수 있었는데, VPC에서는 security group이 인바운드/아웃바운드, egress/ingress에 대한 security group을 따로따로 설정할 수 있기 때문에 우리가 원하는 형태의 보안 설정을 할 수 있다!
'STUDY > Cloud' 카테고리의 다른 글
[클라우드_강의] 2️⃣가상 데이터 센터 만들기_VPC연결 옵션 (0) | 2021.09.09 |
---|---|
[클라우드] 그림으로 배우는 클라우드 인프라와 API의 구조_5,6장 (0) | 2021.08.31 |