네트워크 공부를 위해 읽은 책. 내 생각에 네트워크는 이 한 권으로 충분하다.

1. 홈네트워크

홈 네트워크를 구성하는 데는 모뎀, 공유기, 단말 간에 물리적 연결이 필요합니다. 무선 연결은 무선 랜 카드와 무선 신호를 보낼 수 있는 매체(공기)가 필요하고 유선 연결은 유선 랜 카드(이더넷 랜 카드: 일반적으로 보드에 내장됨), 랜 케이블(일반적으로 랜선이라고 부름)이 필요합니다.

1.1 데이터 센터 네트워크

데이터 센터 네트워크는 안정적이고 빠른 대용량 서비스 제공이 필요하기 때문에 높은 통신량을 수용할 수 있어야 합니다.

데이터 센터 구성은 기존에는 3계층 구성이 일반적이었지만 가상화 기술과 높은 대역폭을 요구하는 스케일 아웃(Scale-Out) 기반의 애플리케이션과 서비스가 등장하면서 2계층 구성인 스파인-리프(Spine-Leaf) 구조로 데이터 센터 네트워크가 변화되었습니다.

2. 프로토콜

네트워크에서 프로토콜은 통신할 때의 규약입니다. TCP와 IP는 별도 계층에서 동작하는 프로토콜이지만 함께 사용하고 있는데 이런 프로토콜 묶음을 프로토콜 스택이라고 부릅니다.

TCP/IP 프로토콜 스택은 총 4개 부분으로 나뉩니다. 물리 부분인 이더넷 외에 데이터가 목적지를 찾아가도록 해주는 네트워크 계층, 잘린 패킷을 데이터 형태로 잘 조합하도록 도와주는 전송 계층과 애플리케이션 계층으로 구성됩니다.

3. OSI 7계층

여기서 1 ~ 4 계층을 데이터 플로 계층 (하위 계층) 이라고 하고 5 ~ 7 계층을 애플리케이션 계층 (상위 계층) 이라고 합니다.

상위 계층은 애플리케이션 개발자가 주로 고려해야 할 부분이고, 하위 계층은 네트워크 엔지니어가 주로 고려합니다. 따라서 TCP/IP 모델은 아래와 같이 4단계로 구분합니다.

1계층 (Physical)

1계층의 주요 장비로 허브, 리피터, 케이블, 커넥터, 트랜시버, 탭이 있습니다.

1계층에서는 들어온 전기 신호를 그대로 잘 전달하는 것이 목적이므로 전기 신호가 1계층 장비에 들어오면 이 전기 신호를 재생성하여 내보냅니다.

2계층 (Data link)

2계층의 네트워크 구성 요소로 네트워크 인터페이스 카드(NIC) 와 스위치가 있습니다.

2계층에서는 출발지와 도착지 주소(MAC) 를 확인하고 내게 보낸 것이 맞는지, 또는 내가 처리해야 하는지에 대해 검사한 후 데이터 처리를 수행합니다.

네트워크 인터페이스 카드와 스위치 모두 MAC 주소를 이해할 수 있고 스위치는 MAC 주소를 보고 통신해야 할 포트를 지정해 내보내는 능력이 있습니다.

3계층 (Network)

3계층의 네트워크 구성 요소로 라이터가 있습니다. 라우터는 3계층에서 정의한 IP 주소를 이해할 수 있습니다. 라우터는 IP 주소를 사용해 최적의 경로를 찾아주고 해당 경로로 패킷을 전송하는 역할을 합니다.

3계층에서는 IP 주소와 같은 논리적인 주소가 정의됩니다.

4계층은 데이터들의 흐름 제어, 혼잡 제어, 오류 제어 등의 역할을 합니다. 패킷에 보내는 순서인 시퀀스 번호(Sequence Number) 를 명시하고 ACK 번호(Acknowledgement Number) 로 받는 순서를 나타냅니다. 또한 장치 내의 많은 애플리케이션을 구분할 수 있도록 포트 번호(Port Number)를 사용해 상위 애플리케이션을 구분합니다.

5계층(Session)

5계층은 양 끝단의 응용 프로세스가 연결을 성립하도록 도와주고 연결이 안정적으로 유지되도록 관리하고 작업 완료 후에는 이 연결을 끊는 역할을 합니다.

6계층(Presentation)

6계층은 일종의 번역기나 변환기 역할을 수행하는 계층으로, 표현 방식이 다른 애플리케이션이나 시스템 간의 통신을 돕기 위해 하나의 통일된 구문 형식으로 변환시키는 기능을 수행합니다.

MIME 인코딩이나 암호화, 압축, 코드 변환과 같은 동작이 이 계층에서 이루어집니다.

7계층(Application)

7계층에서는 애플리케이션 프로세스를 정의하고 애플리케이션 서비스를 수행합니다. 네트워크 소프트웨어의 UI 부분이나 사용자 입.출력 부분을 정의하는 것이 애플리케이션 계층의 역할입니다.

계층별 주요 프로토콜 및 장비

계층	주요 프로토콜	장비
Application	HTTP, SMP, SMTP, STUN, TFTP, TELNET	ADC, NGFW, WAF
Presentation	TLS, AFP, SSH
Session	L2TP, PPTP, NFS, RPC, RTCP, SIP, SSH
Transport	TCP, UDP, SCTP, DCCP, AH, AEP	로드 밸런서, 방화벽
Network	ARP, IPv4, IPv6, NAT, IPSec, VRRP, 라우팅 프로토콜	라우터, L3 스위치
Data link	IEEE 802.2, FDDI	스위치, 브릿지, 네트워크 카드
Physical	RS-232, RS-449, V.35, S 등의 케이블	케이블, 허브, 탭(TAP)

인캡슐레이션과 디캡슐레이션

상위 계층에서 하위 계층으로 데이터를 보내는 것을 인캡슐레이션, 다시 하위 계층으로 전기신호를 받아 상위계층으로 데이터를 보내는 것을 디캡슐레이션이라고 합니다.

인캡슐레이션 과정에서 4계층, 3계층, 2계층은 아래로 내려가면서 네트워크 전송을 위한 정보를 헤더에 붙여넣습니다.

헤더의 정보는 많지만 아래 2가지는 반드시 포함되어야 합니다.

현재 계층에서 정의하는 정보
- 4계층 : 데이터 순서, 빠진 패킷은 없는지 등등 (시퀀스, 에크 번호)
- 3계층 : 논리적 주소인 출발지, 도착지 IP 주소
- 2계층 : 출발지, 도착지 MAC 주소
상위 프로토콜 지시자
- 디캡슐레이션 과정에서 어떤 상위 프로토콜로 올려보내줄지 결정하기 위해 필요

MTU 와 MSS
MTU : 2계층의 최대 데이터 값, 1500바이트
MSS : 4계층의 최대 데이터 값, 1460바이트

1. 네트워크 연결 구분

네트워크는 규모와 관리 범위에 따라 LAN, MAN, WAN 3가지로 구분됩니다.

LAN : Local Area Network 의 약자로 홈 네트워크용과 사무실용 네트워크처럼 비교적 소규모의 네트워크를 말합니다. 먼 거리를 통신할 필요가 없어 스위치와 같이 비교적 간단한 장비로 연결된 네트워크입니다.

WAN : WAN은 Wide Area Network 의 약자로 먼 거리에 있는 네트워크를 연결하기 위해 사용합니다. 멀리 떨어진 LAN을 서로 연결하거나 인터넷에 접속하기 위한 네트워크가 WAN에 해당합니다.

2. 네트워크 회선

2.1 인터넷 회선

인터넷 접속을 위해 통신사업자와 연결하는 회선을 인터넷 회선이라고 부릅니다. 가입자와 통신사업자 간에 직접 연결되는 구조가 아니라 전송 선로 공유 기술을 사용합니다.

전송 선로를 공유하므로 일반 인터넷 회선의 속도는 전송 가능한 최대 속도이고 전용 회선과 달리 그 속도를 보장하지 않습니다.

2.2 전용 회선

가입자와 통신사업자 간에 대역폭을 보장해주는 서비스를 대부분 전용 회선이라고 부릅니다. 인터넷 전용 회선이 아닌 일반 전용 회선은 본사-지사 연결에 주로 사용됩니다.

2.3 인터넷 전용 회선

인터넷 연결 회선에 대한 통신 대역폭을 보장해주는 상품을 인터넷 전용 회선이라고 합니다. 가입자가 통신사업자와 연결되고 이 연결이 다시 인터넷과 연결되는 구조입니다.

인터넷 전용 회선은 가입자가 일반가정에서 사용하는 접속 기술과 달리 다른 가입자와 경쟁하지 않고 통신사업자와 가입자 간의 연결 품질을 보장해줍니다.

2.4 VPN

VPN 은 Virtual Private Network 의 약자로 물리적으로는 전용선이 아니지만 가상으로 직접 연결한 것 같은 효과가 나도록 만들어주는 네트워크 기술입니다. VPN 은 통신사업자 VPN 과 가입자 VPN 기술이 있습니다.

2.4.1 통신사업자 VPN

MPLS VPN 을 사용합니다. 이 기술을 이용하면 여러 가입자가 하나의 망에 접속해 통신하므로 공용 회선을 함께 이용하게 되어 비용이 낮아집니다. MPSL VPN 회선은 거리보다 속도의 영향을 받으므로 거리가 멀어질수록 공용망 기술 사용이 비용을 낮추는 데 도움이 됩니다. 도시 내부 통신 외 본사 - 지사 또는 지사 - 지사 간의 연결은 대부분 MPLS VPN 기술을 사용합니다.

2.4.2 가입자 VPN

일반 사용자가 VPN 을 사용한다면 대부분 가입자 VPN 기술입니다. 일반 인터넷망을 이용해 사용자가 직접 가상 전용 네트워크를 구성하기 때문에 비용이 MPLS VPN 보다 저렴합니다.

2.5 DWDM

DWDM(Dense Wavelength Division Multiplex, 파장 분할 다중화) 전송 기술은 먼 거리를 통신할 때 케이블 포설 비용이 많이 들고 관리가 어려운 문제를 극복하기 위해 개발되었습니다. DWDM 기술은 하나의 광케이블에 다른 파장의 빛을 통해 여러 채널을 만드는 동시에 많은 데이터를 전송할 수 있습니다.

3. 네트워크 구성 요소

3.1 네트워크 인터페이스 카드 (NIC)

네트워크 인터페이스 카드는 컴퓨터를 네트워크에 연결하기 위한 하드웨어 장치입니다.

직렬화(Serialization) : 전기 신호를 데이터 신호로, 또는 데이터 신호를 전기 신호로 변환하는 작업을 합니다.
MAC 주소 : NIC 은 MAC 주소를 가집니다.
흐름 제어 : 패킷 기반 네트워크에서는 다양한 통신이 하나의 채널을 이용하므로 이미 통신 중인 데이터 처리 때문에 새로운 데이터를 받지 못할 수 있습니다. 이런 현상으로 인한 데이터 유실 방지를 위해 데이터를 받지 못할 때는 상대방에게 통신 중지를 요청할 수 있습니다. 이 작업을 흐름 제어라고 합니다.

3.2 허브

허브는 1계층에서 동작하는 장비입니다. 허브는 단순히 들어온 신호를 모든 포트로 내보내기 때문에 모든 단말이 경쟁하게 되어 전체 너트워크 성능이 줄어듭니다. 또한 패킷이 무환 순환하여 네트워크 전체를 마비시키는 문제도 있어 현재 거의 사용하지 않습니다.

3.3 스위치

스위치(Switch)는 허브와 동일하게 여러 장비를 연결하고 통신을 중재하는 2계층 장비입니다. 스위치는 허브와 달리 MAC 주소를 이해할 수 있어 목적지 MAC 주소의 위치를 파악하고 목적지가 연결된 포트로만 전기 신호를 보냅니다.

3.4 라우터

라우터는 OSI 7계층 중 3계층에서 동작하면서 먼 거리로 통신할 수 있는 프로토콜로 변환합니다.

3.5 로드 밸런서

로드 밸런서는 OSI7 계층 중 4계층에서 동작합니다. 로드 밸런서는 4계층 포트 주소를 확인하는 동시에 IP 주소를 변경할 수 있습니다. 로드 밸런서가 가장 많이 사용되는 서비스는 웹입니다. 웹 서버를 증설하고 싶을 때 로드 밸런서를 웹 서버 앞에 두고 웹 서버를 여러 대로 늘려줍니다. 대표 IP는 로드 밸런서가 갖고 로드 밸런서가 각 웹 서버로 패킷의 목적지 IP 주소를 변경해 보내줍니다.

3.6 보안장비 (방화벽 / IPS)

방화벽은 OSI7계층 중 4계층에서 동작해 방화벽을 통과하는 패킷의 3, 4계층 정보를 확인하고 패킷을 정책과 비교해 버리거나 포워딩합니다.

유니캐스트, 멀티캐스트, 브로드캐스트, 애니캐스트

네트워크에서 출발지 ~ 목적지로 데이터를 전송할 때 사용하는 통신 방식입니다.

유니캐스트 : 1:1 통신입니다.
브로드캐스트 : 동일 네트워크 내 모든 호스트로 통신합니다.
멀티캐스트 : 하나의 출발지에서 다수의 특정 목적지로 통신합니다.
애니캐스트 : 1:1 통신으로, 다수의 동일 그룹 중 가장 가까운 호스트가 응답합니다.

MAC 주소

MAC (Media Access Control) 주소는 2계층(데이터 링크 계층)에서 통신을 위해 네트워크 인터페이스에 할당된 고유 식별자입니다.

MAC 주소는 48비트의 16진수 12자리로 표현됩니다. 48비트의 MAC 주소는 다시 제조사 코드의 앞 24비트와 제조사 임의 코드인 뒤의 24비트로 나누어 구분됩니다.

NIC 은 자신의 MAC 주소를 가지고 있으면서 전기 신호가 들어오면 해당 신호의 도착지 MAC 주소를 확인합니다. 만약 도착지 MAC 주소가 자신이 갖고 있는 MAC 주소와 다르면 그 패킷을 폐기하고, 같으면 상위 계층으로 넘깁니다.

IP 주소

IPv4 주소는 8비트 단위의 옥텟 4개로 이루어져있는 32비트 주소체계입니다.

A 클래스는 $2^{24}$ 개, B 클래스는 $2^{16}$ 개, C 클래스는 $2^{8}$ 개의 IP 를 표현할 수 있습니다. 하지만 IP 체계에서 맨 앞의 숫자를 네트워크 주소로, 맨 뒤의 숫자를 브로드캐스트 주소로 사용하므로 실제로 사용할 수 있는 IP는 2개 적습니다.

클래스리스, CIDR 기반 주소 체계

기존 클래스 기반 주소 체계는 주소 낭비가 심했기 때문에 지금은 CIDR(Classless Inter-Domain Routing) 기반의 주소 체계를 사용합니다. 클래스리스 네트워크에서는 별도로 네트워크와 호스트 주소를 나누는 구분자를 사용해야 하는데 이 구분자를 서브넷 마스크(Subnet Mask)라고 부릅니다.

예를 들어 103.9.32.146 주소에 서브넷 마스크가 255.255.255.0 이라면 네트워크 주소는 103.9.32.0, 호스트 주소는 0.0.0.146 입니다. 또한 아래와 같이 클래스 기준을 무시하고 네트워크를 쪼개 사용할 수 있는데 이를 서브네팅(Subnetting) 이라고 합니다.

TCP 와 UDP

4계층에서 동작하는 프로토콜은 목적지 단말 안에서 동작하는 여러 애플리케이션 프로세스 중 통신해야 할 목적지 프로세스를 정확히 찾아가고 패킷 순서가 바뀌지 않도록 잘 조합해 원래 데이터를 잘 만들어내기 위한 역할을 합니다.

TCP

패킷 순서, 응답 번호

TCP 에서는 시퀀스 번호로 패킷에 순서를 부여하고, ACK 번호로 응답 번호를 부여합니다. 이를 통해 순서가 바뀌거나 패킷이 손실된 것을 파악할 수 있습니다.

이때 패킷을 하나 보내고 응답을 받는 것이 아니라 많은 패킷을 한꺼번에 보내고 응답을 하나만 받습니다. 이 패킷의 적정 송신량을 윈도 사이즈라고 하며 네트워크 상황에 따라 윈도 사이즈를 조절하는 것을 슬라이딩 윈도라고 합니다.

TCP 헤더에서 표현할 수 있는 최대 크기의 윈도 사이즈는 $2^{16}$ 으로 64K 지만 현대 네트워크에서는 너무 작은 숫자입니다. 점점 고속화, 안정화되는 환경에 적응하기 위해 윈도 사이즈를 64K보다 대폭 늘려 통신하는데 TCP 헤더는 변경이 불가능하므로 헤더 사이즈를 늘리지 않고 뒤의 숫자를 무시하는 방법으로 윈도 사이즈를 증가시켜 통신합니다. 이런 방법을 사용하면 기존 숫자에 10배, 100배로 윈도 사이즈가 커집니다. TCP는 데이터에 유실이 발생하면 윈도 사이즈를 절반으로 떨어뜨리고 정상적인 통신이 되는 경우, 서서히 하나씩 늘립니다.

3-way handshake

![image-20231011143014722](../../hobeen-kim.github.io/images/2023-10-10-[IT 엔지니어를 위한 네트워크 입문] Ch.03 네트워크 통신하기/image-20231011143014722.png)

3-way handshake 는 통신 시작 전의 사전 연결 작업입니다.

서버에서는 서비스를 제공하기 위해 클라이언트의 접속을 받아들일 수 있는 LISTEN 상태로 대기합니다.
클라이언트에서 통신을 시도할 때 Syn 패킷을 보내고 SYN-SENT 상태가 됩니다.
클라이언트의 Syn을 받은 서버는 SYN-RECEIVE 상태로 변경되고 Syn, Ack로 응답합니다.
이 응답을 받은 클라이언트는 ESTABLISHED 상태로 변경하고 그에 대한 응답을 서버로 다시 보냅니다.
서버에서도 클라이언트의 이 응답을 받고 ESTABLISHED 상태로 변경됩니다. ESTABLISHED 상태는 서버와 클라이언트 간의 연결이 성공적으로 완료되었음을 나타냅니다.

이러한 3-way handshake 와 기존 통신을 구분하기 위해 헤더에 Flag 를 넣습니다.

TCP 플래그는 총 6가지가 있고 통신의 성질을 나타냅니다. 초기 연결, 응답, 정상 종료, 비정상 종료 등의 용도로 사용됩니다.

SYN :연결 시작 용도로 사용합니다. 연결이 시작될 때 SYN 플래그에 1로 표시해 보냅니다.
ACK : ACK 번호가 유효할 경우, 1로 표시해 보냅니다. 초기 SYN이 아닌 모든 패킷은 기존 메시지에 대한 응답이므로 ACK 플래그가 1로 표기됩니다.
FIN :연결 종료 시 1로 표시됩니다. 데이터 전송을 마친 후 정상적으로 양방향 종료 시 사용됩니다.
RST : 연결 종료 시 1로 표시됩니다. 연결 강제 종료를 위해 연결을 일방적으로 끊을 때 사용됩니다.
URG : 긴급 데이터인 경우, 1로 표시해 보냅니다.
PSH : 서버 측에서 전송할 데이터가 없거나 데이터를 버퍼링 없이 응용 프로그램으로 즉시 전달할 것을 지시할 때 사용됩니다.

UDP

UDP 는 4계층 프로토콜이 가져야 할 특징이 거의 없습니다. UDP는 음성 데이터나 실시간 스트리밍과 같이 시간에 민감한 프로토콜이나 애플리케이션을 사용하는 경우나 사내 방송이나 증권 시세 데이터 전송에 사용되는 멀티캐스트처럼 단방향으로 다수의 단말과 통신해 응답을 받기 어려운 환경에서 주로 사용됩니다.

UDP는 TCP와 달리 통신 시작 전, 3방향 핸드셰이크와 같이 사전에 연결을 확립하는 절차가 없습니다. 그 대신 UDP에서 첫 데이터는 리소스 확보를 위해 인터럽트(Interrupt)를 거는 용도로 사용되고 유실됩니다.

ARP

ARP(Address Resolution Protocol) 는 IP 주소 기반으로 MAC 주소를 알아내기 위해 사용되는 프로토콜입니다.

ARP 브로드캐스트

호스트에서 아무 통신이 없다가 처음 통신을 시도하면 상대방의 IP 주소는 알지만 MAC 주소는 모르기 때문에 ARP 브로드캐스트를 이용해 네트워크 전체에 상대방의 MAC 주소를 질의해야 합니다. ARP 브로드캐스트를 받은 목적지는 ARP 프로토콜을 이용해 자신의 MAC 주소를 응답합니다. 이 작업이 완료되면 출발지, 목적지 둘 다 상대방에 대한 MAC 주소를 학습하고 이후 패킷이 정상적으로 인캡슐레이션되어 상대방에게 전달될 수 있습니다.

패킷을 보낼 때마다 ARP 브로드캐스트를 수행하면 네트워크 통신의 효율성이 크게 저하되므로 메모리에 이 정보를 저장해두고 재사용합니다.

ARP 동작

서버 A는 목적지 서버 B의 MAC 주소(1.1.1.2 IP의 MAC 주소)를 알아내기 위해 ARP 요청을 네트워크에 브로드캐스트합니다. 이때 출발지 MAC 은 자신으로, 목적지 MAC 은 브로드캐스트인 FF-FF-FF-FF-FF-FF 로 채웁니다. 그리고 ARP 프로토콜 필드의 전송자 MAC과 IP 주소에는 자신의 주소로, 대상자 IP 주소는 10.1.1.2를, 대상자 MAC 주소는 00-00-00-00-00-00으로 채워 네트워크에 뿌립니다.

브로드 캐스트이므로 동일 네트워크의 모든 단말이 해당 요청을 받아서 ARP 프로토콜 필드의 대상자 IP가 자신이 맞는지 확인하고 자신이 아니면 ARP 패킷을 버립니다. 대상자가 맞다면 송신자와 대상자의 위치를 바꾸고 자신의 MAC 주소를 응답합니다.

ARP 동작 - 동일 네트워크가 아닐 떄

출발 호스트는 서브넷 마스크를 통해 목적지가 목적지 호스트가 다른 네트워크인지 확인합니다. 다른 네트워크면 출발 호스트는 목적지가 자신이 직접 보낼 수 없는 위치에 있다고 판단하고 ARP 요청을 기본 게이트웨이의 IP 주소로 요청합니다.

![image-20231011212747318](../../hobeen-kim.github.io/images/2023-10-10-[IT 엔지니어를 위한 네트워크 입문] Ch.03 네트워크 통신하기/image-20231011212747318.png)

게이트웨이는 데이터 포워딩 테이블을 참고해 패킷의 목적지 IP 주소가 있다면 출발 호스트에 자신의 MAC 주소를 적어 ARP Reply 를 보냅니다.

게이트웨이에서 ARP 응답을 받은 단말은 도착지 MAC 주소에 응답받은 기본 게이트웨이의 MAC 주소를 적어넣고 통신을 시작합니다.

스위치 장비 동작

스위치는 네트워크 패킷 전송 시 서로 간섭 없이 통신하도록 도와주는 장비입니다. 스위치는 단말의 주소인 MAC 주소와 단말이 위치하는 인터페이스 정보를 매핑한 MAC 주소 테이블을 갖고 있습니다. 이를 통해 패킷을 정확히 전송할 수 있습니다.

스위치의 핵심 역할은 누가 어느 위치에 있는지 파악하고 실제 통신이 시작되면 자신이 알고 있는 위치로 패킷을 정확히 전송하는 것입니다. 이런 동작은 스위치가 2계층 주소를 이해하고 단말의 주소인 MAC 주소와 단말이 위치하는 인터페이스 정보를 매핑한 MAC 주소 테이블을 갖고 있어서 가능합니다.

스위치 동작 방식은 다음 3가지로 정리됩니다.

플러딩 : 스위치는 부팅하면 아무런 정보가 없기 때문에 모든 포트로 패킷을 전달합니다. 이러한 동작 방식을 플러딩이라고 합니다.
어드레스 러닝 : MAC 주소 테이블을 만들고 유지하는 과정을 어드레스 러닝이라고 합니다.
포워딩/필터링 : 패킷이 스위치에 들어온 경우, 도착지 MAC 주소를 확인하고 자신이 가진 MAC 테이블과 비교해 맞는 정보가 있으면 매치되는 해당 포트로 패킷을 포워딩합니다. 이때 다른 포트로는 해당 패킷을 보내지 않으므로 이 동작을 필터링이라고 합니다.

VLAN

VLAN 은 물리적 배치와 상관없이 LAN 을 논리적으로 분할하는 기술입니다. 그리고 이렇게 분리된 단말 간에는 3계층 장비를 통해 통신하게 됩니다.

VLAN 의 종류와 특징

VLAN 은 포트 기반 VLAN 과 MAC 기반 VLAN 이 있습니다.

포트 기반 VLAN 은 스위치의 특정 포트가 VLAN 의 선정기준입니다. 반면 MAC 기반 VLAN 은 VLAN 을 할당하는 기준이 PC 의 MAC 주소입니다. 위 그림에서 AA PC 는 어떤 스위치의 어떤 포트에 접속하더라도 동일한 VLAN 10 이 할당됩니다.

VLAN 모드(Trunk/Access) 동작 방식

여러 개의 VLAN 이 존재하는 상황에서 스위치를 서로 연결해야 하는 경우에는 각 VLAN 끼리 통신하려면 VLAN 개수만큼 포트를 연결해야 합니다.

따라서 위와 같이 VLAN 을 3개 구성했다면 각 VLAN 간 통신에 필요한 3개의 포트가 필요합니다. VLAN 을 더 많이 사용하는 네트워크에서는 이렇게 VLAN별로 포트를 연결하면 장비 간의 연결만으로도 많은 포트가 낭비됩니다. 이 문제를 해결하기 위한 것이 VLAN 태그 기능입니다.

태그 기능은 하나의 포트에 여러 개의 VLAN 을 함께 전송할 수 있게 해줍니다. 이 포트를 태그(Tagged) 포트 또는 트렁크(Trunk) 포트라고 합니다.이렇게 통신하려면 이더넷 프레임 중간에 VLAN ID 필드를 끼워 넣어 이 정보를 이용합니다.

일반적인 포트를 언태그(Untagged) 포트 또는 액세스(Access) 포트라고 하고 VLAN 정보를 넘겨 여러 VLAN이 한꺼번에 통신하도록 해주는 포트를 태그 포트 또는 트렁크 포트라고 부릅니다.

STP

SPoF(Single Point of Failure: 단일 장애점) 로 인한 장애를 피하기 위해 스위치를 두 대로 디자인할 수 있습니다. 하지만 두 대 이상의 스위치로 디자인하면 패킷이 네트워크를 따라 계속 전송되므로 네트워크를 마비시킬 수 있습니다. 이런 상황을 네트워크 루프(Loop)라고 합니다.

스패닝 트리 프로토콜(Spanning Tree Protocol) 은 루프를 확인하고 적절히 포트를 사용하지 못하게 만들어 루프를 예방하는 메커니즘입니다. 용어 그대로 잘 뻗은 나무처럼 뿌리부터 가지까지 루프가 생기지 않도록 유지하는 것이 스패닝 트리 프로토콜의 목적입니다.

STP 는 루프를 예방하기 위해 전체 스위치가 어떻게 연결되어있는지 알아야 합니다. 이를 위해 BPDU(Bridge Protocol Data Unit) 라는 프로토콜로 스위치 간에 정보를 전달하고 수집된 정보로 전체 네트워크 트리를 만들어 루프구간을 확인합니다. BPDU 에는 고유한 ID 가 있어서 루프파악이 가능해지고, 이렇게 확인된 루프 지점을 데이터 트래픽이 통과하지 못하도록 차단해 루프를 예방합니다.

라우터의 동작 방식과 역할

라우터는 다양한 경로 정보를 수집해 최적의 경로를 라우팅 테이블에 저장한 후 패킷이 라우터로 들어오면 도착지 IP 주소와 라우팅 테이블을 비교해 최선의 경로로 패킷을 내보냅니다. 라우터는 패킷 포워딩 과정에서 기존 2계층 헤더 정보를 제거한 후 새로운 2계층 헤더를 만들어냅니다.

경로 지정

라우터의 가장 중요한 역할은 경로 지정으로, 패킷의 IP 주소를 확인해 적절한 경로로 패킷을 포워딩합니다. 라우터는 다양한 방법으로 경로를 얻는데, IP 주소를 입력하면서 자연스럽게 인접 네트워크 정보를 얻는 방법과 관리자가 직접 경로 정보를 입력하는 방법, 라우터끼리 서로 경로 정보를 자동으로 교환하는 방법이 있습니다.

브로드캐스트 컨트롤

2계층의 스위치는 패킷의 도착지 주소를 모르면 어딘가에 존재할지 모를 장비와의 통신을 위해 플러딩해 패킷을 모든 포트에 전송합니다. 2계층까지는 LAN 크기가 작기 때문에 전체 네트워크에 큰 무리가 가지 않습니다. 반면 3계층에서 목적지가 없거나 명확하지 않은 패킷이 플러딩된다면 인터넷에 쓸모 없는 패킷이 가득 차 통신불능 상태가 될 수 있습니다.

따라서 라우터의 기본 동작은 멀티캐스트 정보를 습득하지 않고 브로드캐스트 패킷을 전달하지 않습니다. 라우터의 이 기능을 이용해 브로드캐스트가 다른 네트워크로 전파되는 것을 막을 수 있습니다. 이 기능을 "브로드캐스트 컨트롤/멀티캐스트 컨트롤" 이라고 합니다.

프로토콜 변환

과거에는 LAN 과 WAN 에서 사용하는 프로토콜이 전혀 다랐습니다. 따라서 LAN 기술이 WAN 기술로 변환되어야만 인터넷과 같이 원격지 네트워크와의 통신이 가능했고 이 역할을 라우터가 담당했습니다.

라우터에 패킷이 들어오면 2계층까지의 헤더 정보를 벗겨내고 3계층 주소를 확인한 후 2계층 헤더 정보를 새로 만들어 외부로 내보냅니다. 그래서 라우터에 들어올 때의 패킷 2계층 헤더 정보와 나갈 때의 패킷 2계층 헤더 정보가 다른 것입니다. 이 기능을 이용하면 전혀 다른 기술 간 변환이 가능합니다.

경로 지정 - 라우팅/스위칭

라우터는 패킷을 처리할 때 크게 두 가지 작업을 합니다. 경로 정로를 얻어 경로 정보를 정리하는 역할과 정리된 경로 정보를 기반으로 패킷을 포워딩하는 역할입니다. 라우터에 들어온 패킷의 목적지 주소와 라우터가 갖고 있는 라우팅 테이블 정보가 정확히 일치하지 않더라도 수많은 정보 중 목적지에 가장 근접한 정보를 찾아 패킷을 포워딩해야 합니다.

라우팅 동작과 라우팅 테이블

라우터는 전체 경로를 모두 책임지는 게 아니라 인접한 라우터까지의 경로만 지정합니다. 그러면 인접 라우터에서 최적의 경로를 다시 파악한 후 라우터로 패킷을 포워딩합니다. 네트워크를 한 단계씩 뛰어넘는다는 의미로 이 기법을 홉-바이-홉(Hop-by-Hop) 라우팅이라고 부르고 인접한 라우터를 넥스트 홉(Next Hop) 이라고 부릅니다.

라우터가 패킷을 포워딩할 때 출발지는 고려하지 않고 목적지 주소와 라우팅 테이블을 비교해서 어느 경로로 포워딩할지 결정합니다. 따라서 라우팅 테이블에 저장하는 데이터는 아래 정보가 포함됩니다.

목적지 주소
넥스트 홉 IP 주소, 나가는 로컬 인터페이스(선택 가능, 보통은 넥스트 홉 IP 주소)

라우팅(라우터가 경로 정보를 얻는 방법)

라우터가 경로 정보를 얻는 방법은 크게 다음 3가지 방법으로 구분할 수 있습니다.

다이렉트 커넥티드
스태틱 라우팅
다이나믹 라우팅

다이렉트 커넥티드

IP 주소를 입력할 때 사용된 IP 주소와 서브넷 마스크로 해당 IP 주소가 속한 네트워크 주소 정보를 알 수 있습니다. 라우터나 PC에서는 이 정보로 해당 네트워크에 대한 라우팅 테이블을 자동으로 만듭니다. 이 경로 정보를 다이렉트 커넥티드(Direct Connected)라고 부릅니다.

스태틱 라우팅

관리자가 목적지 네트워크와 넥스트 홉을 라우터에 직접 지정해 경로 정보를 입력하는 것을 스태틱 라우팅(Static Routing)이라고 합니다.

다이나믹 라우팅

네트워크 상 경로는 계속 변화하고, 라우터가 다운되거나 하는 상황도 동적으로 대응할 수 있어야 합니다. 또한 네트워크 수가 많아지거나 연결이 복잡해지면 관리자가 직접 라우팅 테이블을 작성하는 것도 한계가 있습니다.

다이나믹 라우팅(Dynamic Routing )은 스태틱 라우팅의 이런 단점을 보완하기 위해 라우터끼리 자신이 알고 있는 경로 정보나 링크 상태 정보를 교환해 전체 네트워크 정보를 학습합니다. 주기적으로 또는 상태 정보가 변경될 때 라우터끼리 경로 정보가 교환되므로 라우터를 연결하는 회선이나 라우터 자체에 장애가 발생하면 이 상황을 인지해 대체 경로로 패킷을 포워딩할 수 있습니다.

스위칭(라우터가 경로를 지정하는 방법)

패킷이 들어와 라우팅 테이블을 참조하고 최적의 경로를 찾아 라우터 외부로 포워딩하는 작업을 스위칭이라고 합니다. 이 스위칭은 2계층의 스위치와 이름은 비슷하지만 다른 용어이며 3계층 장비인 라우터가 패킷 경로를 지정해 보내는 작업을 말합니다.

IP가 목적지인 패킷이 라우터로 들어온 경우, 라우터는 도착지 IP와 가장 가깝게 매치되는 경로 정보를 찾습니다. 이때 롱기스트 프리픽스 매치(Longest Prefix Match) 기법을 이용해 갖고 있는 경로 정보 중 가장 가까운 경로를 선택합니다.

라우팅 테이블과 도착지 정보가 매치되는 정보는 10.0.0.0/8, 10.1.0.0/16, 10.1.1.0/24입니다. 이중 10.1.1.0/24 가 앞의 두 라우팅 정보보다 더 많은 네트워크 정보가 목적지와 매치되므로 이 정보를 최선의 정보로 인식해 Eth 2 인터페이스 쪽으로 패킷을 내보내게 됩니다.

정확한 정보를 매치하는 이그잭트 매치(Exact Match)는 단순한 서치 작업으로 찾고 패킷을 처리할 수 있지만 롱기스트 매치처럼 부정확한 정보 중 가장 비슷한 경로를 찾는 작업은 더 많은 리소스를 소모합니다. 라우터에서 패킷이 들어올 때마다 이 작업을 수행하면 많은 리소스를 소모하게 됩니다. 따라서 대부분의 라우터는 캐시를 이용해 반복작업을 줄여줍니다.

라우팅 설정

라우터나 PC에 IP 주소, 서브넷 마스크를 입력하면 다이렉트 커넥티드 라우팅 테이블이 생성됩니다. 스태틱 라우팅은 관리자가 직접 추가해야 하는데, 네트워크 규모가 커지면 라우팅을 처리하는 데 어려움이 있습니다. 따라서 많은 라우팅 정보를 처리하기 위해 ISP 의 전용 라우터를 사용합니다.

네트워크가 몇 개 없는 간단한 네트워크 구조에서는 스태틱 라우팅으로 망을 유지하는 것이 가능하지만 일반적으로 IT 환경을 구축할 때는 SPoF(Single Point of Failure: 단일 장애점) 를 없애기 위해 두 개 이상의 경로를 유지하는데 이 경우, 대체 경로에 대한 고민이 필요합니다. 이런 대체 경로가 필요한 네트워크를 스태틱 라우팅만으로 구성하면 한 홉이 넘어간 네트워크 상태가 변경될 때 신속히 대응할 수 없습니다.

다이나믹 라우팅 프로토콜을 사용하면 관리자의 직접적인 개입 없이 라우터끼리 정보를 교환해 경로 정보를 최신으로 유지할 수 있습니다. 라우터끼리 경로 정보를 수집하고 전달하므로 관리자가 라우팅 정보를 직접 입력해줄 필요가 없습니다. 다이나믹 라우팅 뒤에 프로토콜이 붙는 것은 라우터끼리 자신들만의 프로토콜로 정보를 교환하기 때문입니다. 주기적으로나 특별한 변화가 있으면 경로 정보를 교환하므로 중간 경로에 문제가 발생하더라도 대체 경로를 찾는 작업이 자동으로 수행됩니다.

4계층 장비의 특징

4계층 장비는 TCP와 같은 4계층 헤더에 있는 정보를 이해하고 이 정보들을 기반으로 동작합니다. 기존 네트워크 장비와 다른 점으로, 세션 테이블과 그 안에서 관리하는 세션 정보가 있습니다. 그래서 4계층 이상에서 동작하는 로드 밸런서, 방화벽과 같은 장비를 ‘세션 장비’라고 부르기도 합니다.

로드밸런서

로드 밸런서는 서버나 장비의 부하를 분산시키기 위한 장비입니다. 로드밸런서는 4계층 이상에서 동작하면서 IP 주소나 4계층 정보, 애플리케이션 정보를 확인, 수정하는 기능이 있습니다. 가장 많이 쓰이는 분야는 웹 서버의 부하 분산입니다.

로드 밸런서는 동작하는 계층에 따라 보통 4계층과 7계층으로 나뉩니다.

L4 로드 밸런싱

TCP, UDP 정보(특히 포트 넘버) 를 기반으로 로드 밸런싱이 동작합니다. 최근 로드 밸런서는 L4, L7의 기능을 모두 지원하지만, L7 지원 여부와 상관없이 4계층에 대한 정보로만 분산 처리하는 경우를 L4 로드 밸런싱이라고 합니다.

L7 로드 밸런싱

HTTP, FTP, SMTP 와 같은 애플리케이션 프로토콜 정보를 기반으로 로드 밸런싱을 수행합니다. HTTP 헤더 정보나 URI 와 같은 정보를 기반으로 부하를 분산할 수 있습니다. 일반적으로 이런 장비를 ADC(Application Delivery Controller)라고 부르며 프록시(Proxy) 역할을 수행합니다.

L4 스위치

L4 스위치는 4계층의 로드밸런서로 내부 동작 방식은 4계층 로드 밸런서이지만 외형은 스위치처럼 여러 개의 포트를 가지고 있습니다. L4 스위치는 부하 분산, 성능 최적화, 리다이렉션 기능을 제공합니다.

L4 스위치 동작을 위해서는 가상 서버(Virtual Server), 가상 IP(Virtual IP), 리얼 서버(Real Server)와 리얼 IP(Real IP)를 설정해야 합니다. 가상 서버와 가상 IP 는 사용자가 바라보는 서비스이고 리얼 서버와 리얼 IP 는 실제 서비스입니다. L4 스위치는 가상 IP 를 리얼 IP 로 변환해줍니다. 이 과정에서 부하를 어떤 방식으로 분산할지 결정할 수 있습니다.

ADC

ADC(Application Delivery Controller)는 애플리케이션 계층에서 동작하는 로드 밸런서입니다. ADC 는 프록시로 동작하며 다양한 부하 분산, 정보 수정, 정보 필터링이 가능합니다. ADC는 이런 상세한 동작을 위해 프락시로 동작합니다. 일부 소프트웨어 ADC를 제외한 대부분의 ADC는 L4 스위치의 기능을 포함하고 있습니다. 또한 Failover, Redirection 기능도 함께 수행합니다. 이 외에도 애플리케이션 프로토콜을 이해하면서 캐싱(Caching), 압축(Compression), 콘텐츠 변환 및 재작성, 인코딩 변환 등이 가능하고 애플리케이션 프로토콜 최적화 기능도 제공합니다.

ADC는 성능 최적화를 위해 서버에서 수행하는 작업 중 부하가 많이 걸리는 작업을 별도로 수행합니다. 그 중 하나가 이미지나 정적 콘텐츠 캐싱(Caching) 기능입니다. 또한 ADC 는 SSL의 엔드 포인트로 동작해 클라이언트에서 ADC까지의 구간을 SSL로 처리해주고 ADC와 웹 서버 사이를 일반 HTTP를 이용해 통신할 수 있습니다.

방화벽

네트워크 중간에 위치해 해당 장비를 통과하는 트래픽을 사전에 주어진 정책 조건에 맞추어 허용(Permit)하거나 차단(Deny)하는 장비를 방화벽이라고 부릅니다. 방화벽은 NAT(Network Address Translation) 동작 방식과 유사하게 세션 정보를 장비 내부의 세션 테이블 에 저장하고 패킷이 통과할 때 패킷이 외부에서 처음 시작된 것인지, 내부 사용자가 외부로 요청한 응답인지 가려냅니다.

세션 테이블 유지 및 세션 정보 동기화

세션 장비는 내부적으로 아래와 같은 방식으로 세션 테이블을 설정합니다.

3 way-handshake 를 통해 정상적으로 세션 설정
방화벽에서 세션 설정 과정을 확인하고 세션 테이블 기록
세션 테이블을 참조해 방화벽에서 패킷 통과
일정 시간 동안 통신이 없다면 세션 테이블 만료

이때 세션 장비의 세션 만료 시간이 애플리케이션의 세션 만료 시간보다 짧다면, 통신에 문제가 생길 수 있습니다. 중간 세션 장비의 세션 유지 시간이 지나 세션 테이블에 있는 세션 정보가 사라졌는데도 양쪽 단말에서는 세션이 유지되고 있다면 다시 통신이 시작되어 데이터를 보낼 때 중간 세션 장비에서 막히는 문제가 발생합니다. 이를 해결하기 위해 다음과 같은 방법을 사용할 수 있습니다.

세션 장비 운영자 입장

세션 만료 시간을 애플리케이션의 세션 유지 시간보다 길게 하는 방법이 있습니다. 이렇게 하려면 애플리케이션측에서 고유의 세션 유지 시간을 미리 알려줘야 합니다.
세션 테이블에 정보가 없는 패킷이 들어오면 세션 정보를 새로 만들 수 있습니다. 하지만 보안이 취약해집니다.
세션 장비에서 세션 타입아웃 시 양 종단장비에 세션 정보 만료(RST) 를 통보합니다. 애플리케이션에서 통신이 필요하면 새로운 세션을 맺어 통신합니다.

개발자 입장

애플리케이션에서 패킷을 주기적으로 발생시킵니다. 더미 패킷을 통해 세션 타임아웃 전에 세션을 계속 유지할 수 있습니다.

비대칭 경로 문제

네트워크의 안정성을 높이기 위해 네트워크 회선과 장비를 이중화한다면 패킷이 지나가는 경로가 2개 이상이므로 인바운드 패킷과 아웃바운드 패킷의 경로가 같거나 다를 수 있습니다. 이때 다른 장비를 통과하는 것을 비대칭 경로(Asymmetric Path)라고 부릅니다.

이를 처리하는 방법은 크게 두가지입니다.

첫 번째 방법은 세션 테이블을 동기화하여 두 장비가 하나의 장비처럼 동작하도록 하는 것입니다. 이 기능은 패킷 경로를 변경하지 않고 동작한다는 장점이 있지만 세션을 동기화하는 시간보다 패킷 응답이 빠르면 정상적으로 동작하지 않을 수 있다는 단점이 있습니다. 이 기능은 응답시간이 비교적 긴 인터넷 게이트웨이로 방화벽이 사용될 때 유용하게 사용될 수 있습니다.
두 번째 방법은 비대칭 경로가 생길 경우, 세션 장비에서 다양한 방법으로 이를 보정하는 것입니다. 인바운드 패킷이 통과하지 않았는데 아웃바운드 패킷이 장비로 들어온 경우, 인바운드 패킷이 통과한 다른 세션 장비 쪽으로 패킷을 보내 경로를 보정합니다. 그럼 강제로 대칭 경로를 만들어주므로 비대칭 경로로 인한 문제를 해결할 수 있습니다.

하나의 통신에 두 개 이상의 세션이 사용될 때의 고려사항

7.1 NAT/PAT

NAT (Network Address Translation) 은 네트워크 주소를 변환하는 기술로, 1:1 변환이나 여러 개의 IP 를 하나의 IP 로 변환하기도 합니다. 여기서 여러 개의 IP 를 하나의 IP 로 변환하는 기술은 NAT 으로 통칭되기도 하지만 실제로는 NAPT(Network Address Port Translation) 이고, 실무에서는 PAT 이라는 용어로 더 많이 사용됩니다. 사설 IP 에서 다른 사설 IP 나, 공인 IP 에서 다른 공인 IP 로 전환할 수도 있고, 사설 및 공인 IP 사이에서 전환할 수도 있습니다. 또는 IPv4 와 IPv6 를 변환하는 것도 NAT 기술입니다.

7.1.1 NAT/PAT 의 용도와 필요성

NAT 은 다양한 곳에서 사용되고 있습니다. 첫번째로 IPv4 주소 고갈 문제의 솔루션으로 사용됩니다.

두번째로는 보안을 강화하는 데 NAT 기술을 사용합니다. 외부와 통신을 할 때 내부 IP 를 다른 IP 로 변환해 통신하면 외부에 사내 IP 주소 체계를 숨길 수 있습니다. 그리고 내부 네트워크에서 외부 네트워크로 나가는 방향 통신은 허용하지만 외부에서 시작해 내부로 들어오는 통신은 방어할 수 있습니다. 이런 성질을 이용해 보안을 쉽게 강화할 수 있습니다.

세번째는 IP 주소 체계가 같은 두 개으 네트워크 간 통신을 가능하게 해줍니다. 사설 IP 는 서로 다른 회사에서 중복해 사용할 수 있습니다. 하지만 사설 IP 를 사용해 다른 회사와 직접 연결해야 한다거나 회사 간 합병에 의해 사설 IP 가 충돌할 수 있는데, 이를 연결하기 위해 "Double NAT" 기술을 사용할 수 있습니다.

네번째로 불필요한 설정 변경을 줄일 수 있습니다. 공인 IP 변경 등에 관계 없이 내부 사설 주소 쳬계의 설정 변경을 최소화할 수 있습니다.

7.1.2 NAT 통신 방식

사용자는 웹 서버에 접근하기 위해 출발지 IP를 10.10.10.10으로, 목적지 IP와 서비스 포트는 20.20.20.20과 80으로 패킷을 전송합니다. 출발지 서비스 포트는 임의의 포트로 할당됩니다. 여기서는 2000번 포트로 가정했습니다.
NAT 역할을 수행하는 장비에서는 사용자가 보낸 패킷을 수신한 후 NAT 정책에 따라 외부 네트워크와 통신이 가능한 공인 IP인 11.11.11.11로 IP 주소를 변경합니다. NAT 장비에서 변경 전후의 IP 주소는 NAT 테이블에 저장됩니다.
NAT 장비에서는 출발지 주소를 11.11.11.11로 변경해 목적지 웹 서버로 전송합니다.
패킷을 수신한 웹 서버는 사용자에게 응답을 보냅니다. 응답이므로 수신한 내용과 반대로 출발지는 웹 서버(20.20.20.20)가 되고 목적지는 NAT 장비에 의해 변환된 공인 IP 11.11.11.11로 사용자에게 전송합니다.
웹 서버로부터 응답 패킷을 수신한 NAT 장비는 자신의 NAT 테이블에서 목적지 IP에 대한 원래 패킷을 발생시킨 출발지 IP 주소가 10.10.10.10인 것을 확인합니다.NAT 변환 테이블에서 확인된 원래 패킷 출발지 IP(10.10.10.10)로 변경해 사용자에게 전송하면 사용자는 최종적으로 패킷을 수신합니다.

7.1.3 PAT 동작 방식

사용자가 웹 서버로 접근하기 위해 패킷에 출발지 10.10.10.10, 목적지 20.20.20.20, 목적지 서비스 포트는 웹 서비스 포트인 80으로 채워 패킷을 전송합니다. 출발지 서비스 포트는 NAT와 마찬가지로 임의의 서비스 포트가 할당되며 이 예제에서는 2000번 포트로 할당되었다고 가정합니다.
NAT 장비는 사용자가 보낸 패킷을 받아 외부 네트워크와 통신이 가능한 공인 IP인 11.11.11.11로 변경합니다. 다만 출발지에 있는 다수의 사용자가 동일한 공인 IP로 변환되어야 하므로 패킷의 주소 변경 시 출발지 IP뿐만 아니라 출발지의 서비스 포트도 변경됩니다. 출발지 IP와 출발지 서비스 포트는 NAT 장비에 의해 모두 변경되고 NAT 장비가 이 변경 정보를 NAT 테이블에 기록합니다.
NAT 장비에서 변경된 출발지 IP 주소인 11.11.11.11과 서비스 포트 3000으로 패킷을 재작성해 웹 서버로 다시 전송합니다.
사용자가 보낸 패킷을 수신한 웹 서버는 사용자에게 패킷을 응답하는데 출발지 IP는 웹 서버의 IP 주소인 20.20.20.20으로 채워지고 목적지 IP는 NAT 장비에 의해 변환된 공인 IP 11.11.11.11과 서비스 포트로 채워져 전송합니다.
웹 서버로부터 응답 패킷을 수신한 NAT 장비는 NAT 테이블을 확인해 웹 서버로부터 받은 패킷의 목적지 IP 주소인 11.11.11.11이 원래 10.10.10.10 이며 서비스 포트 3000 이 원래 2000인 것을 확인합니다.
NAT 장비는 NAT 테이블에서 확인한 목적지 IP 주소와 서비스 포트로 패킷을 재작성한 후 사용자에게 전달합니다. 사용자는 NAT 장비에서 역변환된 패킷을 받아 웹 페이지를 표시합니다.

이 때 서비스 포트가 모두 사용 중이거나 재사용할 수 없을 때 PAT 이 정상작동하지 않으므로 동시 사용자가 매우 많을 때는 PAT 에서 사용하는 공인 IP 주소를 IP 하나가 아닌 풀(Pool) 로 구성해야 합니다.

7.1.4 SNAT 와 DNAT

SNAT (Source NAT) - 출발지 주소를 변경하는 NAT
DNAT(Destination NAT) - 도착지 주소를 변경하는 NAT
NAT와 DNAT의 기준은 NAT가 수행되기 이전의 트래픽이 출발하는 시작 지점입니다. 즉, 요청 시 SNAT를 해 목적지로 전송하면 해당 트래픽에 대한 응답을 받을 때는 출발지와 목적지가 반대가 되므로 DNAT가 되는데 이때 트래픽을 요청하는 시작 지점만 고려해 SNAT 설정을 해야 합니다.

7.1.4.1 SNAT 와 DNAT 의 사용

SNAT 은 사설에서 공인으로 통신할 때 많이 사용되며, 실제 IP 를 숨기기 위한 보안 목적으로도 사용됩니다. 또한 출발지와 목적지 서버가 동일한 대역일 떄 로드밸런서를 거치게 하기 위해 사용될 수도 있습니다.

DNAT 은 로드밸런서에 많이 사용됩니다. 사용자가 서비스 요청을 위해 로드밸런서로 요청을 보내면 로드 밸런서는 서비스 VIP 를 로드 밸런싱될 서버의 실제 IP 로 DNAT 합니다. 또한 사내가 아닌 대외망과의 네트워크 구성에도 DNAT 을 사용합니다. 대외망과 연동할 때 IP 가 중복될 수도 있고, IP 주소가 제각각이므로 NAT 장비를 이용해 대외사의 IP 를 특정 IP 대역으로 NAT 합니다.

7.1.5 동적 NAT 와 정적 NAT

출발지와 목적지 IP 가 1:1 로 미리 매핑된 NAT 를 정적 NAT 라고 합니다. 반대로 출발지나 목적지가 정해지지 않고 다수 IP 풀에서 정해지는 ANT 를 동적 ANT 라고 합니다.

7.2 DNS

DNS(Domain Name Service) 는 문자열로 된 도메인 주소를 실제 통신에 필요한 IP 주소로 변환하는 기술입니다.

사용자가 웹 브라우저에 naver.com 을 입력하면 DNS 서버에 naver.com 의 주소가 무엇인지 질의하고 DNS 서버는 naver.com 의 IP 주소를 사용자에게 알려줍니다. 사용자는 해당 IP 주소로 naver.com 에 접속하게 됩니다.

7.2.2 DNS 구조와 명명 규칙

www.naver.com 의 경우 맨 뒤에 생략된 루트(.) 를 시작으로 Top-Level(com), Second-Level(naver), Third-Level(www) 와 같이 뒤에서 앞으로 해석됩니다.

7.2.2.1 루트 도메인

DNS 서버에 해당 도메인의 정보가 없다면 루트 도메인을 관리하는 루트 DNS 에 쿼리를 하게 됩니다. 루트 DNS 는 전 세계에 13개가 있고 DNS 서버를 설치하면 루트 DNS 의 IP 주소를 기록한 힌트 파일이 있어 별도의 설정이 필요없습니다.

7.2.2.2 Top-Level Domain (TLD)

TLD 는 6가지 유형이 있습니다.

Generic (gTLD) : com, edu, gov, int, mil, net , .org
Country Code TLD (ccTLD) : 국가 코드
Sponsored (sTDL) : 특정 목적을 위한 스폰서 (aero, asia, museum 등)
Ifrastructure : 운용상 중요한 인프라 식별자 공간. .arpa
Generic restricted (grTLD) : 특정 기준을 충족하는 사람이나 단체가 사용. biz, name, pro
Test (tTLD) : IDN 개발 프로세스에서 테스트 목적으로 사용. test

7.2.3 DNS 동작 방식

도메인을 IP 주소로 변환하려면 DNS 서버에 쿼리가 필요하지만, 로컬의 hosts 파일에서 관리할 수도 있습니다. hosts 파일에 도메인과 IP 주소를 설정해두면 해당 도메인 리스트는 항상 DNS 캐시에 저장됩니다.

도메인을 쿼리하면 먼저 로컬에 있는 DNS 캐시 정보를 먼저 확인하고, 캐시에 필요한 도메인 정보가 없으면 DNS 서버로 쿼리를 수행한 뒤 해당 결과를 캐시에 저장합니다.

DNS 서버에서도 모든 데이터를 가지고 있을 수 없기 때문에 자신이 가진 정보가 아니면 다른 DNS 에 질의해 결과를 받습니다.

사용자 호스트는 ‘zigispace.net’이라는 도메인 주소의 IP 주소가 로컬 캐시에 저장되어 있는지 확인합니다.
‘zigispace.net’이 로컬 캐시에 저장되어 있지 않으면 사용자 호스트에 설정된 DNS에 ‘zigispace.net’에 대해 쿼리합니다.
DNS 서버는 ‘zigispace.net’이 로컬 캐시와 자체에 설정되어 있는지 직접 확인하고 없으면 해당 도메인을 찾기 위해 루트 NS에 .net에 대한 TLD 정보를 가진 도메인 주소를 쿼리합니다.
루트 DNS는 ‘zigispace.net’의 TLD인 ‘.net’을 관리하는 TLD 네임 서버 정보를 DNS 서버에 응답합니다.
DNS는 TLD 네임 서버에 ‘zigispace.net’에 대한 정보를 다시 쿼리합니다.
TLD 네임 서버는 ‘zigispace.net’에 대한 정보를 가진 zigi 네임 서버에 대한 정보를 DNS 서버로 응답합니다.
DNS는 zigi 네임 서버에 ‘zigispace.net’에 대한 정보를 쿼리합니다.
zigi 네임 서버는 ‘zigispace.net’에 대한 정보를 DNS 응답합니다.
DNS는 ‘zigispace.net’에 대한 정보를 로컬 캐시에 저장하고 사용자 호스트에 ‘zigi space.net’에 대한 정보를 응답합니다.
사용자 호스트는 DNS로부터 받은 ‘zigispace.net’에 대한 IP 정보를 이용해 사이트에 접속합니다.

7.2.4 마스터와 슬레이브

DNS 서버는 마스터와 슬레이브 서버로 나눌 수 있습니다. 마스터 서버는 도메인에 대한 존 파일을 직접 관리하고, 슬레이브 서버는 마스터에 만들어진 존 파일을 복제합니다. 이를 영역 전송이라고 합니다.

도메인 영역 전송 시에 마스터 서버는 인가받지 않은 다른 DNS 서버가 복제해가지 못하도록 슬레이브 서버를 지정해 복제를 제한해야 합니다.

DNS 마스터 서버와 슬레이브 서버는 이중화에서 일반적으로 사용하는 액티브-스탠바이나 액티브-액티브 형태로 구성하지 않습니다. 마스터 서버에서 문제가 생기면 일정 시간 이후 슬레이브 서버도 도메인에 대한 질의에 정상적으로 응답하지 못해게 만료시간(expiry Time) 을 SOA 레코드에 설정합니다. 따라서 만료 시간 안에 마스터 서버를 복구하거나 슬레이브 서버를 마스터 서버로 전환해야 합니다.

7.2.5 DNS 주요 레코드

A(IPv4) 레코드 : 기본 레코드로 도메인 주소를 IP 주소로 변환하는 레코드. 도메인과 IP 를 1:N 또는 N:1 로 매핑할 수도 있음
- aws 의 A 레코드는 Alias 로 설정할 수 있는데, IP 주소대신 AWS 내 도메인 이름을 사용하여 참조할 수 있음 (Route 53 에 특화된 서비스) 루트 도메인에과 서브 도메인에 모두 사용할 수 있음
AAAA(IPv6) 레코드 : IPv6 에서 사용되는 레코드. A 레코드와 역할이 같음
CNAME(Canonical Name) 레코드 : CNAME 레코드는 도메인 주소를 매핑함. 네임 서버가 CNAME 레코드에 대한 질의를 받으면 CNAME 레코드에 설정된 도메인 정보를 확인하고 그 도메인 정보를 내부적으로 다시 질의한 결과 IP 값을 응답함
- 예를 들어서 www.naver.com 과 naver.com 이 같은 IP 를 매핑할 때, www 서브 도메인은 naver.com 도메인을 참조하도록 하면 IP 가 변경되었을 때 한곳만 수정하면 됨
SOA (Start Of Authority) 레코드
- 도메인 영역에 대한 권한을 나타내는 레코드. 도메인 영역에서 SOA 레코드를 만들지 않으면 해당 도메인은 네임 서버에서 정상 동작하지 않음. 도메인 동기화에 필요한 타이머 값이나 TTL 값과 함께 도메인의 네임 서버나 관리자 정보도 SOA 레코드에 설정. 해당 도메인에 대해서는 다른 네임 서버에 질의하지 않고 직접 응답
NS (Name Server) 레코드
- 도메인에 대한 권한이 있는 네임 서버 정보를 설정하는 레코드. 하위 도메인에 대한 권한을 다른 네임 서버로 위임(Delegate) 하는 역할로도 사용
MX(Mail eXchange) 레코드 : 메일 서버를 구성할 때 사용되는 레코드
PTR (Pointer) 레코드 : IP 주소에 대한 질의를 도메인 주소로 응답하기 위한 레코드 (역방향 조회용 레코드). A 레코드와 달리 하나의 IP 주소에 대해 하나의 도메인 주소만 가짐. 주로 화이트 도메인 구성용으로 사용
TXT(TeXT) 레코드 : 도메인에 대한 설명과 같이 간단한 텍스트를 입력할 수 있음

7.2.6 DNS 에서 알아두면 좋은 내용

7.2.6.1 도메인 위임(DNS Delegation)

모든 레코드에 대해 네임 서버가 직접 관리하지 않고 일부 영역은 다른 곳에서 레코드를 관리하도록 위임할 수 있습니다. CDN, GSLB 를 사용하는 것이 대표적인 경우입니다. 특정 계층의 레코드를 위임하면 해당 레코드의 하위 계층은 함께 위임처리됩니다.

위 그림과 같이 post.zigispace.net 은 'B' GSLB 에서 관리합니다.

7.2.6.2 TTL

TTL 은 DNS 응답값이 로컬 캐시에 저장되는 시간입니다. 서비스 성지로가 도메인 정보의 갱신 빈도에 따라 TTL 값을 적절히 조절해야 합니다. 기본 TTL 값은 윈도우는 1시간, 리눅스는 3시간입니다.

그 밖의 기타 도메인 관련 시간은 아래와 같습니다.

refresh(새로 고침 간격): 보조 네임 서버에서 Zone Transfer를 통해 정보를 주기적으로 받아오는 주기
retry(다시 시도 간격): 보조 네임 서버가 주 네임 서버로 접근이 불가능할 때 재시도하는 주기
expire(다음 날짜 이후 만료): 보조 네임 서버가 주 네임 서버로부터 도메인 정보를 받아오지 못할 때 유지되는 시간. 해당 시간 동안 도메인 관련 정보를 받아오지 못하면 주 네임 서버에서 삭제된 것으로 간주하고 보조 네임 서버에서도 해당 도메인 정보를 삭제

7.2.6.3 화이트 도메인

KISA (한국인터넷 진흥원) 에서 불법적인 스팸메일을 차단하는 활동을 하고 있는데, 이를 위해 정상적인 도메인을 인증, 관리하는 제도가 '화이트 도메인' 입니다. 그리고 불법적인 사이트를 블랙리스트 정보로 관리해 메일 발송을 제한합니다. 이 실시간 블랙리스트를 RBL (Realtime Blackhole List, Realtime Blocking List) 이라고 합니다.

현재 보유 중인 도메인을 화이트 도메인으로 등록하며면 해당 도메인에 SPF 레코드 (Sender Policy Framework) 가 설정되어 있어야 합니다. 해당 레코드로 수신 메일 서버가 발송된 메일이 실제 메일 서버에 등록된 정보와 일치하는지 확인할 수 있습니다. 도메인에 SPF 레코드를 작성하려면 TXT 레코드를 사용합니다.

7.2.8 DNS 설정(Linux)

7.2.7 DNS 설정(window) 생략

DNS 패키지 (bind) 설치
1. yum install -y bind
외부에서 도메일 질의를 허용
1. 네임 서버 설정 파일(/etc/named.conf) 에서 option 안에 ‘listen-on port 53’, ‘listen-on-v6 port 53’, ‘allow-query’ 항목 값을 각각 any로 수정
도메인 영역을 관리하는 설정 파일(/etc/named.rfc1912.zones) 에서 신규 도메인 영역(zigispace.kr) 추가
1. ```
 zone "zigispace.kr" IN {
   				type master;
        file "zigispace.kr.zone";
        allow-update { none; };
};
```
  - 도메인 타입을 mater 로 지정
  - 존 파일 이름을 zigispace.kr.zone 으로 지
  - 동기화할 슬레이브 서버가 따로 없으므로 allow-update 는 none 으로 설정

존 파일 생성

기존 존 파일을 복사해 사용 -> cp /var/named/named.empty /var/named/zigispace.kr.zone

복사한 파일을 다음과 같이 수정

$TTL 3H
@       IN SOA ns.zigispace.kr. root.zigispace.kr(
                                      0       ; serial
                                      1D      ; refresh
                                      1H      ; retry
                                      1W      ; expire
                                      3H )    ; minimum
   NS    ns.zigispace.kr.
   A     10.10.10.20
ns A     10.1.1.5

존 파일에는 도메인에 대한 기존 SOA 레코드, NS 레코드, A 레코드 (10.10.10.20) 설정

존 파일을 bind 에서 사용할 수 있도록 권한 변경
1. chown root:named /var/named/zigispace.kr.zone

bind 서비스 데몬 실행
1. systemctl start named.service

7.2.9 호스트 파일 설정

hosts 파일을 이용해서 도메인-IP 주소 쿼리를 사용할 수 있습니다. 현대에 들어와서는 일반적으로 사용되지 않고, 테스트 목적 드응로 특정 도메인에 임의로 설정한 값으로 도메인을 접속할 때 이 hosts 파일을 사용할 수 있습니다. hosts 파일을 DNS 쿼리에 의한 결과보다 우선순위가 높습니다. 따라서 hosts 파일을 임의로 조작해 유해 사이트에 대한 접근을 유도할 때도 있습니다.

운영체제별 hosts 파일의 위치는 아래와 같습니다.

윈도우 : C:\window\Systems\System32\drivers\etc\hosts
리눅스 : /etc/hosts

7.3 GSLB

DNS 에서 동일한 레코드 이름으로 서로 다른 IP 주소를 동시에 설정하면 로드밸런싱이 가능합니다. 이를 DNS 로드밸런싱이라고 합니다. 하지만 DNS 는 비정상 상태의 IP 주소를 응답할 수 있으므로 서비스 가용성 향상 방법으로 부적합합니다.

GSLB (Global Server/Service Load Balancing) 는 DNS 의 이런 문제점을 해결해, DNS 와 동일하게 도메인 질의에 응답해주는 역할과 동시에 로드 밸런서처럼 등록된 도메인에 연결된 서비스가 정상적인지 헬스 체크를 수행합니다. 이런 이유로 GSLB 를 인텔리전스 DNS 라고도 부릅니다.

7.3.1 GSLB 동작 방식

사용자가 web.zigispace.net에 접속하기 위해 DNS에 질의합니다.
LDNS는 web.zigispace.net을 관리하는 NS 서버를 찾기 위해 root부터 순차 질의합니다.
zigispace.net을 관리하는 NS 서버로 web.zigispace.net에 대해 질의합니다.
DNS 서버는 GSLB로 web.zigispace.net에 대해 위임했으므로 GSLB 서버가 NS 서버라고 LDNS에 응답합니다.
LDNS는 다시 GSLB로 web.zigispace.net에 대해 질의합니다.
GSLB는 web.zigispace.net에 대한 IP 주솟값 중 현재 설정된 분산 방식에 따라 서울 또는 부산 데이터 센터의 IP 주솟값을 DNS에 응답합니다. 본 예제에서는 서울 데이터 센터의 서비스 IP인 1.1.1.1을 응답하는 것으로 가정합니다. GSLB가 응답하는 값은 GSLB에서 설정한 주기에 따라 서울과 부산 데이터 센터로 헬스 체크해 정상적인 값만 응답합니다.
GSLB에서 결괏값을 응답받은 LDNS는 사용자에게 web.zigispace.net이 1.1.1.1로 서비스하고 있다고 최종 응답합니다.

7.3.2 GSLB 구성 방식

GSLB 를 사용한 도메인 설정 방법은 두 가지입니다.

도메인 자체를 GSLB 로 사용

도메인에 대한 네임 서버를 GSLB 로 지정함
모든 레코드에 대한 질의가 GSLB 를 통해 이루어지므로 GSLB 에 부하를 주게 됨

도메인 내의 특정 레코드만 GSLB 로 사용

Alias 를 사용 (CNAME 레코드 사용)
위임(Deltegation) 사용 (NS 레코드 사용)
아래는 별칭을 통한 DNS 쿼리의 예입니다. 별칭(CNAME)을 이용해 GSLB를 사용하는 방법은 실제 도메인과 다른 별도의 도메인 레코드로 GSLB에 등록됩니다. 일반적으로 외부 CDN을 사용하거나 회사 내부에 GSLB를 사용해야 할 도메인이 많은 경우 한꺼번에 관리하기 위해 사용합니다.

사용자가 web.zigispace.net을 LDNS(1.1.1.1)로 질의
LDNS는 web.zigispace.net을 관리하는 NS 서버를 찾기 위해 root부터 순차적으로 질의
zigispace.net을 관리하는 DNS(2.2.2.2)에 web.zigispace.net의 주소 질의
DNS 서버는 LDNS에게 별칭으로 web.zigispace.net은 web.zigispace.gslb.net이 관리하고 있다는 응답 수신
다시 LDNS(1.1.1.1)는 gslb.net을 관리하는 NS 서버를 root부터 순차 질의
LDNS(1.1.1.1)는 zigispace.gslb.net을 관리하는 NS 서버인 GSLB(3.3.3.3)에 web.zigispace.gslb.net에 대해 질의
GSLB(3.3.3.3)는 LDNS(1.1.1.1)에 web.zigispace.gslb.net의 IP(10.10.10.10)를 응답
LDNS(1.1.1.1)는 해당 결괏값(10.10.10.10)을 사용자에게 최종 응답

아래는 NS 레코드를 이용해 위임하여 GSLB 를 사용하는 방법입니다. DNS 에서 특정 FQDN 에 대한 설정을 NS 레코드로 설정하면 해당 FQDN 에 대한 값을 NS 레코드의 값으로 설정된 네임 서버로 재질의합니다.

사용자가 web.zigispace.net을 LDNS(1.1.1.1)로 질의
LDNS는 web.zigispace.net을 관리하는 NS 서버를 찾기 위해 root부터 순차적으로 질의
zigispace.net을 관리하는 DNS(2.2.2.2)에 web.zigispace.net의 주소 질의
DNS(2.2.2.2)는 GSLB(3.3.3.3)가 web.zigispace.net을 관리한다고 응답
다시 LDNS(1.1.1.1)는 web.zigispace.net을 관리하는 NS 서버인 GSLB(3.3.3.3)에게 web.zigispace.net을 질의
GSLB(3.3.3.3)는 LDNS(1.1.1.1)에 web.zigispace.net의 IP를 응답
LDNS(1.1.1.1)는 해당 결괏값을 사용자에게 최종 응답

7.3.3 GSLB 분산 방식

서비스 제공의 가능 여부를 체크해 트래픽 분산
지리적으로 멀리 떨어진 다른 데이터 센터에 트래픽 분산
지역적으로 가까운 서비스에 접속해 더 빠른 서비스 제공이 가능하도록 분산
GSLB 는 round-robin, least connection, hashing 등 여러 분산 방식이 있습니다. 대부분 다음 두가지의 헬스 체크 모니터링 요소를 지원하고 있습니다.
서비스 응답 시간/지연(RTT/Latency)
IP 에 대한 지리(Geography) 정보
참고로 이러한 Geo 값은 사용자 기준이 아니라 Local DNS 와 GSLB 간 값입니다. 따라서 국내 사용자가 해외 DNS 서버를 사용하면 사용자의 서비스 접속시간이 더 길어질 수 있습니다.

7.4 DHCP

DHCP(Dynamic Host Configuration Protocol) 은 IP 를 동적으로 할당하는 데 사용되는 프로토콜입니다. IP 주소, 서브넷 마스크, 게이트웨이, DNS 정보를 자동으로 할당받아 사용할 수 있습니다.

7.4.1 DHCP 프로토콜

DHCP 는 서버/클라이언트로 동작하며 클라이언트의 서비스 포트는 68(bootpc), 서버의 서비스 포트는 67(bootps) 입니다.

7.4.2 DHCP 동작방식

DHCP Discover
- DHCP 클라이언트는 DHCP 서버를 찾기 위해 DHCP Discover 메시지를 브로드캐스트로 전송합니다.
DHCP Offer
- DHCP Discover를 수신한 DHCP 서버는 클라이언트에 할당할 IP 주소와 서브넷, 게이트웨이, DNS 정보, Lease Time 등의 정보를 포함한 DHCP 메시지를 클라이언트로 전송합니다.
DHCP Request
- DHCP 서버로부터 제안받은 IP 주소(Requested IP)와 DHCP 서버 정보(DHCP Server Identifier)를 포함한 DHCP 요청 메시지를 브로드캐스트로 전송합니다.
DHCP Acknowledgement
- DHCP 클라이언트로부터 IP 주소를 사용하겠다는 요청을 받으면 DHCP 서버에 해당 IP를 어떤 클라이언트가 언제부터 사용하기 시작했는지 정보를 기록하고 DHCP Request 메시지를 정상적으로 수신했다는 응답을 전송합니다.

DHCP 를 통해 IP 를 할당할 때 IP 임대 시간이 있습니다. 만약 임대시간이 만료되면 클라이언트에 할당된 IP 를 다시 IP Pool 로 회수합니다. 이때 다시 DHCP Discover 부터 시작해 IP 를 재할당받아야 합니다. 하지만 현재 클라이언트가 IP 를 사용 중인 경우 갱신(renewal) 과정을 거쳐 사용 중인 동안 IP 주소가 IP 풀에 다시 반환되지 않도록 합니다. 이 과정은 임대 시간의 50% 가 지나면 수행됩니다.

7.4.4 DHCP 릴레이

(7.4.3 DHCP 설치 과정 생략)

DHCP 클라이언트와 서버 간 전송되는 패킷은 모두 브로드캐스트로 아래와 같이 각 네트워크마다 DHCP 서버가 있어야 합니다.

하지만 여러 네트워크에서도 DHCP 릴레이 에이전트를 사용하면 다른 네트워크에서 DHCP 서버를 관리할 수 있습니다. 브로드캐스트로 전달되는 DHCP 패킷을 동일 네트워크 대역의 DHCP 릴레이 에이전트가 수신하면 DHCP 서버로 갈 수 있도록 이것을 유니캐스트로 변환합니다.

흐름은 아래와 같습니다.

8.1 서버의 네트워크 설정 및 확인

8.1.1 리눅스 서버 네트워크

일반적으로 리눅스에서 설정 파일이 텍스트 형태이고 텍스트를 직접 수정해 시스템 구성을 변경합니다.

8.1.1.1 CentOS 의 네트워크 설정

/etc/sysconfig/network-scripts 위치에 있습니다. 인터페이스에 대한 설정 파일이나 인터페이스 제어용 스크립트가 있습니다.

리눅스에서 인터페이스 설정파일을 수정하면 네트워크 서비스를 재시작하거나 인터페이스를 재시작해야 합니다.

네트워크 서비스 재시작 : systemctl restart network.service
특정 인터페이스 다운 : ifdown ifcfg-eth0
특정 인터페이스 업 : ifdown ifcfg-eth0

8.1.1.2 우분투의 네트워크 설정

/etc/network/interfaces 에 설정파일이 있습니다. CentOS 와는 다르게 우분투는 interfaces 설정 파일에 네트워크의 모든 인터페이스 설정이 들어갑니다. 우분투에서 네트워크 서비스를 시작/정지/재시작하기 위해서는 다음 명령어를 사용합니다.

/etc/init.d/networking start
/etc/init.d/networking stop
/etc/init.d/networking reload
/etc/init.d/networking restart
/etc/init.d/networking force-reload

8.2 서버의 라우팅 테이블

서버에서도 라우팅 테이블을 가지고 있는데, 따로 설정하지 않더라도 디폴트 라우팅 테이블이 등록됩니다. 하지만 아래와 같이 네트워크 어댑터를 두 개 이상 사용할 때 여러 가지 고려사항이 생길 수 있습니다.

두 네트워크 어댑터에 모두 다폴트 게이트웨이 설정을 하면 정상적으로 통신이 되지 않습니다. 외부 공인망 네트워크와 통신해야 하는 프론트엔드 네트워크 쪽 어댑터만 디폴트 게이트웨이를 설정하고 백엔드를 연결하는 어댑터에는 별도로 적절한 라우팅 정보를 반드시 설정해주어야 합니다.

8.2.1 서버의 라우팅 테이블

서버의 라우팅 테이블 항목은 보통 아래와 같은 항목을 갖습니다.

목적지(Destination)
서브넷(Genmask)
게이트웨이(Gateway)
인터페이스(Iface)
우선순위(Metric)

목적지와 서브넷은 서버가 통신하려는 목적지 IP 주소에 맞는 라우팅을 선택하는 기준이 됩니다. 게이트웨이는 목적지로 가기 위해 선택하는 넥스트 홉입니다. 인터페이스는 서버의 네트워크 카드를 말하고, 라우팅에서 어떤 물리적인 경로로 패킷을 내보낼지 설정합니다. 마지막으로 우선순위는 동일한 라우팅 테이블이 두 개 이상 존재할 때 어떤 라우팅 테이블을 선택할지 정하는 값입니다. 값이 낮을수록 우선순위가 높아집니다.

8.3 네트워크 확인을 위한 명령어

8.3.1 ping(Packet InterNet Groper)

ping 은 ip 네트워크를 통해 특정 목적지까지 네트워크가 잘 동작하고 있는지 확인하는 명령어입니다. 또한 라우팅 경로가 정상적으로 구성되어 있는지도 함께 체크할 수 있습니다. ICMP(Internet Control Message Protocol) 라는 인터넷 프로토콜을 사용합니다.

ping [옵션] 목적지_ip_주소

ping 에서 사용되는 주요옵션은 아래와 같습니다. (linux 기준)

-c count : ping 을 보내는 패킷을 몇 번 보내고 종료할 것인지 지정. 기본 설정은 강제 종료 시까지 지속
-i interval : 패킷을 보내는 시간 간격. 기본 설정값은 1초. 슈퍼 유저의 경우 0.2 이하로 설정 가능
-I interface : 패킷을 보낼 때 출발지 주소를 지정.
-s packetsize : 패킷 크기를 지정. 기본 설정값은 56바이트(8바이트 ICMP 헤더가 추가로 붙어 64바이트를 송신)

8.3.3 traceroute(리눅스) / tracert (윈도)

traceroute 는 출발지부터 통신하거나 목적지까지의 네트워크 경로를 확인할 때 사용하는 네트워크 명령어입니다. ping 보다 더 상세한 중간 경로 정보를 얻는 데 사용됩니다. traceroute 는 IP 헤더의 TTL 필드를 이용해서 TTL 을 1 부터 증가시키면서 목적지에 도달할 때까지 패킷을 반복적으로 전송하면서 경로를 추적합니다.

아래와 같이 경로가 추적됩니다.

8.3.4 tcptraceroute

tcptraceroute 명령어는 traceroute 와 유사하게 출발지와 목적지까지의 경로를 확인하지만 실제 서비스 포트를 이용해 경로를 추적하므로 최종 목적지까지 서비스 포트가 정상적으로 열리는지 확인할 수 있습니다.

8.3.5 netstat

netstat 은 다양한 네트워크 상태를 확인하는 데 사용됩니다. 사용범위가 매우 넓지만 서비스 포트 상태를 확인하는 용도로 가장 많이 사용됩니다. 현재 서버에서 특정 서비스가 정상적으로 열려 있는지, TCP 세션이 정상적으로 맺어져 있는지 등을 netstat 명령어로 확인할 수 있습니다.

8.3.6 ss (socket statistics)

ss 는 소켓 정보를 확인할 수 있는 네트워크 명령어입니다. netstat 명령어를 대체하는 것뿐만 아니라 다양한 옵션을 제공합니다.

8.3.7 nslookup (name server lookup)

nslookup 은 DNS 에 다양한 도메인 관련 내용을 질의하는 네트워크 명령입니다. 주로 DNS 에 대한 IP 주소를 질의하는 데 사용됩니다.

9.2 보안 솔루션 종류

데이터 센터에서 보안 장비를 디자인할 때 DDoS - 방화벽 - IPS - WAF 형태와 같이 여러 단계로 공격을 막도록 인라인 상에 여러 장비를 배치합니다.

9.2.1 DDoS 방어 장비

DDoS 장비는 데이터 센터 네트워크 내부와 외부의 경계에서 공격을 방어하는데, 이것을 볼류메트릭(Volumetric) 공격을 우선 막기 위해서입니다. 볼류메트릭 공격은 회선 사용량이나 트래픽을 과도하게 발생시켜 회선 사용을 방해하는 공격이므로 DDoS 장비는 네트워크의 가장 바깥쪽에 위치하여 이 공격을 완화해야 합니다.

9.2.2 방화벽

방화벽은 3, 4계층 정보를 기반으로 정책을 만드는 4계층 장비입니다. 패킷의 허용(Allow)하거나 거부(Deny)할 수 있습니다. 보통 DDoS 방어 장비 바로 뒤에 놓습니다.

9.2.3 IDS, IPS

IDS(Intrusion Detection System : 침입 탐지 시스템) 와 IPS(Intrusion Prevention System : 침입 방지 시스템) 는 애플리케이션 공격을 방어하는 장비로, 최근에는 IPS 로 통칭됩니다.

9.2.4 WAF

WAF(Web Application Firewall) 는 웹 서버 보호 전용 장비로, HTTP, HTTPS 처럼 웹 서버에서 동작하는 웹 프로토콜의 공격을 방어합니다. IPS는 데이터를 조합하지 않고 처리하지만 WAF는 프록시 서버와 같이 패킷을 데이터 형태로 조합해 처리합니다. 그래서 회피 공격을 쉽게 만들기 어렵고 데이터의 일부를 수정, 추가하는 기능을 수행할 수 있습니다.

9.3 방화벽

방화벽이란 네트워크 중간에 위치해 해당 장비를 통과하는 트래픽을 사전에 주어진 정책 조건에 맞추어 허용하거나 차단하는 장비입니다. 방화벽은 넓은 의미로 쓰이지만, 일반적으로 방화벽이란 네트워크 3, 4계층에서 동작합니다.

현대의 방화벽은 모두 세션 기반으로 동작하는 상태 기반(SPI) 엔진을 탑재하고 있습니다.

과거 패킷 필터링 방화벽은 위와 같이 요청과 응답 모두 방화벽 정책을 참조해야 했으나, 상태 기반 방화벽은 요청만 허용한다면 응답은 패킷의 방향성을 인지하고 내부에서 외부 인터넷으로 통신을 시도해 받은 응답과 외부에서 내부로 직접 들어오려는 패킷을 구분할 수 있습니다.

방화벽에서 패킷은 아래와 같은 순서로 확인됩니다.

장비에 패킷이 들어오면 우선 세션 상태 테이블을 확인합니다.
조건에 맞는 세션 정보가 세션 테이블에 있을 때, 포워딩 테이블을 확인합니다(라우팅, ARP 포함).
조건에 맞는 세션 정보가 세션 테이블에 없을 때, 방화벽 정책을 확인합니다.
방화벽 정책은 맨 위의 정책부터 확인해 최종 정책까지 확인한 후 없을 때 암시적인 거부(Implicit Denial) 규칙을 참고해 차단됩니다.
허용 규칙이 있으면 내용을 세션 테이블에 적어 넣습니다.
포워딩 테이블을 확인합니다(라우팅, ARP 포함).
조건에 맞는 정보가 포워딩 테이블에 있을 때, 적절한 인터페이스로 패킷을 포워딩합니다.
조건에 맞는 정보가 포워딩 테이블에 없을 때, 패킷을 폐기합니다.

SPI 엔진을 가진 방화벽은 세션 인지 기능이 있어 단순히 5-튜플 조건만 확인하는 것이 아니라 OSI 3, 4계층의 세부적인 필드도 함께 확인합니다. TCP 컨트롤 플래그에 따라 동작 방식이 변하거나 시퀀스와 ACK 번호가 갑자기 변경되는 것을 인지해 세션 탈취 공격을 일부 방어할 수 있습니다. 이것을 TCP Anti-Replay 기능이라고 합니다. 세션을 추가로 인지하고 세션 테이블에 저장하므로 세션을 로깅하기 쉽습니다.

9.4 IPS, IDS

IDS 와 IPS 는 애플리케이션 계층에서 이루어지는 공격을 탐지, 방어합니다.

IDS 는 침입 탐지 시스템으로 방어보다 탐지에 초점이 맞추어져있습니다. 트래픽을 복제해 검토하고 침입 여부를 판별합니다.

IPS 는 침입 방지 시스템으로, 공격이 발견되면 직접 차단하는 능력을 갖춘 장비입니다.

9.4.2 IPS, IDS 의 동작 방식

패턴 매칭 방식

기존 공격이나 취약점을 통해 공격 방식에 대한 데이터베이스를 습득하고 그 최신 내용을 유지하다가 공격을 파악하는 기술입니다.

어노말리 공격 방어

어노말리 공격 방어는 프로파일 어노말리(Profile Anomaly) 와 프로토콜 어노말리(Protocol Anomaly) 로 나뉩니다.

프로파일 어노말리 : 관리자나 IPS 장비가 정해놓은 기준과 다른 행위가 일어나면 공ㄱ겨으로 판단. 프린트 서버에 FTP 패킷이 전송되는 경우, 시스템의 트래픽이 갑자기 대량으로 발생한 경우 등
프로토콜 어노말리 : 사용자의 PC 가 악성코드에 감염되면 외부 C&C 서버와 연결되고 이 연결을 사용해 사용자 정보를 전달하고 해커의 지시에 따라 동작. 감영된 내부 PC 가 외부와 통신 시 잘 알려진 서비스 포트(ex. 80번) 를 사용하지만 프로토콜은 다른 프로토콜을 사용하는 경우가 흔하며 (ex. VNC) 이 경우 공격으로 탐지됨.

9.4.3 IPS, IDS 한계

IPS 는 애플리케이션 레벨의 빠른 확인을 위해 플로 엔진을 사용하는데, 해당 엔진은 패킷을 데이터 형태로 변환해 검사하는 것이 아니라 흘러가는 상황을 모니터링하므로 비교적 우회가 쉽습니다. 또한 오탐이 많이 발생하여 지속적인 최적화와 모니터링이 필요합니다. 이러한 한계를 극복하기 위해 NGIPS(Next Generation IPS) 개념의 장비가 출시되었습니다. NGIPS 는 애플리케이션을 인지하거나 다양한 시스템과 연동할 수 있고 특히 APT 공격을 방어하기 위한 일부 기능이 탑재되어 있거나 다양한 외부 시스템과 연동할 수 있습니다.

9.5 DDoS 방어 장비

DDoS 방어 장비는 볼류메트릭 공격을 방어하기 위해 트래픽 프로파일링 기법을 주로 사용합니다. 프로파일링 기법이란 평소 데이터 흐름을 습득해 일반적인 대역폭, 세션량, 초기 접속량, 프로토콜별 사용량 등을 저장하고 이렇게 습득한 데이터와 일치하지 않는 과도한 트래픽이 인입되면 알려주고 차단합니다. 습득한 데이터는 다양한 날짜 범위와 다양한 요소를 모니터링합니다.

DDoS 는 대규모 공격이므로 탐지 장비와 방어 장비를 구분하는 경우가 ㅁ낳은데, 이를 아웃 오브 패스(Out of Path) 라고 합니다.

9.5.4 볼류메트릭 공격

DDoS 장비는 주로 볼류메트릭 공격이나 프로토콜 공격을 방어하는 데 사용됩니다. 볼류메트릭 공격은 좀비 PC 를 통해 특정 시간에 특정 타킷을 공격하는 형태입니다. 이런 공격을 방어하기 위해서는 DDoS 장비를 보유하는 것뿐만 아니라 ISP 를 통한 방어나 Cloud DDoS 솔루션을 통해 서비스 네트워크로 트래픽이 직접 도달하지 못하도록 조치해야 합니다.

9.6 VPN

VPN (Virtual Private Network) 는 퍼블릭망을 통해 논리적으로 적접 연결하는 터널링을 말합니다. VPN 은 주로 퍼블릭망을 사설망처럼 사용하기 위해 도입하므로 강력한 보안을 제공해야 합니다. 그래서 IPSEC, SSL 과 같은 암호화 기법을 제공하는 프로토콜이 주로 사용됩니다.

일반적으로 VPN 은 3가지 형태로 구현됩니다.

Host to Host 통신 보호
Network to Network 통신 보호
Host 가 Network 로 접근할 때 보호

이중 Host to Host VPN 구성은 잘 쓰이지 않습니다. Network to Network 통신은 본사-지사 같은 특정 네트워크를 가진 두 종단을 연결하는 경우이며 IPSEC 프로토콜 스택이 가장 많이 사용됩니다.

Host to Network 통신은 모바일 사용자가 일반 인터넷망을 통해 사내망으로 연결하는 경우이며 IPSEC과 SSL 프로토콜이 범용적으로 사용됩니다.

10.1 리눅스 서버의 방화벽확인 및 관리

리눅스에서는 호스트 방화벽 기능으로 iptables 와 firewalld 가 있는데, CentOS 7 이상은 기본적으로 firewalld 사용. 하지만 iptables 에 익숙한 사용자가 많고, UFW 는 iptables 의 프론트엔드 역할도 수행하므로 iptables 에 대한 기본적인 이해 필요

관리자는 iptables 를 통해 허용하거나 차단할 IP 나 포트에 대한 정책을 수립함. 정책 그룹은 서버 기준의 트래픽 구간별로 만드는데 여기서 말하는 트래픽 구간은 서버로 유입되는 구간(INPUT), 서버에서 나가는 구간(OUTPUT), 서버를 통과하는 구간(FORWARD) 등을 말함. 그리고 이렇게 만들어진 방향성과 관련된 정책 그룹은 각 정책의 역할에 따라 다시 상위 역할 그룹에 속하게 됨

리눅스 방화벽 역할 용어 정리

Filter 테이블
- iptables에서 패킷을 허용하거나 차단하는 역할을 선언하는 영역
INPUT, OUTPUT, FORWARD 체인
- 호스트 기준으로 호스트로 들어오거나(INPUT) 호스트에서 나가거나(OUTPUT) 호스트를 통과할(FORWARD) 때 사용되는 정책들의 그룹. 패킷의 방향성에 따라 각 체인에 정의된 정책이 적용됨
Match
- 제어하려는 패킷의 상태 또는 정보 값의 정의
- 정책에 대한 조건
Target
- Match(조건)와 일치하는 패킷을 허용할지, 차단할지에 대한 패킷 처리 방식

리눅스 방화벽 예시

명령어 : iptalbes -L

ACCEPT all -- anywhere anywhere state RELATED, ESTABLISHED : 이미 세션이 맺어져 있거나 연계된 세션이 있을 때 모두 허용 : FTP 처럼 원시적 프로토콜은 연결과 다운로드 세션이 별도로 만들어지기 때문에 relate 를 통해 두 세션을 연관시켜야 함
ACCEPT icmp -- anywhere anywhere : ping 서비스 사용
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh : 외부에서 서버로 ssh 접속 허용
ACCEPT all -- anywhere anywhere reject-with icmp-host-prohibited : 1 ~ 4번째 정책에 매치되지 않는 패킷 모두 차단. reject 는 drop 과 달리 icmp 프로토콜로 패킷 차단 이유를 전달함.
3번째 정책은 모두를 허용하는 것 같지만 iptables -S 로 보면 루프백임을 알 수 있음

리눅스 방화벽 정책 관리

방화벽 추가 명령어지만, 위와 같이 설정하면 해당 정책이 제일 아래로 가기 때문에 정책이 적용안될 수 있음. 따라서 적절한 위치에 넣어줘야 함.

5번째에 정책 추가 : iptables -I INPUT 5 -p tcp --dport 80 -j ACCEPT
ip 주소나 포트를 범위로 지정
ip 주소와 서브넷 : iptables -A INPUT -p all -m iprange --src-range 192.168.0.0-192.168.255.255 -j DROP
ip 범위로 지정 : iptables -A INPUT -p all -m iprange --dst-range 192.168.1.11-192.168.2.15 -j DROP
포트 범위로 지정 : iptables -A INPUT -p tcp -m multiport --dports 3001:3010 -j DROP

방화벽 로그 확인

로그는 /var/log/messages 에 남지만 iptables 로그 외 다른 로그도 포함되어 있기 때문에 rsyslog.conf 설정 파일에 다음과 같이 추가

kern.* /var/log/iptables.log

그리고 rsylog 서비스 재시작

# systemctl restart rsyslog.service

iptables 에 로그를 남기도록 설정 (예시 : warning 수준의 로그, 로그 구분 식별자는 '## ZIGI-Log ##')

# iptables -I INPUT -j LOG --log-level 4 --log-prefix ‘## ZIGI-Log ##’

로드밸런서는 가상 IP 주소인 VIP 를 가지고 있으며, 실제 서버들의 IP 가 VIP 에 바인딩되어 있음. 로드 밸런서에서 부하 분산 그룹을 만들 때 IP 주소뿐만 아니라 서비스 포트까지 지정해서 만들기 때문에 로드 밸런서를 L4 스위치라고 함.

헬스 체크

ICMP : ping 으로 헬스 체크. 잘 사용하지 않음
TCP 서비스 포트 : SYN, ACK 로 확인
TCP 서비스 포트 (Half Open) : 정상적인 TCP 연결보다 빨리 헬스 체크 세션을 끊기 위해 SYN -> SYN/ACK 이후에 ACK 대신 RST 를 보내 세션을 끊음
HTTP 상태 코드 : 3way 핸드셰이크 이후 HTTP 를 요청해 200 OK 르 응답하는지 확인
콘텐츠 확인(문자열 확인) : 요청에 대한 결과값으로 상태확인

헬스 체크 주기와 타이머

주기 : 헬스 체크 패킷을 보내는 주기
응답 시간 : 헬스 체크 패킷을 보내고 응답을 기다리는 시간
시도 횟수 : 헬스 체크 실패 시 최대 시도 횟수
탕미아웃 : 헬스 체크 실패 시 최대 대기 시간
서비스 다운 시의 주기 (dead interval) : 서비스 다운 시의 헬스 체크 주기

부하 분산 알고리즘

로드 밸런서의 구성 방식

원암 구성 : 로드 밸런서가 중간 스위치 옆에 연결되는 구성. 서버로 가는 트래픽이 모두 로드밸런서를 경유하지 않아도 됨
- 부하분산을 이용할 때는 로드밸런서를 거치고, 그렇지 않으면 로드밸런서를 거치지 않음
- 로드밸런서 부하 감소 및 장애 영향도를 줄임
인라인 구성 : 서버로 가는 경로 상에 로드 밸런서가 연결
- 구성이 직관적이고 이해하기 쉬움

로드밸런서 동작 모드

트랜스패런트 모드

로드밸런서가 서비스하는 VIP 주소와 실제 서버가 동일한 네트워크를 사용해 로드밸런서가 OSI 2계층 스위치처럼 동작하는 구성. 인라인 구성과 원암 구성이 둘 다 가능하나 원암 구성에는 응답 트래픽 경로 부분이 문제가 될 수 있으므로 Source NAT 이 필요함

요청할 때는 로드밸런서를 통과할 때 목적지 IP 와 목적지 MAC 이 변경됨. 로드밸런서와 목적지 서버가 동일한 네트워크 대역이므로 출발지 MAC 주소는 변경되지 않음

반대로 응답할 때는 로드밸런서를 지나면서 출발지 IP 가 변경되지만 목적지 MAC 주소는 변경되지 않음. 목적지 MAC 주소가 이미 게이트웨이의 MAC 주소를 갖고 있기 때문임

라우티드 모드

로드밸런서가 라우팅 역할을 수행하면서, 사용자 방향과 서버 방향의 네트워크를 라우팅으로 연결. 라우터와 같이 맥주소가 변경됨.

DSR 모드

DSR (Direct Server Return) 은 명칭 그대로 사용자의 요청이 로드 밸런서를 통해 서버로 유입된 후에 다시 로드 밸런서를 통하지 않고 서버가 사용자에게 직접 응답하는 모드. 로드 밸런서 부하가 감소하는 효과가 있지만 문제가 발생했을 때 문제 확인이 어려움

사용자는 서비스 IP인 VIP 주소 10.10으로 서비스를 요청
로드 밸런서는 목적지 IP를 VIP 주소로 두고 목적지 서버의 MAC 주소만 변경해 실제 서버로 전송
실제 서버에서는 루프백 인터페이스에 VIP와 동일한 IP 주소가 설정되어 있고 목적지 IP가 이 루프백 IP와 동일한 경우에도 패킷을 수신

DSR 모드의 응답은 로드 밸런서가 개입하지 않으므로 로드 밸런서를 사용하지 않는 일반 패킷과 유사하게 전달됨
다만 출발지 IP 가 서버의 인터페이스 IP 주소가 아닌 루프백 인터페이스 IP 주소임

2계층/3계층 네트워크

2계층 네트워크

호스트 간 통신이 직접 2계층 통신만으로 이루어지는 네트워크 디자인

3계층 네트워크

호스트 간 통신이 IP 라우팅과 같은 3계층 통신으로 이루어지는 네트워크 디자인. 라우팅으로 구성되므로 루프 문제가 발생하지 않음. 하지만 각자 다른 네트워크이기 때문에 브로드캐스트로 상대방 호스트를 직접 찾을 수 없음

3-Tier 아키텍처

코어 - 애그리게이션 - 액세스 3계층으로 이루어진 전통적인 네트워크 아키텍처.

액세스는 호스트가 직접 연결된 스위치이며 애그리게이션 스위치는 액세스 스위치를 중간에서 접선한다. 코어 계층 스위치는 애그리게이션 스위치를 다시 모아 서로 통신할 수 있게 연결해준다. 상위 계층으로 갈수록 높은 대역폭이 필요하다.

2-Tier 아키텍처

스파인-리프(Spine-Leaf) 2-Tier 디자인은 데이터 센터 디자인으로 많이 적용됨

데이터 센터에서는 센터 내부의 서버 간 통신량이 많기 때문에 East-West 트래픽이 많음. 스파인-리프 네트워크 디자인에서는 동일 리프 스위치에 호스트가 연결된 경우를 제외하면 모든 호스트 간 통신 홉이 동일함. 따라서 홉 수가 짧아지고 트래픽 흐름이 일정해짐.

해당 구성은 2계층과 3계층에서 모두 사용할 수 있음

L2 패브릭

스파인-리프 구조를 2계층 네트워크로 구성하는 방법. TRILL 이나 SPB 와 같은 프로토콜을 사용할 수 있음.

L3 패브릭

스파인-리프 구조를 3계층 네트워크로 구성하는 방법. 스파인과 리프가 연결된 링크는 각각 라우팅이 활성화되어 있고 라우팅 프로토콜을 이용해 경로 정보를 교환함

하단 호스트의 네트워크가 리프 간에 서로 다른 네트워크를 갖기 때문에 동일한 네트워크 구성이 필요하다면 VxLAN 과 같은 오버레이 네트워크 기술을 적용해야 함.

케이블링과 네트워크

스위치의 물리적 위치에 따른 구성 방식

ToR : 랙 상단에 개별적으로 설치되는 스위치. 서버와 스위치가 동일 랙에 있으므로 케이블링의 길이나 복잡성이 줄어들지만 스위치가 더 많이 필요하므로 관리사항과 전력, 냉각비용 등이 늘어남. 랙별로 스위치를 구성하므로 미사용 포트가 늘어 포트의 집적도가 떨어짐
EoR : 랙이 있는 행 끝에 네트워크 장비를 두고 연결. 필요한 스위치 장비 수가 줄어들고 대기시간이나 지연에 유리. 하지만 서버와의 케이블 구성이 더 멀어지므로 복잡도가 높아지고 케이블이 길어짐.
MoR : 네트워크 장비의 랙을 행 끝이 아닌 중간에 두는 방식. EoR 과 비교해서 네트워크 장비가 중간에 있어 케이블 길이가 전반적으로 감소함
장비 가장화 기술이란 크게 두 가지로 구분됨
여러 개의 물리 장비를 하나의 논리 장비로 합치는 기술
하나의 물리 장비를 여러개의 논리 장비로 나누는 기술

여러 개의 물리 장비를 하나의 논리 장비로 합치는 기술

여러 개의 물리 박스 스위치를 묶어 한 대의 논리적 스위치로 만듦

다수의 장비를 하나의 장비처럼 관리할 수 있어 관리 부하가 줄어듦
이중화 경로를 효율적으로 사용하고 루프 문제를 제거할 수 있음

네 대의 스위치를 사각형으로 연결한 것은 루프 구조이기 때문에 하나의 인터페이스가 블록됨

하지만 장비 두 대를 각각 하나의 논리 장비로 구성하고 이 논리 장비로 1:1 구조를 만들면 루프 구조에서 벗어날 수 있음. 또한 이중화된 경로에 장애가 발생하더라도 별도의 긴 페일오버 시간이 필요 없음

하나의 물리 장비를 여러개의 논리 장비로 나누는 기술

VMware 의 ESXi 와 같은 기술이 대표적임. 스위치의 VLAN 기술도 이 범주에 속함. 리소스를 독립적으로 할당해 사용

운용 시 관리 포인트 감소
자원 활용률 증가
도입 비용과 운영비용 절감

장비를 가상화해 이중화 구성을 하더라도 물리 장비 하나에서 동일한 역할을 논리적으로 나누지 않음. 물리 장비에 장애가 발생하면 논리 장비 모두 서비스의 영향을 받기 때문