< L4 Switch & L7 Switch >
+ L4SW & L7SW
- Load Balancing
- Multi Layer 또한 가능
- L4SW의 Load Balancing
: L4(& TCP/IP Transport Layer) Switch는
4계층(; 양단의 연결 & TCP/UDP)에서 (부하분산을 위해) 송수신 측에 부하분산 방식으로 IP, TCP/UDP 등에 따라 구분해서 연결한다.
- L7SW의 Load Balancing
: 데이터 파일의 확장자를 구분하고 분별하여 부하를 분산한다.
Ex. .exe File or .bat File 등 보안과 관련된 확장자를 가진 파일의 경우, 서버로의 유입을 막는 기능도 가질 수있다
!※ [MSA Part]
K8s Ingress Controller(Ex. Nginx Ingress, GKE, King, etc.)를 통한 Ingress
: Ingress의 경우, Layer 7에서의 요청을 처리함에 외부로부터 들어오는 요청에 대한 LB, TLS/SSL 인증서 처리, 특정 HTTP 경로의 라우팅 등을 Controller에서 정의, 제어하고 그에 따라 Ingress 동작한다
~ LB는 Ingress의 한 기능이며 처리함에 L7 Load Balancing을 한다
! GKE의 경우, 클라우드 플랫폼에 K8s를 위임할 수 있지만
AWS에서 EKS 또는 EC2를 사용할 경우는
k8s Cluster에서 Nginx ingress Controller를 직접 생성하고 외부에서 Nginx에 접근하기 위한 (k8s 서비스의 타입을 Load Balancer 타입으로 설정해) AWS LB 생성하게 된다
!! AWS LB 생성 시, ELB/NLB/ALB 중 선택함에 쿠버네티스 애플리케이션 특성을 고려!!
!!! Ex. gRPC 지원 여부, 대규모 트래픽 필요 여부 등 !!!
※ gRPC google Remote Procedure Calls
- 구글이 최초로 개발한 오픈 소스 원격 프로시저 호출(RPC) 시스템
- 전송을 위해 HTTP/2를 사용
- 인터페이스 정의 언어로 프로토콜 버퍼를 사용하며
인증, 양방향 스트리밍 및 흐름 제어, 차단 및 비차단 바인딩, 취소 및 타임아웃 등의 기능을 제공
- “수많은 언어를 대상”으로 크로스 플랫폼 클라이언트 및 서버 바인딩을 생성
- 가장 흔한 시나리오로,
MSA의 서비스 연결, 모바일 장치, 브라우저 클라이언트를 백엔드 서비스에 연결하는 일
Ref. 브로드캐스트의 2가지
- 로컬 브로드캐스트 : 특정 시스템의 같은 네트워크에 브로드캐스트
- 서브넷 브로드캐스트 : 특정 네트워크를 지정해서 브로드캐스트
-> 라우터는 기본적으로 포트를 막아놓기에, 라우터는 기본적으로 유니캐스트 통신을 한다
※ Port Number
(1) 0 ~ 1023 : Well-known Port
(2) 1023 ~ 49151 : Registered Port
(3) 49151 ~ 65535 : Dynamic Port
<Port Security와 더불어 IPv6>
+ 네트워크 트래픽 도청(; Sniffing)에 대한 보안 해결책 -> Port Security
상황 1. MAC 발생기로 L3SW의 MAC Table을 포화 상태로 만들어서 실질적인 MAC정보를 MAC Table에서 가지지 못하게 한다.
상황 2. 네트워크 내의 모든 통신이 Flooding(;스위치에서 브로드캐스트)으로 트래픽 도청 가능하게 된다
-> 공격 당할 위험 증가
=> Port Security 수행
+ Port Security
- 하나의 포트에는 하나의 MAC정보만 가지도록 설정
※ VoIP ~ Port Security 관련
포트는 하나여서 문제!
-> 전화기와 스위치를 결합해서 스위치에 컴퓨터를 연결해서 하나의 포트에 2개이상의 MAC주소를 가지게 된다 -> Default Violation에 의해 포트가 막힌다
+ TCP/IPv4 to TCP/IPv6
-> Internet 계층에서 가장 큰 변화 (TCP/UDP도 영향을 받음)
| Internet Layer | TCP/IPv4 | TCP/IPv6 | |
| ICMP | IGMP | ICMPv6(<- ICMP, IGMP, ARP 기능) | |
| IPv4 | IPv6 | ||
| ARP | RARP(-> DHCP) | ||
+ ARP 데이터 내에 IP 정보도 있으므로 -> MITM(Man In the Middle, 중간자 공격)
Ex.
예시 환경 : 하나의 허브에 3개의 단말기 A, B, C가 연결된 하나의 허브 네트워크
상황 1. A가 특정 IP의 MAC주소가 MAC Table에 없다
-> ARP Request(~Broadcast, A to BD) : 담고 있는 정보: A’s IP, 특정IP(= B’s IP), A’s MAC
상황 2.(1). B 측, ARP Response(Reply) : Unicast, B to A
상황 2.(2). C 측, 상황 1’s ARP Request(~Broadcast from A)가 담고 있는 정보를 알게 된다.
-> C가 A’s IP와 A’s MAC주소를 알고 네트워크 내의 “특정 IP”(= B’s IP) 또한 알게 된다.
상황 3. C가 특정 IP의 MAC주소를 알기 위해 ARP Request(~Broadcast, C to BD) -> Reply(~from B)
상황 4. C는 A’s IP, MAC & B’s IP, MAC을 모두 아는 상황
-> C에서 A’s IP와 B’s IP 모두를 C’s MAC으로 A와 B 둘 다에게 재학습시키면, C는 A에서 B로의 통신을 Sniffing 가능
-> C는 MITH(중간자 공격) 가능 상태
=> L2 스위치는 방어가 불가능하며 L3 스위치에서는 차단 할 수 있다
(※ 가상 스위치에서도 차단 설정 가능)
※ WireShark
~ WinPcap Driver로 패킷 Chapter한다
<STP와 관련된 Looping 문제>
+ Looping : Data 전송 경로에 원이 생기는 경우(; Dst에 도착하지 못하고 순환 발생)
- L2 Looping -> 1L & L2의 Looping의 경우, 해결 할 수 없어서 제어 불가능
- L3 Looping
+ 보통 사내 스위치 2가지로 운영
(1) Access Switch(단말 Switch, Workgroup Switch)
- 단말기와 연결된 Switch
- 보통 L2SW로 구성
(2) Backbone Switch(Aggregate Switch) : Access Switch들끼리의 연결
- Route와 연결 (; 사이에 네트워크 보안 장비 배치)
- Server Farm과 연결
- 보통 L3SW로 구성
- 고가용성이 필요하기에 링크 이중화로 구성
-> Looping 발생
=> 아예 물리적인 Looping이 생기지 않도록 Spine-Leaf 구조로 구성해버린다(가상화 또한) -> 가상화 환경에서는 가상의 스위치를 만들게 되는 데, 아예 가상 스위치끼리 연결을 안 함으로써(Spine-Leaf Architect) 아예 Looping을 원천 차단( 찾기도 어렵고 모든 시스템 구조를 확인해야 하기에)
+ L2스위치간의 Looping을 막아주는 Protocol인 STP
-> STP가 모든 Looping을 해결해 주지 못한다!
<VLAN>
+ VLAN : Broadcast Domain 나누는 기술 (L2)
- Segmentation
- Flexibility
- Security
※ MAC Table에 VLAN의 정보 또한 있기에, VLAN 설정 이전의 MAC Table 정보가 있다한들 VLAN이 다르면 연결되지 않는다
+ VLAN 기술 사용에 필요한 Trunk 기술
하나의 포트가 여러개의 VLAN의 정보를 가지는 것 : Multi VLAN
-> 나눈 브로드캐스트 도메인이 다시 합쳐지는 문제 발생 <- 원인 : 데이터에서 VLAN을 구분할 수 없기에(~ 연결된 모든 VLAN에 브로드캐스로 Query 발생)
-> Trunk 기술을 사용하게 되면 구분자(Tag) 사용으로 해결
+ Trunk 기술(IEEE 802.1Q, dot1Q) (※ IEEE 802.1은 스위치 관련 표준)
: 2계층에서 Multi VLAN 정보를 가지면서 데이터가 어느 VLAN인지 알려주는 Tag를 붙이는 기술
- 2계층 Frame에서 Tag(VLAN Tag, VLAN ID)
Dst MAC | Src MAC | (Tag’s Location) | type | Data | FCS | + | Tag |
=> Tagged Frame : | DM | SM | Tag | type | Data | FCS |
-> Trunk Port(; Switch나 trunk를 지원하는 NIC를 가진 Host에 연결)를 지날 때, Frame에 Tag 정보가 추가되고
-> 스위치끼리 어느 VLAN인지 정보를 교환한다
※ Trunk Port와 다르게, Access Port(; trunk를 지원하지 않는 NIC를 가진 Host에 연결 -> VLAN만 설정되어 있는 포트)로 내보낼 때는
Tag 정보를 제거해서 원래 Frame으로 원복하며,
그렇지 않을 경우 호스트에서 위조된 Frame으로 간주하고 버리게 된다
+ (다른 VLAN에 같은 네트워크 대역 IP 할당 ->) 같은 네트워크이면서 VLAN이 다르면 통신까지 불가능하게 되는 문제
-> VLAN마다 서로 다른 네트워크를 설정해 주면 Router를 통해서 Routing 가능하여 통신이 가능하게 된다
~ 라우터 또한 trunk 기술이 지원된다 -> 그로 인해 병목현상 발생( <- 스위치에서 빠르게 처리했지만 결국 윗 단의 라우터에서 (병목현상으로 인해) 느려진다)
-> 라우터 기능과 L2스위치 기능을 합친 L3스위치(~ 내부적으로 Fabric 구조로 데이터를 처리) 사용
-> L3스위치를 VLAN 간의 빠른 처리를 위해 사용하였다(: Inter VLAN Routing으로 L3SW 사용)
~ 가상화 환경에서는 이런 기술이 PC 안으로 들어가게 된다?!
+ EtherChannel (Link aggregation)
: 최대 8개까지의 물리적인 Link(Cable)을 논리적인 Ethernet Link(Virtual Link)로 만드는 Protocol
Ref. Network Traffic 혼잡 상황의 경우, 드랍되고 재전송되면서 네트워크가 더 악화된다
-> 비슷한 링크들의 논리적인 결합: Load Balancing
-> 논리적으로 하나인 Port Redundancy(이중화)
(1). 일시적인 traffic 혼잡 상황일 경우, QoS 사용
Like) “교통경찰”을 통한, traffic 해결
※ QoS ~ 일시적인 traffic 혼잡 상황 풀어주는 기능
(2). 지속되는 traffic 혼잡 상황일 경우, EtherChannel
Like) “도로확장”을 통한, 해결
<- 단순히 물리적인 링크(Cable)을 추가하면 STP에 의해 추가된 포트가 막히는 문제 발생
-> STP를 속여서 하나의 논리적인 Ethernet Link(Virtual Link)로 만드는 Protocol인 EtherChannel
-> STP를 속이는 것이기에 잘못되면 루핑이 발생할 수 있다.
※ EtherChannel(~ Cisco)
= Link aggregation(~ another vendors)
= NIC Teaming(~ Windows, Cloud)
= NIC Bonding(~ Linux)
= Channel Bonding(~ wireless)
<4. 라우팅 기술>
+ Routing 기본
(1). Destination Based Routing
df. Switcch는 소스도 보고 전송하지만
(2). Unicast Routing
- 목적지 주소에 Unicast 주소만 갖게된다
- 목적지에 대한 정보가 없으면 Drop하게 되고 출발지에게 ICMP로 Drop 보고한다
(3). Network Based Routing
라우팅 테이블에는 네트워크 정보만 (Not Host)
(4). Hop by Hop Routing
라우팅 테이블에 목적지로 가는 모든 경로를 기록하지 않고 바로 다음(Next Hop Router)로의 경로를 기록한다
Ref. Routing Table.Like) 사거리 도로교통 표지판(~ 방향에 따른 대략적인 장소를 알려준다.)
-> 라우팅 테이블에는 네트워크 정보만 기록
+ Routing Table의 경로
(1) 라우터가 직접 인식하는 경로
Directly connected : Router에 직접 연결된 Network 정보
(2) 학습에 의해 인식되는 경로
- Static Routing : 관리자에 의해 수동으로 생성된 경로 정보
~ 수많은 네트워크를 일일히 관리자가 직접 수동으로 작업하기에 한계가 있다
⇩
- Dynamic Routing : 다른 Router들로부터 학습한 경로 정보
-> 인접 Router와의 경로 정보 교환에 있어 필요한 규약/제약: Routing Protocol
+ routing protocol에서
클라우드에서는 static routing 설정과 BGP(; 인터넷과의 연결에서 Routing protocol)
+ Routing Algorithm을 기준으로 Protocol 나눈다
+ Routing algorithm
(1). Distance Vector
- 주위의 라우터의 방향과 거리(홉)에 따라 경로 선택
- 이웃하는 라우터에서 알려준 정보에 의존하기에 잘못된 경로로 인해 L3 Looping이 발생할 수 있다
Ex. RIPv2 <- 좁은 곳에서 사용, 알고리즘이 보완하지만 완벽히 해결하지 못한다
Ex. BGP
(2). Advanced Distance Vector
(3). Link-State
- (SPF Algorithm을 통해) 전체 네트워크 지도에서 목적지까지의 길을 파악하고 최적의 경로를 선정하고(;SPF Algorithm을 통해) 라우팅 테이블에 기록하고 경로 선택
-> 전체 네트워크 및 네트워크의 정보 와 메모리 및 CPU(리소스)들이 많은 양이 요구 (계산하기위해)
중대형망에서 안정적으로 라우팅하기위해 사용
-> 디자인을 잘해서 최소한의 네트워크 정보를 가질 수 있도록 해야하는 프로토콜
Ex. OSPF
+ 라우팅 프로토콜을 구분하는데 AS 사용
AS -> ISP를 기준으로해서 할당 -> 큰 기업들 or 정부 가 받은 AS 기준으로 영역을 관리
Ref. AS번호를 받은 기관/기업은 BGPv4+ 다뤄야 한다
(1). IGP(Interior Gateway Protocol) : ISP/대기업이 받은 AS(;할당받아 관리하는 네트워크) 안에서 운영되는 Routing Protocol
Ex. 대부분의 Routing Protocol
(2). EGP(Exterior Gateway Protocol) : AS 간의 운영되는 Routing Protocol
Ex. BGPv4+
※ ICANN ~ IP #, Port #, AS # 관리
⇩
RIR <- Reason Internet Registry Ex. APNIC
⇩
(특정 국가에서만?)NIR National Internet Registry Ex.KRNIC
⇩
LIR Local Internet Registry Ex. ISP
+ Stub Network의 의미
맨 끝단에 형성된 네트워크
- 외부와 통신하는 부분이 한 부분인 네트워크 -> 한 부분(ISP or HQ Router)을 통해서만 외부와 통신하는 네트워크
-> 외부와 통신하기 위해,
(1). Default Route 설정
Ex. Stub Network’s Router에서 Default Route 설정
-> Default Route: ip route 0.0.0.0 0.0.0.0 172.16.x.x(ISP의 라우터) <- 공유기에 기록되어 있어서 많은 네트워크 정보가 없어도 Stub Network가 외부와 통신 할 수 있다
-> (2). ISP/HQ Router에서도 Static Route 설정
Ex. Static Route: 172.16.x.x(Stub Network) 255.255.255.0 172.16.x.x(Target IP; Stub Network’s Router)