[6.20] 하이브리드 클라우드(AWS와 오픈스택의 연동)

# Route 53

: GSLB: Cross Region, VRRP : 이중화, Fail Over(무중단 서비스) : Active, Passive(=Inactive, Standby) 

 

# Hybrid cloud- AWS의 Storage를 활용하는 방법

AWS <-VPN-> Openstack(on-prem) --> EFS

AWS <-Storage gateway-> ESXI(on-prem) --> S3

---

# GSLB

* 장애 조치 레코드 유형 

-> 기본 : active, 보조 : passive

* 상태 확인 ID

-> 서울의 상태확인 ID가 active이기 때문에  active 상태 확인 ID를 선택

-> 도쿄의 상태확인 ID가 passive이기 때문에 passive 상태 확인 ID를 선택

* 레코드ID : 구분자와 같음, 뒤에 만들 다른 레코드와 구분하기 위해 임의로 정해주기

* gslb.skk2022.shop : 서울과 도쿄가 동일한 도메인의 적용을 받음

 

해당 도메인으로 접속 가능

 

서울 HA-seoul vm을 stop 시키고, gslb.skk2022.shop으로 접속해보기

 

서울 리전 비정상 상태확인 표시

 

서울 리전에 장애가 발생한 상황에도 도쿄 리전으로 연결됨(failover)

 

---

# 오픈스택 라우터 설정

 

정적경로(=라우팅 테이블)

* 대상 CIDR : 상대의 내부 IP

* 다음 홉 : 상대의 네트워크 토폴로지의 외부 IP

* 라우터에게 CIDR(인터널 네트워크)의 경로를 물어보는 것

---

#  VPN Tunneling

 

* VPN Tunneling

-> src와 dst의 IP를 다른 IP로 변조

-> 평문이 아닌 암호환된 데이터를 주고 받음

-> 이를 통해 해커가 데이터를 가로채도 어떤 데이터인지 알 수 없음

 

* Site-to-Site VPN

-> IPsec 프로토콜을 가장 많이 이용

-> openstack이 설치된 CentOS 8 버전에 libreswan 도구를 설치해야 함 (소프트웨어 설치가 필요함)

-> AWS에서는 기본적인 설정만 하면 됨

---

# VGW, VCG를 VPC에 연결 후 VPN 연결 생성

 

 

* 로컬 IPv4 네트워크 CIDR(= 고정 IP 접두사) : AWS의 MY-VPC

* 원격 IPv4 네트워크 CIDR :  AWS MY-VPC의 내부 IP

 

터널 1과 터널 2 옵션은 VGW와 VCW 간의 통신에 보이는 IP

 

VPN 연결 생성됨

* 아직은 on-prem 쪽에서 연결하지 않았기 때문에 VPN tunneling이 되기 전 상태

 

구성 다운로드 : VPN Tunneling을 도와주는 configuration 파일들을 다운로드 받을 수 있음

 

 

* Openswan이 Libreswan의 이전 버전

* Openswan은 CentOS 7버전까지만 사용 가능, CentOS 8 버전부터는 Libreswan

 

 

좌측은 내려 받은 구성 파일, 우측은 강의실에서 배포 받은 파일

* leftid와 leftsubnet : 강의장의 IP와 강의장의 IP 대역을 입력

* right와 rightsubnet : 내려 받은 구성 파일에 자동으로 입력되어 있음

* Tunnel1, Tunnel2 : 터널이 두 개 있음, VGW에서는 IP가 두 개라는 의미, CGW는 강의장의 IP이므로 한 개밖에 없음

 

Tunnel1고 Tunnel2의 PSK

* PSK : Pre Shared Key : VPN 터널링에 접속하기 위한 일종의 패스워드

* Libreswan이 해당 키를 사용이 VPN에 접속하게 됨

 

터널 세부 정보 탭에서 상태가 Up이면 VPN Tunneling 완성된 것, 이제 라우팅 테이블 설정할 차례

 

라우팅 편집

 

RTB에 192.168.0.0/20 대역(오픈스택의 floating IP)으로 트래픽이 발생하면, 넥스트홉(대상)이 가상 프라이빗 게이트웨이(VP Gateway)로 가면 됨

* VP Gateway로 가면 어디로 트래픽을 전송해야할지 알려줌, 이후 MY-PRIVATE-SUBNET의 라우팅도 편집해줘야 함

 

프라이빗 서브넷에서도 192.168.0.0/20(오픈스택의 floating IP) 대역으로 트래픽이 발생하면 VP Gateway로 트래픽을 전송

* 이제 오픈스택의 라우팅 테이블도 설정해줘야 함

 

IPsec 정보를 오픈스택이 가지고 있으니 다음 홉에 오픈스택 IP 넣어줌

* 오픈스택에 Libreswan(VPN 정보가 담겨 있는 소프트웨어)이 설치되어 있으니, 오픈스택의 IP를 넥스트 홉으로 지정

 

오픈스택 세션에서 iptables -F하고 ipsec 재시작 해주기, 이후 ping 통신 잘 됨

* 오픈스택 자체의 IP를 통해 접속한 세션에서 iptables -F, systemctl restart ipsec

* 오픈스택에서 만든 인스턴스에서 ping <AWS 인스턴스의 프라이빗 IP>

* AWS의 인스턴스에서 오픈스택의 floating IP로 ping 통신

* 오픈스택 세션과 AWS 인스턴스의 세션 양 쪽 모두 ping 명령을 실행한 상태에서 restart 해야 됨

---

# 하드웨어 VPN장비가 없기 때문에 Libreswan 설치

 

dnf install -y libreswan

systemctl enable --now ipsec

 

# vi /etc/sysctl.conf
net.ipv4.ip_forward = 1                                      -> 리눅스가 라우터 역할을 하게 만드는 명령어
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

-> conf 파일에 없는 내용을 그대로 붙여 넣기

for vpn in /proc/sys/net/ipv4/conf/*;
do echo 0 > $vpn/accept_redirects;
echo 0 > $vpn/send_redirects;
done

-> mobaXterm 에 그대로 입력

 

sysctl -p

-> 위에서 진행했던 커널 수정작업을 적용하는 명령어

 

 

 

 

---

# 오픈스택의 WEBSERVER에서 AWS의 EFS에게 마운트

 

---

 

2차 프로젝트 설계도