<Network-4 Summary>
+ IP Saving
(1). Subnetting
(2). DHCP Dynamic Host Configuration Protocol
- 여러 시스템이 제한된 IP 범위에서 통신 할 수 있도록 IP 대여/반환 서비스 프로토콜
- 시스템에 IP를 자동으로 할당 -> 지금은 IP Saving 개념은 X
(3). NAT
- PAT(Port Address Translation)을 통해 IP 구조 문제 해결
- 모든 프로토콜에 대해서 적용 X
-> (NAT 주소 변환 가능한 프로토콜인) IP 위의 ICMP, UDP, TCP만 가능할 뿐,
IP 아래의 프로토콜은 NAT 적용 불가능
-> (기업/기관/개인의) 사설망에서 중간에 NAT가 있을 경우, 통신 불가한 문제
=> (NAT 변환 가능한) UDP로 감싸고 IP로 감싸서 마치 UDP 통신인 것처럼 속여서 끝단 사이에 통신 가능하도록 한다.
+ 브로드캐스트 Frame으로 인한 네트워크 성능 저하(<-Network Storming) 해결
-> 2계층 통신에서 Broadcast-Broadcast 통신에서 Broadcast-Unicast 통신으로 변경
<간단한 명령어 체계>
Ref. 콘솔 포트(매니지먼트 포트) <- (노트북 같은 터미널 장비의) Serial 포트(COM)
- DB9와 연결된다 -> 노트북의 USB포트로 변경
-> 실제 연결 시, Converter를 통해 진행
Ref. 포트의 모양이 같다고 같은 기능 X <- 포트마다 Voltage같은 전기적 방식이 다르다
-> 잘못 꼽을 시, Voltage같은 이유로 고장이 날 수 있다.
+ Cisco Network 장비의 OS: IOS
- User Mode : Ping Test 또는 옆 장비로의 Telnet Test, 간단한 설정 조회(~ show Command)하는 모드
- Privilege Mode : 설정 및 재부팅 등 가능한 관리자용 모드
+ 추가 Mode
“>” : 실행(EXEC) 모드
“#” : 관리자 모드 <- enable
“(conf)#” : Configuration Mode
- Global vs Sub
(1) Global: 장비 전체 설정 (Ex. 장비의 Hostname 부여, etc.)
(2) Sub: 부분 설정 (Ex. 지정한 Interface 설정(; (config-if)#), etc.)
Ref. 명령 맨 앞에
“do”: Exec 모드 명령어 사용 가능
“no”: Configuration 했던 것 취소 가능
+ # sh run vs # sh start
- running configuration = wr(; write Command) : RAM 상의 설정이기에 휘발성
-> copy run start : RAM상의 Running Configuration을 하드 디스크(; 부팅 시에 읽기 위해)에 저장
- start configurattion: 부팅 시에 읽어지는 NVRAM에 저장되어지는 설정
+ enable PW
: User Mode -> Privilege Mode 에서의 PW
Ref. Enable PW vs Secret PW
: Enable PW를 암호화한 PW가 Secret PW(; 장비의 벤더사 표시되는 것을 막기 위해)
#(config-line) login <- 로그인해서 접근 설정
<기술 설정에 Cisco 명령어>
+ router(외장형 라우터) InterVLAN Routing
<- trunk 기술(; L2 기능)
f0/0.10 & f0/0.20 -> sub interface는 바로 ip 설정 불가
-> 각 Sub Interface 당
no ip addr x.x.x.x.(; 기존의 IP 삭제)
Encapsulation dot1q 10
ip addr x.x.x.x 255.255.255.0
~ sub interface에 VLAN 지정; dot1q <VLAN NUM>
+ L3SW -> L2로 들어온 정보를 내장된 Routing 부분으로 옮겨야하므로 SVI Interface 설정
※ Cisco Packet Tracer’s L3SW: 3560 24PS <- BB급 불가
Ref. BB급 SW는 기본이 L3인 구조
L3 Conf t
(config)# ip routing <- L3SW로 동작
(config)# do sh ip route <- Routing 기능 확인
(config)# interface vlan 10
(config-if)# ip addr x.x.x.x x.x.x.x
(config)# interface vlan 20
(config-if)# ip addr x.x.x.x x.x.x.x
+ router 밑단에 L3SW가 들어가게 되면, DG/W는 L3SW의 포트 IP가 G/W가 된다.
<- 첫번째 만나는 L3 장비(; First Hop Router/Device)가 DG/W가 된다
-> 라우터와 L2SW 사이에, Firewall 장비(~ L4 이상의 장비)가 들어가게 되면 Firewall 장비가 DG/W가 될 수 있다
예외). 2가지 모드로 Firewall 장비: 라우터모드(; 보통) & 브릿지모드(; L2장비처럼) -> 브릿지모드로 동작하는 경우 Firewall 장비는 DG/W가 아니다.
※ L2 EtherChannel
switch) terminal interface range f 0/1 - 2
switch(config-if-range)# channel-group 1 mode desirable
<Web & DNS>
※ 컴퓨터 초반, 사람의 Typing(정보 입력) 정보 처리하기에 성능이 떨어져서 마우스의 사용을 통해 정보 입력 속도 낮췄다
※ Web service
하이퍼 링크를 통해 정보 찾기 쉽고 주고 받기에 더 편리해진 service
URL을 통해 리소스 위치 특정 -> DNS
+ Windows hosts File 위치
:c\windows\system32\drivers\etc\hosts
-> host file의 시스템 별 수동 작성의 어려움으로 -> DNS
+ DNS는 처음부터 분산 시스템으로 설계했으며, 계층적으로 동작
※ Root NS -> Top Level Domain (; gTLD & ccTLD(Ex. .com, .net, … etc.)) -> Second Level Domain(Ex. .naver, .daum, .kakao, …etc.)
+ DNS 2가지 Query
- recursive Query
: 클라이언트로부터 도메인 네임 질의 요청이 들어올 경우 네임서버가 직접 탐색하여 결과값을 변환
Ref. DNS Recursor = 캐시 DNS Server = 풀 서비스 리졸브
- Iterative Query
: Root DNS -> Top Level DNS -> Second Level DNS
Ref. DNS TCP 53 -> Primary & Secondary DNS 끼리의 configuration, DNS 정보 등을 주고 받아 동기화 하기 위해 사용
※ 서버들 있는 구역: 서버팜
+ Cisco DNS service 설정
A Record <-> PTR (PoinT Record)
Ref. Another Records : CNAME(Canonical Name record), start of authority (SOA) record
+ DNS Cache 정보 확인 COMMAND Windows
# ipconfig /displaydns
-> DNS Cache 초기화: # ipconfig /flushdns
<Network 보안>
+ TCP 3 hands shake
Sync : 준비되어 있는가
Sync + Ack : 준비 되어 있다, 너는 준비?
Ack : 준비 되어 있다
-> 윈도우 사이징 -> 신뢰성 있는 전송<- Ack를 받는 전송 -> 한 바이트 보내고 확인(Ack)를 받고 하면서 시간이 너무 많이 소요 -> window size에 따라 통신하게 된다.
+ window size : 묶인 데이터 크기
- Sync ; 나의 Win(;window Size)는 얼만큼이다. 정보도 같이 전송
- Ack; Window Size 확인
->>TCP Sync Flooding Attack
-> 서버가 Sync를 받으면 서비스 준비(<- 여러 서비스 요청들을 처리해야 하기에 Buffer가 할당) 마치고 Ack를 보내게 되는 데 -> Buffer가 유한(; 서버의 물리적인 리소스 한계가 있기에)하기에 서버를 여러대를 두게 된다. -> Client 수 한계 존재
-> 다수의 Client가 서비스 요청 -> 다수의 응답(Snc, Ack) => Client로 부터 Ack를 받아야 서비스 할 수 있는데, Ack를 받지 못하면 계속 Client’s ACK를 기다리면서 Buffer에는 (서비스 준비로) 리소스가 할당 된 상태로 서비스 중단 <= DoS Attack 중 하나 <- TCP 통신은 3 hand shake가 완료되어야 Virtual Circuit 생성으로 신뢰성 있는 전송을 하기에 그 부분 공략
-> 서버와 고객 사이 로드밸런서에서 Virtual Circuit 형성이 되지 않은 연결 상태를 일정량 이상되면 전부 없애는 기능을 넣어서 해결
-> LB에서 보안 기능 가능
+ LB 2가지 동작
(1). Inline Mode
C-S 사이의 데이터 경로 상에 LB가 배치 되고, Client는 Server의 IP를 LB’s VIP(Virtual Ip)로 생각하고 서비스
-> LB는 Client에게 받은 요청을 SourceIP가 Client’s IP로(DstIP=Server’s IP) Server에게 건네준다
-> Server에서 SIP=Server’s IP, DIP=Client’s IP로 넘겨주는 데, Inline Mode에서는 직접 전달하지 못하고 LB에게 보내고 LB에서 Service요청을 건내준 기록을 바탕으로 Client로 LB에서 전송
=> Destination NAT만 사용
(2). One Arm Mode
: C-S 사이가 데이터 경로에 연결 접합 -> LB로 Client는 서비스 요청을 보냈지만, Server에서 응답을 직접 전달하여 Client에서 정상적으로 응답을 받지 못했다고 인식 가능 -> 그래서 Server에서 응답 시, LB를 거치도록 NAT 설정 진행 필요
=> Dst NAT & Source NAT도 같이 진행 되어야 한다
+ 서비스 분리 이유: 서비스 안정성 때문에, 같은 시스템에서 서비스끼리의 영향 없애기 위해
-> 물리적 리소스 낭비 ex. 처음에 서버 풀세팅으로 구매, 실질적 사용 리서치에서 최대 15%일뿐
-> 환경 문제 발생, 과도한 전기 소모
-> 가상화로 효율적인 리소스 분배 & 서비스 개별 운영에 편리
+ 가상화 -> 클라우드 가속화
- 서비스 수요로 인한 유연한 확장란 장점이 코로나 때 빛을 발했다
※ 지금은 HTTP/5 기반으로 Cloud Service
이전에는 Java Version으로 Java version Trouble 발생
-> 개발자와 클라이언트 사이의 환경(OS, OS 내의 Java) 차이로
(바이너리/라이브러리 파일같은) “보조적인 파일”을 같이 어플리케이션을 제공하는 컨테이너!
-> 그래서 가상화와 비교해서 복사를 해서 사용해도 부팅하고 추가로 configuration이 필요 없게, 훨씬 빠르게 서비스 된다
+ Underlay Network; 물리적으로 연결되어 있는 네트워크
-> Overlay Network; 논리적으로 분리되어 있는 네트워크
; 내가 원하는 형태로 임의로 구성한 네트워크 이다
Ref. 예시는 VLAN이지만, 실제 VLAN은 Underlay Network로 취급된다.
-> ST-WAN으로 물리적인 대역대 등을 임의로 설정하고 구성 가능하다.
+ 망 구분 -> 외부망 & 내부망
-> 외부에서 내부로 침입하는 경우가 많이 발생
-> 보호하는 방법 강구
-> 개별적인 제어는 힘들어서 Network 차원으로 보호 -> 방화벽(Firewall) & VPN(Virtual Private Network)
+ firewall 동작
; 내부에서 밖에 나갈때는 괜찮지만, 외부에 안으로는 점검을 절차 진행
문제점:
- 내부의 시스템 이외의 서버가 있을 경우, 내부 침투 위험 <- 허용하게 되면 허용한 경로를 통해 침입을 차단하지 못하게 된다.
+ IDS: 어떤 이유로 침입 되었는 지 탐지
- 위치: SWitch에 연결해서 (스위치에서의) 데이터를 Mirroring 받아서 Signature 방식(;가장 널리)으로 검사/탐지
- 알려 줄 뿐 이미 전달 다 된 데이터 미러링이기에 그저 알림뿐
+ IPS: 탐지뿐만 아니라 방지까지 필요
- 배치(위치): 보안 장비들(Firewall, IPS, IDS, etc.) 중 맨 앞단
* WIDS Wireless IDS
- 최근에는 IDS/IPS로 합쳐서 제품이 나온다
- Signature 방식으로 검사/차단
- (맨처음)1차 보안 Filtering
-> 오탐(False Alarm)이 자주 발생 Ex. 쇼핑몰, 급증한 주문량을 DDoS 공격으로 간주
+ UTM : 한 장비에서 통합 보안 가능하도록 한 생산 장비
+ Zero-Trust 보안 관점
: 외부 & 내부 모두 포함해서 신뢰하지 않는다 -> 시스템 별 Firewall 설치
+ 정책: 외부와 내부와의 경계에서 서로 구분하는 정책 -> Zero-Trust 관점에서 더 작은 부분을 (시스템별) 경계를 짓게 된다
Ref. Micro Segmentation : 경계를 최소화 한 것
-> 서버 입장에서는 서비스를 해야하므로 불가능, 서비스 흐름에 따라 하나의 세그먼트화(그룹화)해서 보안성 증가
-> L3스위치를 중간에 두는 이유; TCP/IP 동작을 네트워크에서 제어(; 브로드캐스트 공격 등) 가능
-> 시스템 별 정책 설정이 가장 좋지만 현실적으로 불가능
Ref. Hybrid Cloud
:Ex. VMConAWS or VMConAzure or VMConGCP
Ref. Live Migration(Hot Migration)
Ref. (VMware vSphere) vMotion
Ref. VOS(Virtual OS) = Hypervisor(VMware’s ESXi)
-> Hypervisor 위에 있는 구조를 그대로 퍼블릭으로 올리면서 Live Migration 진행
※ 역사적으로 DR 백업의 중요성을 알게 된 계기가 된 사건: 9.11 Terror
+ SDN Software Defined Network
- 장비의 3가지 기능
(1). Management Plane ; configuration(설정) 같은 관리하는 기능
(2). Control Plane ; mac table or routing table(데이터 제어하는 ) 만들어서 제어 기능
(3). Data Plane ; 데이터를 보내는 기능
-> (코로나 때) 급속도의 네트워크 확장으로 인한 네트워크 장비들 수 증가 -> 추가된 네트워크 장비들의 요구 기능: (3). Data Plane -> (1).&(2).의 Management 기능을 하는 Server 추가하게 된다
거기의 nsx manager에서 필요한 보안 정책들 설정 <- 시스템 안에 설정 불가 -> (만든 FW 정책이 각각 VM 앞단(스위치를 통해)에 붙게 된다 -> 시스템 안에 들어가지 않아도 NIC 앞단에서 정책이 동작해서 VM마다 동일하게 정책 동작하게 된다
Ref. https://www.techtarget.com/whatis/definition/plane-in-networking
