라우터 동작
MAC -> 이더넷 프로토콜 -> Gateway까지 감
패킷이 라우터에 도달하면 input queue에 들어감(FIFO 방식)
https://book.systemsapproach.org/congestion/queuing.html
Routing Table: 라우터가 알고있는 도달 가능한 경로 정보가 들어있음
라우팅 방식 2가지
- 정적 라우팅 -> 클라우드에서 주로 쓰임
- 동적 라우팅 -> 레거시에서 주로 쓰임
라우팅 프로토콜로 서로 대화를 함
https://min-310.tistory.com/161
output queue에 쌓임
ARP를 통해 MAC을 씌워서 ISP로 보냄
ISP는 DNS(8.8.8.8)로 보냄
DNS는 입구에서 MAC을 확인하고 나서, IP를 확인함
라우터는 내부에서 '패킷'을 처리한다.
라우터는 '패킷'의 목적지 'ip'를 보고 경로를 설정한다.
PDU(Protocol Data Unit) - 프레임, 패킷, 세그먼트
Network: 공통된 목적을 갖는 집단 -> LAN, WAN, Internet
- LAN(Local Area Network) ex) 한 강의실
- WAN(Wide Area Network) -> 공중망 ex) 부산 지사와 서울 분사
- 부산 지사와 서울 본사를 연결 -> 우리 회사끼리만 쓰려고 함
-> 사설ip 사용 - 서울 본사만 인터넷에 연결되어있고, 부산 지사는 서울 본사를 통해 인터넷에 접속
- 데이터센터끼리는 WAN으로 연결(서울, 부산, 제주), 서울 본사만 별도로 인터넷 연결
- 부산 지사와 서울 본사를 연결 -> 우리 회사끼리만 쓰려고 함
ap-northeast-1 Region -> a, b, c zone에 인스턴스 있음
c의 웹서버에서 발생한 데이터를 c의 db에 저장 -> 비용 발생 안 함
a 또는 b 웹서버에서 발생한 데이터를 c의 db에 저장 -> 비용 발생함. ISP를 이용했기 때문
비용 절감하는 방법?
한 zone에 웹서버와 db를 몰아두고, 장애 상황에 대비하여 다른 zone에 backup db를 둠
https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_ReadRepl.html
VPN
본사와 지사를 WAN으로 연결
본사는 인터넷과 연결되어있음
만약 본사와 지사가 연결되어있는 WAN이 고장났을 경우 지사는 인터넷이 안 될 것임
지사도 공중망을 통해 인터넷에 접속되게 할 수 있지만 보안에 매우 취약해짐
따라서 데이터의 암호화, 무결성 검사(hash), 인증(Authentication)이 필요함
이를 VPN(Virtual Private Network)이라고 한다.
https://docs.aws.amazon.com/ko_kr/vpn/latest/clientvpn-admin/scenario-peered.html
OSI 7계층
7 응용프로그램
6 표현
5 세션
4 전송
3 네트워크 -> 라우터 -> 다른 네트워크
2 데이터링크 -> 스위치 -> 동일 네트워크
1 물리
TCP/IP stack
LoadBalancer
NLB -> 4계층에서 Segment의 'Port'를 보고 부하 분산을 한다
ALB -> 7계층에서 프레임의 Data에서 주소를 확인하고 부하 분산을 한다
ex) www.test.com/blog, www.test.com/news에 따라 부하 분산. 컨테이너 기반 개발
쿠버네티스 -> ingress + Autoscale
https://matthewpalmer.net/kubernetes-app-developer/articles/kubernetes-ingress-guide-nginx-example.html
GNS3 실습
HQ에 slot 추가(NM-1FE-TX) -> 포트 개수 부족해서 늘렸음
cloud1 configure -> 이더넷 추가
인터넷과 HR 연결은 fa0/0
라우터끼리 연결은 fa0/1
라우터와 스위치 연결
스위치와 PC 연결
HQ와 BR만 start하기
네트워크 구성
HQ --- BR: 10.10.10.0/24
HQ --- PC1: 10.10.100.0/24
BR --- PC2: 10.10.200.0/24
[HQ Router]
conf t
int fa1/0 -> 스위치 설정
ip add 10.10.100.1 255.255.255.0
no sh -> changed state to up
int fa0/1 -> BR과의 WAN 설정
ip add 10.10.10.1 255.255.255.0
no sh -> changed tp state up
do show ip int br
[BR Router]
conf t
int fa0/0 -> 스위치 설정
ip add 10.10.200.1 255.255.255.0
no sh
int fa0/1
ip add 10.10.10.2 255.255.255.0
no sh
[HR Router]
do ping 10.10.10.2
!!!!! -> 된다
do ping 10.10.10.2 source 10.10.100.1
..... -> 안 된다
이유?
-> src: 10.10.100.1
-> dst: 10.10.10.2
src는 dst를 알기 때문에 가지만,
dst는 src를 모르기 때문에 돌아오지 못함(Routing Table에 없어서 패킷이 drop됨)
do ping 10.10.200.1
..... -> 안 된다
dst가 어디 있는지 모르기 때문에 가지도 못 한다
ip route 10.10.200.0 255.255.255.0 10.10.10.2 -> 지사쪽으로 가기 위한 라우팅 설정
-> 10.10.200.0으로 들어오는 패킷을 10.10.10.2로 보내겠다
[BR Rotuer]
ip route 10.10.100.0 255.255.255.0 10.10.10.1 -> 본사쪽으로 가기 위한 라우팅 설정
-> 10.10.100.0으로 들어오는 패킷을 10.10.10.1로 보내겠다
[HQ Router]
do ping 10.10.200.1 source 10.10.100.1 -> 10.10.100.1에서 출발해서 10.10.200.1로 ping
!!!!! -> 이제 통신이 가능해졌음
HQ Router, BR Router
do wr -> write memory -> 저장하기
[HQ Router]
do show ip route
HQ Router에서 do ping 10.10.10.2를 했을 때
broadcast ARP -> who has 10.10.10.2?(target MAC을 모름)
10.10.10.2 -> HQ에게 자기 MAC주소 알려줌
10.10.10.2의 MAC주소(target MAC)를 알게 된 HQ는 다시 10.10.10.2에게 MAC헤더가 포함된 프레임을 보냄
HQ에서 do show arp를 하면, ARP가 발생하여 ARP Table에 10.10.10.2의 MAC 주소가 저장된 것을 확인할 수 있음
ex)
ip route 1.1.0.0 255.255.0.0 2.2.2.2 -> 1.1.0.0 ~ 1.1.255.255의 ip를 2.2.2.2로 보내겠다
ip route 1.0.0.0 255.0.0.0 2.2.2.2 -> 1.0.0.0 ~ 1.255.255.255의 ip를 2.2.2.2로 보내겠다
ip route 0.0.0.0 0.0.0.0 2.2.2.2 -> 0.0.0.0 ~ 255.255.255.255의 ip를 2.2.2.2로 보내겠다 -> default route -> 매우 중요!! -> pc에서 default gateway도 이것과 같음
IPv4 -> 4개의 옥텟. 각 옥텟은 8bit
0.0.0.0 ~ 255.255.255.255
HQ에서 default route 설정하기
[HQ Router]
ip route 0.0.0.0 0.0.0.0 192.168.1.1 -> 모든 ip를 192.168.1.1(인터넷)으로 보내겠다
[BR Router]
ip route 0.0.0.0 0.0.0.0 10.10.10.1
Longest match rules
BR의 PC가 10.10.200.100으로 가고 싶다고 할 때, 어떤 경로를 통해서 갈까?
do show ip route를 하면 아래와 같은 route들이 있음
해당 route들 중에서, 10.10.200.100으로 갈 수 있는 경로는 두 가지가 가능함.
C 10.10.200.0
S* 0.0.0.0/0
둘 중에서 10.10.200.0이 더 자세한 주소이므로, 해당 경로를 선택함
라우터와 같이 패킷 처리 장비는 목적지 주소에 부합하는 네트워크 경로가 2개 이상일 경우에는 더 자세한 주소로 찾아간다. (경로가 더 많이 matching되는 경로)
-> longest match rules! (상식으로 알아두기)
GNS 실습 - 이어서
[HR Router]
int fa0/0
ip add 192.168.1.116 255.255.255.0
no sh
do ping 8.8.8.8 -> 됨
exit
ip name-server 8.8.8.8
ip domain-lookup
do ping www.google.com
[BR Router]
do ping 8.8.8.8 -> 안 됨
[HR Router]
! private addresses
access-list 1 permit any -> any는 0.0.0.0과 같음
! private addresses => public ip
ip nat inside source list 1 int fa0/0 overload
! busan branch network
int fa0/1
ip nat inside
! head quarter network
int fa1/0
ip nat inside
! internet network
int fa0/0
ip nat outside
PC1, PC2 start 시키기
[PC1]
ip 10.10.100.100/24 10.10.100.1 -> 10.10.100.100이 ip, 10.10.100.1이 gateway
ip dns 8.8.8.8
ping www.google.com -> 잘 됨
[PC2]
ip 10.10.200.200/24 10.10.200.1
ip dns 8.8.8.8
ping www.google.com -> 잘 됨
ping 10.10.100.100 -> 지사pc에서 본사pc로 -> 잘 됨
시나리오
우리 회사는 웹서비스 제공을 위하여 공인 주소를 구매하였다.
211.183.3.0/24를 사용할 수 있고, 라우터에 HQ의 fa0/0에는 211.183.3.99를 할당한다.
ISP 주소는 211.183.3.2로 고정되어있다. 나머지 주소는 내부에서 자유롭게 사용할 수 있다.
이 중, 211.183.3.100은 본사와 지사에 있는 pc들이 동적 PAT를 통하여 외부(인터넷)와 연결이 가능하도록 할 계획이고, 211.183.3.101은 본사 내부에 있는 웹서버 10.10.100.100과 1:1로 정적 NAT를 구성하여 웹서비스를 제공할 계획이다.
cloud의 선 delete
cloud의 이더넷 삭제 후 VMnet10 추가
step 1. 인터페이스에 ip 주소 입력
[HQ Router]
int fa0/0
ip add 211.183.3.99 255.255.255.0
do ping 211.183.3.2 -> 잘 됨
step 2. 인터넷 연결을 위한 default route 설정
do show run | in ip route -> ip route를 포함해는 내용을 보여줌
no ip route 0.0.0.0 0.0.0.0 192.168.1.1 -> 기존 ISP route 삭제
ip route 0.0.0.0 0.0.0.0 211.183.3.2 -> 새로운 ISP로 보냄
do ping 8.8.8.8 -> 됨!
step 3. 인터넷 사용을 위한 동적 PAT 구성
기존 설정 중에서 지워야 할 설정 -> NAT 설정 지우기
do show run | include ip nat
no ip nat inside source list 1 interface FastEthernet0/0 overload
ip nat pool PRI 211.183.3.100 211.183.3.100 pre 24
Pool name: PRI라는 pool에 담을 것임
start IP: 211.183.3.100
end IP: 211.183.3.100
prefix-length: 24
ip nat inside source list 1 pool PRI overload
PRI라는 pool을 사용
overload: 여러 개의 사설 ip가 하나의 ip를 공유할 것임
cloud의 선 선택해서 start capture -> filter에 ICMP 적용
PC1> ping 8.8.8.8
PC2> ping 8.8.8.8
step 4. 웹서버 연결을 위한 정적 PAT 구성
aws에서 서버를 생성하면 사설 주소가 할당되고, 자동으로 공인 주소를 부여해준다. 하지만 이 공인 주소는 고정이 되지는 않는다. -> dynamic NAT
elastip ip는 위와 같은 환경에서 공인 IP 주소를 정적으로 사설 주소와 매핑해주는 기능이다. -> static NAT
[HQ Router]
ip nat pool WEBSRV 211.183.3.101 211.183.3.101 pre 24
ip nat inside source static 10.10.100.100 211.183.3.101
inside local IP address: 10.10.100.100
inside global IP address: 211.183.3.101
내 로컬 pc에서 ping 211.183.3.101 -> 잘 됨!
AWS
VPC
172.31.0.0/16
라우팅
0.0.0.0/0 -> igw
172.31.0.0/16 -> local
서브넷
172.31.0.0/20 -> Web
172.31.16.0/20 -> WAS
172.31.32.0/20 -> DB
서브넷의 장점
- 보안성이 높음(ex. DB는 WAS와만 연결됨)
- 유지 보수가 편함
- 불필요한 트래픽을 줄일 수 있음
일반 VM vs 인스턴스 VM
일반 VM -> iso와 같은 설치 파일을 이용하여 OS 설치 작업을 수동으로 일일이 진행해야 한다. 상세한 설정이 가능하다는 점에서는 유용하나, 클라우드 환경에서는 적절하지 않다.
인스턴스 VM -> 클라우드용 이미지(OS가 설치된 환경을 이미지화 한 것 = 템플릿 또는 클래스)를 이용하여 deployment, 찍어내다!! 단, 동일한 이미지를 사용하므로, 만약 루트에 대한 패스워드를 설정한 상태에서 이미지화 했다면 모든 인스턴스는 동일한 패스워드를 사용해야하는 보안상 결함이 발생한다. 이를 해결하기 위해 key-pair를 이용한다.
ec2 인스턴스 생성
이름: testwebsrv
AMI: Amazon Linux kernel 4.14
키페어: mykey
SSH 트래픽 허용: 내 IP로 설정 변경
인터넷에서 HTTP 트래픽 허용 체크
탄력적 IP 주소 할당 -> 인스턴스에 주소 연결
ping [내 EIP] -> 안 됨
-> ICMP 인바운드 규칙을 추가해야 됨
-> 모든 ICMP - IPv4 추가하기
Docker 실습
puttygen 실행 -> mykey.pem load 후 private key 생성 -> mykey.ppk
putty 실행 -> SSH -> Kex
디피헬만14을 제일 위로
디피헬만1을 두 번째로 순서 변경
Auth -> Private Key 선택 mykey.ppk
Hostname -> IP 입력 - > Open
sudo yum -y install docker
sudo systemctl start docker
sudo systemctl status docker
sudo docker container run --name centos --hostname centos -it centos:7 /bin/bash
uname -nr
centos 4.14.281-212.502.amzn2.x86_64 -> 아마존의 커널을 사용 중
ctrl+p,q 를 누르면 빠져나옴 -> 하지만 도커는 계속 돌고 있음
sudo docker container attach centos -> 다시 centos로 들어옴
1) 80번 포트에 nginx 설치
sudo docker container run -d --name nginx1 -p 80:80 nginx
-> 아마존 리눅스의 80 포트로 들어오면, nginx1의 80포트로 보내줌
pc에서 3.114.86.128 접속 -> nginx 페이지 뜬다
2) 8001포트에 nginx 설치
sudo docker container run -d --name nginx2 -p 8001:80 nginx
-> 아마존 리눅스의 8001 포트로 들어오면, nginx2의 80포트로 보내줌
pc에서 3.114.86.128 접속 -> 안 된다! -> 보안그룹 인바운드 규칙에 8001포트 추가(0.0.0.0/0)
pc에서 3.114.86.128:8001 접속 -> nginx 페이지 뜬다
3) 8002포트에 nginx 설치
sudo docker container run -d --name nginx3 -p 8002:80 nginx
보안그룹 인바운드 규칙에 8002포트 추가(0.0.0.0/0)
pc에서 3.114.86.128:8002 접속 -> nginx 페이지 뜬다
4) 8002포트에 아파치 설치
sudo docker container rm -f nginx3
sudo docker container run -d --name httpd1 -p 8002:80 httpd
pc에서 3.114.86.128:8002 접속 -> It works! 아파치 페이지 뜬다
내일 배울 내용: vSwitch
