1.
오픈스택 세팅
오픈스택은 온프레미스 프라이빗 클라우드에서 많이 사용된다. 메가존에서는 많이 사용안함
스펙을 낮출 것이다. 크게 잡았더니 호스트 자원과 문제가 생겼다. 현재 메모리 10GB, CPU 6이다
클릭하면 세팅창이 뜬다
Memory 8GiB와 Processors 4개로 설정한다
Openstack_Yoga 가상머신 Poweron. 부팅 오래 걸림
서버가 켜지면 아이디 root 비밀번호 asd
ip a // 오픈스택의 ip를 확인한다 192.168.1.88
URL창에 ip를 입력하고 오픈스택에 admin으로 로그인한다
정상적으로 접속이 되었다
AWS 세팅
Auto Scaling 그룹으로 인스턴스 만들기
Auto Scaling 원하는 용량과 최소 용량을 '2'로 설정해준다
이제 Auto Scaling 그룹이 최소 용량 2개에 따라 인스턴스를 2개 생성되고 대상 그룹에 추가된다
생성된 인스턴스에 wp01 wp02 태그를 달아준다
접속테스트. https://blog.changhoon.shop/ 접속이 잘 된다.
NAT Instance와 bastion host도 Poweron
Auto Scaling 정책과 Cloudwatch 연동되었는지 확인
rds 켜져있는지 확인
2.
Site-to-Site VPN (S2S)
Site-to-Site를 연결하는 데에 ipsec vpn이 이용된다.
VPC gateway - VPN Connection (터널링) - Customer Gateway
키를 이용해 오고가는 데이터를 암호화한다.
터널링 : 외부에서 들어오는 접속을 차단하고 데이터를 암호화하여 보호하는 기술. 가용성을 위해서 터널을 2개 만든다 캡슐화라는 프로세스를 통해 공용 네트워크를 통해 개인 네트워크 통신을 보낼 수 있다
고객 게이터웨이(CGW) 만들기
- 고객 게이트웨이 디바이스는 온프레미스 네트워크(Site-to-Site VPN 연결의 사용자 측)에서 사용자가 소유하거나 관리하는 물리적 또는 소프트웨어 어플라이언스입니다.
- 사용자 또는 네트워크 관리자가 Site-to-Site VPN 연결에서 작동하도록 디바이스를 구성해야 합니다
VPC 콘솔에서 가상 사설 네트워크(VPN) - 고객 게이트웨이(Customer Gateway)
고객 게이트웨이 이름 'my-cgw'
IP 주소 '106.253.56.124' // 송파 강의장의 퍼블릭 IP를 넣어줘야한다. '내 IP'로 알 수 있다.
가상 프라이빗 게이트웨이 만들기(VGW)
- 가상 프라이빗 게이트웨이는 Site-to-Site VPN 연결의 Amazon 측에 있는 VPN 집선기입니다.
- 가상 프라이빗 게이트웨이를 생성하여 Site-to-Site VPN 연결에 사용하려는 VPC에 연결합니다.
VPC 콘솔에서 가상 사설 네트워크(VPN) - 가상 프라이빗 게이트웨이(Gateway)
가상 프라이빗 게이트웨이 이름 'my-vgw'
생성한 가상 프라이빗 게이트웨이를 VPC에 Attached 되야한다. 현재 상태는 Detached
사용 가능한 VPC 'my-vpc' - VPC에 연결
Attaching이 되면 Site-to-Site VPN 연결을 한다
Site-to-Site VPN 연결
VPC 콘솔에서 가상 사설 네트워크(VPN) - Site-to-Site VPN 연결
VPN 연결 이름 'my-s2s'
대상 게이트웨이 유형 '가상 프라이빗 게이트웨이' // Site-to-Site 연결을 위한 기존 가상 프라이빗 게이트웨이 또는 Transit gateway를 선택
가상 프라이빗 게이트웨이 'my-vgw'
고객 게이트웨이 '기존' // 고객 게이트웨이는 고객 게이트웨이 디바이스 또는 소프트웨어 애플리케이션에 대한 정보를 AWS에 제공한다다
고객 게이트웨이 ID 'my-cgw'
라우팅 옵션 '정적' // 고객 게이트웨이 디바이스가 경계 경로 프로토콜(BGP)을 지원하는 경우 Site-to-Site VPN 연결을 구성할 때 동적 라우팅을 지정한다. 고객 게이트웨이 디바이스가 BGP를 지원하지 않는 경우 정적 라우팅을 지정한다.
고정 IP 접두사 '192.168.0.0/21' // 고객사의 프라이빗 IP (송파 강의실 공유기 IP)
VPN 연결을 생성하면 AWS에서 자동으로 2개의 터널을 뚫어준다
3.
고객 게이트웨이를 기반으로 다운로드할 샘플 구성을 선택한다.
공급 업체 'Openswan' // 소프트웨어적인 소프트웨어를 사용한다.
IKE : Internet Key Exchange를 뜻함
다운로드를 클릭하면 AWS가 오픈스택이 세팅해야할 내용을 다운로드받았다.
고객사쪽(오픈스택)에서 이 내용으로 세팅해야하는 문서.
오픈스택 환경 세팅
현재 네트워크 토폴로지에 external-network밖에 없다.
예전 수업에 생성했던 것들을 지우고 새로 환경을 세팅한다
내부 네트워크 만들기
네트워크 이름 'internal-network'
서브넷 이름 'internal-subnet'
네트워크 주소 '10.20.0.0/24' // my-vpc와 ip범위가 달라야함.
게이트웨이 IP '10.20.0.1'
'DHCP 사용' 체크
DNS 네임 서버 '8.8.8.8' '8.8.4.4'
라우터 만들기
라우터 이름 'router'
외부 네트워크 'external-network'
인터페이스 추가 - 서브넷 'internal-network'
보안그룹 만들기
이름 'open-sg-db'
SSH, MYSQL, ALL ICMP 규칙을 추가한다
Floating IP 만들기
Pool 'external-network'
3번 반복해서 총 3개를 만든다
external-network 핑 테스트하기
핑이 잘 나간다
전에 만들었던 인스턴스 삭제
Flavor은 예전에 만들었던 m1.micro를 사용한다
이미지는 Ubuntu를 사용할 것이다
볼륨 정리하기
키페어 생성
키 페어 이름 'open-key'
키 유형 'SSH키'
키 페어를 생성하면 open-key.pem 파일이 다운로드된다
인스턴스 생성
인스턴스 이름 'dbserver'
볼륨 크기 '10'
이미지 'unbuntu18'
인스턴스 유형(Flavor) 'm1.micro'
네트워크 'internal-network'
보안 그룹 'open-sg-db'
MobaXterm에서 Openstack_Yoga 접속
스크립트를 실행하기 전에 패키지를 설치해야한다
yum install -y libreswan
systemctl enable --now ipsec // libreswan의 서비스 이름이 ipsec
이제 스크립트 순서에 따라서 명령을 수행한다
1.
vi /etc/sysctl.conf
net.ipv4.ip_forward = 1 // 이미 입력되어있다
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0
2.
sysctl -p // 잘 세팅되었는지 확인
3.
cat /etc/ipsec.conf
include /etc/ipsec.d/*.conf // #을 지워야하는데 이미 지워져있다. conf라는 파일을 읽어서 구성 파일로 활용한다는 설정
4.
vi /etc/ipsec.d/aws.conf // aws.conf를 만든다. conn Tennel 터널 2개를 만들어서 연결되도록 설정한다. 가용성을 위함
conn Tunnel1
authby=secret
auto=start
left=%defaultroute
leftid=106.253.56.124 // 우리 강의실(custom)을 뜻함. 강의장에서 실행한다면 IP를 수정할 필요 없다
right=3.37.97.159 // AWS를 뜻함. 강의실 사용자마다 다름
type=tunnel
ikelifetime=8h
keylife=1h
phase2alg=aes128-sha1;modp1024
ike=aes128-sha1;modp1024
auth=esp // 얘 지워야함
keyingtries=%forever
keyexchange=ike
leftsubnet=192.168.0.0/21 // 오픈스택의 프라이빗은 2가지다(192와 10). <LOCAL NETWORK>를 192.168.0.0/21
rightsubnet=10.40.0.0/16 // AWS의 my-vpc 대역. <REMOTE NETWORK>를 10.40.0.0/16 로 수정
dpddelay=10
dpdtimeout=30
dpdaction=restart_by_peer
overlapip=yes // 얘를 추가했다
conn Tunnel2 // 두번째 터널을 설정한다. 터널 1과 right 부분(AWS)만 달라진다
authby=secret
auto=start
left=%defaultroute
leftid=106.253.56.124
right=13.125.89.234 // 터널1과 유일하게 다른 부분
type=tunnel
ikelifetime=8h
keylife=1h
phase2alg=aes128-sha1;modp1024
ike=aes128-sha1;modp1024
keyingtries=%forever
keyexchange=ike
leftsubnet=192.168.0.0/21
rightsubnet=10.40.0.0/16
dpddelay=10
dpdtimeout=30
dpdaction=restart_by_peer
overlapip=yes
4.
5.
vi /etc/ipsec.d/aws.secrets // 키를 만들어야한다
106.253.56.124 3.37.97.159: PSK "o1xeL2epkiZZmBYXnry9jSC2z1z4WM.H" // 첫 번째 터널의 키. 강의실과 AWS를 오갈때 데이터를 보호할 키를 만들어주고 연결을 해준다. 이 키를 가지고 연결을 해준다
106.253.56.124 13.125.89.234: PSK "7oq7xkI3yQR.JS1uO78WPDqb4a5Ctu2u" // 두 번째 터널의 키
6.
systemctl restart ipsec // 오픈소스로 소프트웨어 VPN이 가능하도록 하는 프로토콜
systemctl status ipsec
오픈스택 인스턴스 콘솔로 잘떠있는지 확인하기
잘떠있다
인스턴스와 Floating IP 연결
아무거나 하나 선택하면됨
인스턴스 핑 테스트하기. 잘나간다
라우터 정적 경로 추가하기 // 오픈스택의 라우팅 테이블을 세팅한다. 오픈스택 dbserver가 AWS my-vpc에 있는 EC2로 가는 길을 세팅해준다
대상 CIDR '10.40.0.0/16' // AWS의 my-vpc IP
다음 홉 '192.168.1.88' // Openstack Yoga의 IP. 오픈스택에 libreswan을 설치했기 때문에 길을 알려준다
오픈스택 인스턴스dbserver MobaXterm에 접속
AWS my-vpc에 있는 인스턴스에게 핑 테스트 해보기
현재 핑이 안나간다. 현재 라우팅 정보가 오픈스택에 있는데 AWS에는 라우팅 정보가 없기 때문
AWS 라우팅 테이블을 편집
송파 강의장 IP 192.168.0.0/21로 가는 길을 가상 프라이빗 게이트웨이에게 물어본다
systemctl restart ipsec // 라우팅 정보를 업데이트했기 때문에 오픈스택 MobaXterm 세션에서 ipsec을 restart해준다
5.
오픈스택 MobaXterm 세션에서
iptables -F // 오픈스택에는 iptables 방화벽이 있다. -F 명령을 통해서 iptables 방화벽 기능을 정리한다
ping 10.40.70.24 // 다시 우분투 세션에서 AWS 인스턴스의 프라이빗 IP로 핑을 치면 핑이 나간다
현재 my-pvt-rtb에만 통신이 된다.
퍼블릭 서브넷의 라우팅 테이블을 세팅하면
대상(목적지) '192.168.0.0/21' - 대상(타겟) '가상 프라이빗 게이트웨이' // 강의장 라우터를 목적지로 하면 가상 프라이빗 게이트웨이가 길을 알려준다
오픈스택 우분투 서버에 마리아DB설치
sudo apt-get update -y
GSLB
Route53의 지리적 라우팅 기능 : 사용자의 리전에 가까운 쪽의 로드밸런서로 라우팅해준다.
같은 도메인을 가지고 있는데 서울 사람은 서울 서버로, 상파울루 사람은 상파울루 서버로 라우팅한다
상파울루 리전에 인스턴스 만들기
인스턴스 이름 'web01'
이미지 'Amazon Linux 2 AMI'
키 페어 생성
키페어 이름 'paulo-key'
'키 페어 생성' 클릭하면 paulo-key.pem 파일이 다운로드된다
#!/bin/bash
yum install -y httpd
systemctl enable --now httpd
echo "<h1>web01</h1>" > /var/www/html/index.html
web01 접속 테스트
web02 인스턴스 만들기
web02 접속테스트
상파울루 리전에 ALB 만들기
로드밸런서 이름 'paulo-alb'
보안 그룹 'paulo-sg-web' // 편의상 웹 보안그룹과 같이 쓴다
대상그룹 생성
paulo-tg-alb
포트번호를 열기 위해 보안 그룹 편집
로드밸런서 접속테스트. 로드밸런서 DNS 이름을 복사하고 테스트. web01 web02가 번갈아서 뜬다
Route53 레코드 만들기
레코드 이름 'geo'
트래픽 라우팅 대상 'ALB' - '아시아 태평양(서울)' - 'my-alb-asg-wp'
라우팅 정책 '지리적 위치' - 위치 '아시아' // 지리적으로 가까운 로드밸런서로 포워딩해준다. 가중치 기반은 따라 가중치를 줄 수 있다
라우팅 정책 선택
라우팅 정책을 사용하면 Route 53이 트래픽을 리소스로 라우팅하는 방식을 선택할 수 있습니다. 동일한 작업을 수행하는 리소스가 여러 개 있는 경우(예: 웹사이트의 콘텐츠 제공) 단순 이외의 라우팅 정책을 선택합니다. 다음은 간단한 비교입니다.
- 단순: 단순 레코드는 표준 DNS 기능을 사용합니다.
- 가중치: 가중치 적용 레코드를 사용하면 각 리소스로 보낼 트래픽 부분을 지정할 수 있습니다. 가중치가 높은 곳에 더 많이 포워딩한다
- 지리적 위치: 지리적 위치 레코드를 사용하면 사용자의 지리적 위치에 따라 트래픽을 리소스로 라우팅할 수 있습니다.
- Latency(지연 시간): 지연 시간 레코드를 사용하면 지연 시간이 가장 짧은 AWS 리전의 리소스로 트래픽을 라우팅할 수 있습니다. 모든 리소스는 AWS 리전에 있어야 합니다.
- IP 기반: IP 기반 레코드를 사용하면 알고 있는 IP 주소를 기반으로 트래픽을 리소스로 라우팅할 수 있습니다.
- 장애 조치: 한쪽 서버가 죽으면 다른 서버로 넘겨주는 Failover 정책. 장애 조치 레코드는 특정 리소스가 정상일 경우 해당 리소스로 트래픽을 라우팅하고 첫 번째 리소스가 비정상일 경우 다른 리소스로 트래픽을 라우팅합니다.
- 다중 응답: 다중 응답 레코드를 사용하면 Route 53이 DNS 쿼리에 대해 다수의 값(예: 웹 서버의 IP 주소)을 반환하도록 구성할 수 있습니다.
레코드 ID 'seoul' // 식별자
'다른 레코드 추가'를 통해 상파울루 리전도 추가해준다
레코드 이름 'geo'
트래픽 라우팅 대상 'ALB' - '아시아 태평양(서울)' - 'my-alb-asg-wp'
라우팅 정책 '지리적 위치' - 위치 '남아메리카'
레코드 ID 'paulo'
레코드를 생성하면 동시에 2개의 레코드가 생긴다
geo.changhoon.shop 접속테스트를 하면 여기는 서울이라서 상파울루의 웹페이지를 확인할 수 없다.
상파울루에서 접속테스트 해보기
curl geo.changhoon.shop // 상파울루 리전에서는 web01 web02가 번갈아 뜨는 것을 확인할 수 있다
6.
7.
8.
마무리
상파울루 리전에 인스턴스 종료
상파울루 로드밸런서 삭제
상파울루 대상그룹 삭제
상파울루 보안 삭제
상파울루 키 페어 삭제
VPC 지우기
Site-to-Site VPN 지우기
고객 게이트웨이 지우기
가상 프라이빗 게이트웨이 분리
가상 프라이빗 게이트웨이 삭제
가상 프라이빗 게이트웨이 분리
Detached가 되면 지운다
라우팅 테이블 정리
pvt-rtb가 블랙홀되었다
my-pub-rtb 도 지워준다
rds 일시중지
CloudWatch 경보 지우기
Auto Scaling 그룹 용량 수정
인스턴스 정리
wp01 wp02 Sample 인스턴스 종료(삭제)
bastion host, NAT Instance 중지
Route53 A레코드 지우기
댓글