통신을 도와주는 네트워크 주요 기술 (NAT, PAT, DNS, GSLB, DHCP)

NAT / PAT

*NAT 네트워크 주소 변환 기술 → 하나의 네트워크 주소에 다른 하나의 네트워크 주소로 변환하는 1:1 변환이 기본이지만.. NPAT IP 주소 고갈 문제로 인해 여러 개의 IP 를 하나의 IP로 변환하기도. (PAT) AFT IPv4 ↔ IPv6 으로 변환하는 기술도 NAT 의 일종*

💡 NAT 가 가장 많이 사용되는 경우는 사설 IP → 공인 IP 주소로 전환하는 경우이다.

NAT / PAT 의 용도와 필요성

IPv4 주소 고갈 문제

• IPv4 주소 보존 전략 중
  • 단기 전략은 서브네팅.
  • 중기 전략은 NAT 와 사설 IP 체계.
  • 장기 전략은 IPv6 전환.
• NAT 를 이용해 외부 서비스에만 공인 IP 사용.
• 외부에 공개할 필요 없는 일반 사용자 PC 나 기타 종단 장비는 사설 IP 사용.

보안 강화

• 외부와 통신할 때 내부 IP 를 다른 IP로 변환해 통신하면 외부에 사내 IP 주소 체계 숨기기 가능.
• NAT 는 주소 변환 후 역변환이 정상적으로 다시 수행되어야 통신 가능하여 → 방향성 통제 가능
• 내부 → 외부 통신 허용하고 외부 → 내부 통신 방어 가능 (NAT 장비 거쳐야 통신 가능)

IP 주소 체계가 같은 두 개의 네트워크 간 통신 가능

• 사설 IP를 이용해 다른 회사와 직접 연결해야하거나 회사 간 합병으로 서로 통신해야 한다면?
  • 사설 IP 주소 충돌 가능성
• 출발지와 도착지를 한꺼번에 변환하는 더블 나트 기술을 사용하여 해결

불필요한 설정 변경 줄이기

• 만약 회선 사업자를 변경하거나 IDC 를 이전하면 그 동안 빌려써왔던 공인 IP 사용 불가 → 신규 사업자가 빌려주는 IP로 변경 필요
• 그러나 사용자가 NAT/PAT 를 이용해 내부 네트워크를 구성하고 있었다면 서버와 PC의 IP 주소 변경 없이 회선과 IDC 사업자 이전 가능.
  • 외부에 서비스하던 공인 IP 주소가 변경되므로 DNS 서비스나 NAT 수행 네트워크 장비 설정은 변경해야하지만
  • 내부 서버나 PC 설정 변경 최소화 가능 → 복잡한 작업 최소화 가능
  • 특정 사업자에 종속되지 않는 유연한 인프라스트럭처 기본 요소 → 비즈니스 유연성을 높이는데 매우 중요한 기술

단점

• IP가 변환되면 장애가 발생했을 때 문제해결이 힘듬.
• 애플리케이션 개발할 때 더 많은 고려사항 생김
  • 단말 간 직접적인 연결성 무너짐
  • 개발자들이 앱 제작할 때 NAT 환경을 항상 고려해야 함.
  • 이걸 극복하기 위해 NAT 밑에 있는 단말도 직접 연결하게 도와주는 홀 펀칭 기술 → 이걸 도입하기 위해 앱이 더 복잡해지는 악순환~

NAT 동작 방식

출발지 사용자 10.10.10.10 가 목적지 웹 서버 20.20.20.20 로 통신하는 과정

1. 사용자는 웹 서버에 접근하기 위해 출발지 IP를 10.10.10.10 으로, 목적지 IP 와 서비스 포트는 20.20.20.20 과 80으로 패킷 전송 (출발지 포트는 임의로 할당 (2000)
2. NAT 장비에서는 사용자 패킷을 수신한 후, NAT 정책에 따라 외부 네트워크와 통신이 가능한 공인 IP 11.11.11.11 로 IP 주소를 변경.
   1. NAT 장비에서 변경 전후 주소는 NAT 테이블에 저장.
3. NAT 장비에서 출발지 주소를 11.11.11.11 로 변경해 목적지 웹 서버로 전달.
4. 패킷을 수신한 웹 서버는 사용자에게 응답.
   1. 출발지는 웹서버 (20.20.20.20) 목적지는 NAT 장비에 의해 변환된 공인 IP (11.11.11.11) 로 사용자에게 전송
5. NAT 장비는 자신의 NAT 테이블에서 목적지 IP 에 대한 원래 패킷을 발생시킨 출발지 IP 주소가 10.10.10.10 인 것을 확인.
6. NAT 변환 테이블에서 확인된 원래 패킷 출발지 IP(10.10.10.10) 로 변경해 사용자에게 전송하면 사용자는 최종적으로 패킷을 수신.

PAT 동작 방식

1. 사용자는 웹 서버에 접근하기 위해 출발지 IP를 10.10.10.10 으로, 목적지 IP 와 서비스 포트는 20.20.20.20 과 80으로 패킷 전송 (출발지 포트는 임의로 할당 (2000)
2. NAT 장비에서는 사용자 패킷을 수신한 후, NAT 정책에 따라 외부 네트워크와 통신이 가능한 공인 IP 11.11.11.11 로 IP 주소를 변경.
   1. NAT 와 다르게 출발지 서비스 포트도 변경되며, 모두 NAT 테이블에 저장.
3. NAT 장비에서 변경된 출발지 주소 IP, 포트로 패킷을 재작성해 웹서버로 전송.
4. 웹서버는 사용자에게 패킷 응답.
   1. 출발지는 웹서버 (20.20.20.20) 목적지는 NAT 장비에 의해 변환된 공인 IP (11.11.11.11) 로 사용자에게 전송
5. NAT 장비는 자신의 NAT 테이블에서 목적지 IP 에 대한 원래 패킷을 발생시킨 출발지 IP 주소가 10.10.10.10 인 것을 확인. 포트도 3000이 원래 2000인 것을 확인
6. NAT 변환 테이블에서 확인된 원래 패킷 출발지 IP와 포트로 변경해 사용자에게 전송하면 사용자는 최종적으로 패킷을 수신.

결론

• PAT 와 NAT 는 거의 비슷하게 동작한다.
  • IP 만 바꾸냐 → NAT
  • IP 랑 PORT 다 바꾸냐 → PAT
• PAT : 서비스 포트의 개수는 제한되어 있어 재사용된다.
  • 만약 포트가 모두 사용중이거나 재사용할 수 없으면 PAT 정상 동작 불가.
  • 동시 사용자가 매우 많으면 PAT 공인 IP 주소를 IP 하나가 아니라 IP 풀로 구성해야 함.
• PAT IP 가 목적지 일 때는 해당 IP 가 어느 IP 에 바인딩되는지 확인할 수 있는 NAT 테이블이 없어서 사용 불가
  • SNAT (출발지 주소 변경) 에서만 사용하고 DNAT (목적지 주소 변경)에서는 사용 불가

SNAT 및 DNAT

트래픽이 출발하는 시작 지점을 기준으로 구분한다.

 

	트래픽 시작 지점	사용 예
SNAT	출발지 주소 변경	사설 → 공인
DNAT	도착지 주소 변경	외부 → 내부, 로드밸런서

SNAT

• 사설 → 공인 통신에 많이 사용
• 내부 IP 주소가 아니라 다른 IP 로 전환해 전송하여 내부 실제 IP 주소를 숨길 수 있음. : 보안상 이유
• 대외사와 통신해야하는 사내 IP 가 대외사 IP 대역과 중복 될 때 : SNAT 로 다른 IP로 변경해 통신
  • 이 경우에는 반드시 공인 IP로 변경할 필요는 없음
• 로드밸런서 구성
  • 출발지/목적지가 동일한 대역이면 로드밸런서를 구성해도 트래픽이 로드 밸런서를 거치지 않고 응답할 수 있어 SNAT 를 통해 응답 트래픽이 로드밸런서를 거치게 함.

DNAT

• 로드밸런서에 많이 사용.
  • 로드 밸런서에 설치된 서비스 VIP(Virtual IP) 로 서비스를 요청 → 로드 밸런서가 서비스 VIP 를 로드 밸런싱될 서버의 실제 IP로 DNAT 해 내보냄.
• 대외망과의 네트워크 구성
  • 대외망에 NAT를 이용해 대외사의 IP를 특정 IP 대역으로 NAT
  • 사내에서는 어떤 대외사든 대외망 전용 NAT 대역으로 변경된 네트워크 대역으로 라우팅 처리
  • 대외사 추가에 따라 별도 라우팅을 개별적으로 설정할 필요가 없고 사내 IP 와 중복되는 IP 가 있더라도 라우팅 이슈 없이 구성 가능

동적 NAT 와 정적 NAT

 

	정적 NAT	동적 NAT
뜻	출발지와 목적지 IP 를 미리 매핑해 고정	NAT 를 수행할 때 동적으로 변경
관계	1:1	1:N
NAT 테이블	사전 생성	NAT 수행 시 생성
NAT 테이블 타임아웃	없음	있음
NAT 수행 정보	별도 필요 없음 (설정=NAT내역)	실시간으로만 확인하거나 별도 변경 로그 저장 필요.

동적 NAT

• 출발지와 목적지가 모두 정의된 게 아니라 다수의 IP 풀에서 정해짐.
• 최소한 출발지나 목적지 중 한 곳이 다수의 IP 로 구성된 IP 풀이나 레인지로 설정되어 있음.
• NAT 를 수행하는 시점에 NAT 테이블을 만들어 관리.
  • NAT 테이블 : 설정된 시간 동안 유지, 일정 시간 동안 통신이 없으면 다시 사라짐(NAT 테이블 타임아웃) 동적 NAT 설정은 서비스 흐름을 고려해 적용.

정적 NAT

• 출발지 목적지 매핑 관계가 특정 IP로 사전에 정의 → 1:1 NAT 라고 부르기도…
• 방향성 없이 서비스 흐름을 고려하지 않고 NAT 설정 가능

💡 네트워크 프로토콜은
- 데이터 프로토콜컨트롤 프로토콜
- 프로토콜 체계를 유지하기 위한 주요 컨트롤 프로토콜
- ARP , ICMP , DNS

DNS

Domain Name System : 도메인 주소를 IP 주소로 변환하는 역할.

도메인 주소 사용 이유

• 숫자로 구성된 IP 주소보다 의미있는 문자열로 구성된 도메인 주소가 인식하고 기억하기 쉬움.
• 하나의 IP 주소로 여러 개의 웹 서비스 운영 가능
• 서비스 중인 IP 주소가 변경되어도 → 도메인 주소 그대로 유지해 접속 방법 변경 없이 서비스 그대로 유지 가능
• 지리적으로 여러 위치에서 서비스 가능

 

💡 물론 실제로 패킷을 만들어 통신하려면 3계층 IP 주소를 알아야 함.
→ 이를 위해 문자열로 된 도메인 주소를 실제 통신에 필요한 IP 주소로 변환하는 DNS(Domain Name ServeR) 정보 입력 필요

도메인 주소 요청 예

1. 사용자가 도메인 주소(naver.com) 로 서비스 요청
2. 브라우저가 DNS 서버에 naver.com 주소가 뭔지 질의
3. DNS 서버는 naver.com 의 IP 주소가 202.179.177.21 이라고 사용자에게 알려줌
4. 사용자는 DNS 로 응답받은 202.179.177.21 이라는 IP 주소를 이용해 실제 naver.com 에 접속.

DNS 구조와 명명 규칙

www.naver.com.

← 이 방향으로 루트부터 찾음

• . : 각 계층의 경계를 . 로 표시하며, 뒤에서 앞으로 해석한다. 마지막 .는 루트로, 생략한다
• www : Third-Level domain
• naver : Second-Level domain
• com : Top-Level domain (TLD)

루트 도메인

도메인을 구성하는 최상위 영역

• DNS 서버는 사용자가 쿼리한 도메인 값을
  • 직접 갖고 있거나
  • 캐시에 저장된 정보를 이용해 응답
• DNS 서버에 해당 도메인 정보가 없으면 루트 도메인을 관리하는 루트 DNS 에 쿼리

Top-Level Domain (TLD)

최상위 도메인

Generic TLD(gTLD)

특별한 제한 없이 일반적으로 사용하는 최상위 도메인, 세 글자 이상으로 구성됨.

• com(일반 기업체), edu(4년제 이상 교육 기관), gov(미국 연방 정부 기관) 등, 각자 뜻이 있음

Country Code TLD(ccTLD)

국가 최상위 도메인, ISO 3166 표준에 의해 규정된 두 글자의 국가 코드 사용

• 우리나라는 kr

Sponsored(sTLD)

특정 목적을 위한 스폰서를 두고 있는 최상위 도메인

… 등등 여러가지 도메인 들이 있음. (생략)

DNS 동작 방식

클라이언트 관점의 DNS

1. 도메인을 IP 주소로 변환하려면 DNS 서버에 도메인 쿼리 과정을 거침.
   • DNS 서버 없이 로컬에 도메인과 IP 주소를 직접 설정해 사용도 가능.
     • hosts 파일에 도메인과 IP 주소 설정 → 해당 도메인 리스트는 항상 DNS 캐시에 저장
     • hosts 파일 : 로컬에서 도메인과 IP 주소를 관리하는 파일
2. 도메인을 쿼리하면 DNS 서버에 쿼리하기 전에 로컬에 있는 DNS 캐시 정보 먼저 확인
   • 동일한 도메인을 매번 질의하지 않고 캐시를 통해 성능 향상
     • 기존 DNS 를 통해 확인한 동적 DNS 캐시
     • hosts 파일에 저장되어 있는 정적 DNS 캐시
3. DNS 캐시 정보에 도메인 정보가 없으면 DNS 서버로 쿼리
4. DNS 서버로부터 응답 받으면 그 결과를 캐시에 먼저 저장
   • 전에 한 번 쿼리를 수행한 DNS 정보는 캐시부터 조회
   • DNS 서버에 별도 쿼리하지 않고 캐시 정보 사용

DNS 시스템 관점에서 도메인에 대한 결괏값을 클라이언트에 보내주는 과정

• DNS 는 자신이 가진 도메인 정보가 아니면 다른 DNS 에 질의해 결과를 받을 수 있음.
• DNS 서버는 기본적으로 루트 DNS 관련 정보를 갖고 있음.
• 클라이언트 쿼리가 자신에게 없는 정보라면 → 루트 DNS 에 쿼리
  • 루트 DNS 에서 쿼리한 도메인의 TLD(최상위 도메인) 값 확인.
  • 해당 TLD 값을 관리하는 DNS 가 어디인지 응답.

예 )

1. zigispace.net 도메인을 클라이언트가 DNS 에 쿼리.
2. 루트 DNS 에 다시 쿼리.
3. 루트가 .net 을 관리하는 DNS 서버에 zigispace.net 에 대해 쿼리
4. .net 관리 서버가 zigispace.net 을 관리하는 DNS 관련 정보를 처음 DNS 서버에 응답.
5. DNS 서버는 마지막으로 zigispace.net 을 관리하는 DNS 에 쿼리.
6. zigispace.net 최종 결괏값 받음. → DNS 서버가 이 정보를 클라이언트에게 응답.

결론

• 클라이언트에서 처음 질의를 받은 DNS 가 중심이 되어 책임지고 루트 → 상위 DNS 에 차근차근 쿼리를 보내 결과 알아냄.
• 최종 결괏값만 클라이언트에게 응답.
  • 클라이언트는 한 번의 쿼리 : 재귀적 쿼리
  • DNS 서버는 여러 단계로 쿼리를 상위 DNS 서버에 보내 정보 획득 : 반복적 쿼리

마스터와 슬레이브

마스터 서버 우선순위가 더 높지 않음, 두 서버 모두 도메인 쿼리에 응답. 그냥 도메인에 대한 Zone 파일을 직접 관리하는지 여부로 구분.

• 마스터 : 존파일(Zone File)을 직접 생성해 도메인 관련 정보 관리.
• 슬레이브 : 마스터에 만들어진 존파일 복제 (영역 전송).

슬레이브 서버를 만들 때

• 도메인을 복제해올 마스터 서버 정보를 입력해야 함.

마스터 서버에서는

• 자신이 가진 도메인 정보를 인가받지 않은 다른 DNS 서버가 복제해가지 못하도록 슬레이브 서버 지정해 복제 제한 가능.
  • 마스터에 다른 설정을 하지 않으면 무제한 복제 가능
  • 슬레이브 서버 정보를 반드시 입력하는 것이 좋음.

마스터 서버가 터지면

• 마스터 서버에 문제가 발생하고 일정 시간이 지나면 슬레이브 서버도 도메인 질의에 정상 응답 불가 → 만료 시간 : SOA 레코드에 설정
• 액티브-스탠바이 또는 액티브-액티브 등의 이중화 방식을 사용하지 않음.

DNS 주요 레코드

 

레코드 종류	내용
A (IPv4)	도메인 주소를 IP 주소로 매핑
AAAA (IPv6)	도메인 주소를 IP 주소로 매핑
CNAME (별칭)	도메인 별칭
SOA (권한 시작)	본 영역 데이터에 대한 권한
NS (도메인의 네임 서버)	본 영역에 대한 네임서버
MX (메일 교환기)	도메인에 대한 메일 서버 정보
PTR (포인터)	IP 주소를 도메인에 매핑
TXT (레코드)	도메인에 대한 일반 텍스트

A 레코드 (IPv4)

기본 레코드. 도메인 주소를 IP 주소로 변환.

• 사용자가 질의한 도메인 주소를 A 레코드에 설정된 IP 주소로 응답.
• 1:1 매핑

AAAA 레코드 (IPv6)

역할은 A 레코드와 같으나 IPv6 주소 체계에 사용.

CNAME 레코드

별칭 레코드

• 도메인 주소를 매핑
• 대표적인 예로 www 사용

SOA 레코드

도메인 영역에 대한 권한

• 필수 항목
• 현재 네임 서버가 이 도메인 영역에 대한 관리 주체라면, 해당 도메인에 대해서는 다른 네임 서버에 질의하지 않고 직접 응답.
• 현재 도메인 관리에 필요한 속성값도 설정

NS 레코드

도메인에 권한이 있는 네임 서버 정보 설정

• 하위 도메인에 대한 권한을 다른 네임 서버로 위임하는 역할로도 많이 사용.

MX 레코드

메인 서버 구성 레코드

• 해당 도메인을 메일 주소로 갖는 메일 서버를 MX 레코드를 통해 선언.
• 우선 순위가 높은(값이 적은) 서버로 메일을 보내고 실패하면 다음 순서의 MX 레코드의 메일 서버에서 처리.

PTR 레코드

IP 주소에 대한 질의를 도메인 주소로 응답.

• 역방향 조회용
• 하나의 IP 에 대한 PTR 레코드는 오직 하나만 가짐.
• 주로 화이트 도메인 구성용

TXT 레코드

도메인에 대한 설명과 같이 간단한 텍스트 입력

• 화이트 도메인을 위한 SPF 레코드로 주로 사용

DNS 에서 알아두면 좋은 내용

• 도메인 위임
• TTL
• 화이트 도메인
• 한글 도메인

도메인 위임

도메인 내의 모든 레코드를 그 네임 서버가 직접 관리하지 않고 일부 영역은 다른 곳에서 레코드를 관리하도록 위임.

• CDN 또는 GSLB 를 이용하는 것이 대표적.
• 도메인은 계층 구조여서 특정 계층 레코드를 위임하면 해당 레코드의 하위 계층은 함께 위임 처리.
• 예 ) zigispace.net 도메인 하위에 post 를 추가하는데, 원래 zigi-.net 을 관리하는 “A” 서버가 아니라 관리 권한을 “B” 서버(GSLB)에 넘길 수 있음
  • 해당 영역을 위임하겠다는 레코드 설정을 “A” DNS 서버에 추가
  • post.zigispace.net 을 포함한 하위 영역에 대한 세부 레코드 c.post.zigispace.net 은 “B” GSLB 에서 관리
• 특정 영역에 대한 관리 주체를 분리하는 용도 → 계열사에서 특정 도메인을 분리하거나 GSLB 등 다양한 용도로 사용 가능.

TTL

DNS 에 질의해 응답받은 결괏값을 캐시에 유지하는 시간

• DNS 에 설정된 TTL 값에 따라 그 시간만 로컬 캐시에 저장.
• TTL 값으로 캐시를 많이 이용하면 DNS 재귀적 쿼리로 인한 응답 시간을 많이 줄이고 네트워크 응답 시간 단축. 그러나..
  • 너무 길면 DNS 에서 도메인 정보 변경 시 새로 변경된 값으로 DNS 정보 갱신이 지연
  • 너무 짧으면 DNS 정보 갱신이 빨라져 DNS 쿼리량이 늘어나 DNS 서버 부하 증가
• 적정 TTL 값 정하는 법
  • 변경이 빈번하지 않으면 → TTL 값 늘려 DNS 부하 줄임
  • IDC 이전이나 공인 IP, 서비스 변경이 예정되어 있다면 → TTL 값을 미리 극도로 줄여 변경 신속 적용

화이트 도메인

정상적인 도메인을 인증, 관리하는 제도. 불법적인 스팸 메일을 발송하는 사이트를 실시간 블랙리스트 정보로 관리해 메일 발송 제한.

• 실시간 블랙리스트 → RBL
• SPF 레코드로 사전에 메일 서버를 공개함.
  • 메일 정보 / SPF 정보가 일치하지 않으면 비정상적인 이메일 서버에서 전송된 것으로 간주, 해당 이메일을 스팸 처리 가능
• SPF 레코드 길이는 최대 512바이트 → 하나의 도메인에 화이트 도메인으로 등록할 수 있는 메일 서버 개수가 제한되어있음

한글 도메인

도메인 주소를 http://한국인터넷진흥원.한국 처럼 한글 주소로 만들 수 있음.

• DNS 에서 해당 한글을 “ 퓨니코드 ” 로 변경하고 퓨티코드로 DNS 에 도메인 생성
  • 퓨니코드 → 다국어 도메인이 아스키로 인코딩된 구문. 한글뿐만 아니라 영어가 아닌 자국어 도메인을 사용할 수 있게 해주는 표준 코드
  • 자국어 도메인을 사용할 수 있는 것을 “다국어 도메인 네임 IDN”

GSLB

DNS 와 동일하게 도메인 질의에 응답해주는 역할과 동시에 로드밸런서처럼 등록된 도메인에 연결된 서비스가 정상적인지 헬스 체크 수행.

• 등록된 도메인에 대한 서비스 상태를 체크해, 정상적인 레코드만 사용.
• 인텔리전스 DNS 라고 부르기도..

GSLB 동작 방식

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

일반 DNS 와 GSLB 와의 차이

• 서비스 IP 정보에 대한 헬스체크.
• 사전에 지정한 다양한 분산 방법을 이용한 부하 분산
  • 일반 DNS 는 두 개 이상의 항목이 있다면 라운드 로빈으로 응답.

GSLB 구성 방식

• 도메인 자체를 GSLB 로 사용하는 경우
  • GSLB 자체가 도메인의 네임 서버 역할을 함.
  • 헬스 체크 불필요
  • 모든 레코드에 대한 질의가 GSLB 를 통해 이뤄짐 → GSLB 에 부하.
• 도메인 내의 특정 레코드만 GSLB 사용
  • 도메인 내의 특정 레코드만 GSLB 사용
  • 회사 대표 도메인에 속한 레코드 중 GSLB 적용이 불필요한 것이 있다면 → 도메인 내의 특정 레코드만 GSLB 로 처리를 이관하는 방식 사용
    • 별칭 (CNAME) 사용
    • 위임 (NS) 사용

별칭 (CNAME) 사용하는 경우

실제 도메인과 다른 별도의 도메인 레코드로 GSLB 에 등록.

• 외부 CDN 사용하거나 회사 내부에 GSLB 를 사용해야 할 도메인이 많은 경우 한꺼번에 관리하기 위해 사용.
• CNAME 레코드 값으로 등록된 FQDN(전체 도메인 이름)을 GSLB 로 재질의해 서버를 찾아감.
  • CNAME 값으로 등록되는 FQDN 이 네임 서버로 등록된 도메인을 사용해 GSLB 로 재질의하게 만듬.

별칭 사용하는 경우 질의 단계

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

위임 (NS) 사용하는 경우

실제 도메인과 동일한 레코드 사용하여 도메인 전체를 위임.

• DNS 에서 특정 FQDN 에 대해 NS 레코드에 GSLB 로 설정.
• 최초 요청한 FQDN 을 그대로 GSLB 에 재질의.
• DNS 서버 설정을 최소화해 GSLB 로 다수의 FQDN 위임 처리 가능.

위임 (NS) 사용하는 경우 질의 단계

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

 

💡 정리하면
별칭을 사용하는 경우
- CDN 처럼 GSLB 를 운영해주는 외부 사업자가 있을 때
- GSLB 를 사용해야 하는 도메인이 매우 많은 경우 별도의 GSLB 를 운영하기 위해 사용

위임 을 사용하는 경우
- DNS 와 같은 도메인으로 GSLB 를 운영하면서 계층적으로 GSLB 를 이용한 FQDN 을 관리할 때 사용.

NS 와 CNAME 방식을 혼용하여 사용하기도..

 

GSLB 분산 방식

서비스 헬스 체크를 통하는 것 외에 서로 다른 사이트로 서비스를 분산하는 것이 GSLB 의 중요한 역할.

• 서비스 제공 가능 여부를 체크해 트래픽 분산
• 지리적으로 멀리 떨어진 다른 데이터 센터에 트래픽 분산
• 지역적으로 가까운 서비스에 접속해 더 빠른 서비스 제공이 가능하도록 분산

GSLB 지원

• 서비스 응답 시간/지연 (RTT/Latency)
  • 서비스 요청에 대한 응답이 얼마나 빠른지 또는 지연이 얼마나 없는지 확인하고 분산 처리
• IP 에 대한 지리 정보
  • 각 사이트의 IP 주소에 대한 Geo 값을 확인해 가까운 사이트로 서비스 분산
    • Geo : 사용자가 바라보는 LDNS 와 GSLB 간 값임. 만약 국내 사용자가 해외 DNS 서버를 LDNS 로 활용하면 서비스 접속 시간이 더 길어질 수도…

→ 서비스가 가능한 사이트로 트래픽을 분산시키는 것뿐만 아니라, 더 신속히 서비스를 제공할 수 있는 사이트로 접속할 수 있도록 유도.

DHCP

Dynamic Host Configuration Protocol IP 를 동적으로 할당하는 데에 사용하는 프로토콜.

• DHCP 를 사용하면 사용자가 직접 입력해야 하는 IP 주소, 서브넷 마스크, 게이트웨이, DNS 정보를 자동으로 할당받아 사용할 수 있음.
• 별도의 IP 설정 작업 필요 X
• 사용하지 않는 IP 정보는 자동 회수되고 사용하는 경우에만 재할당.
• IP 가 자동으로 관리되어 사용자가 직접 입력하며 발생하는 설정 정보 오류나 중복 IP 할당 문제 예방 가능.

DHCP 프로토콜

• BOOTP 라는 프로토콜을 기반으로 함.
• DHCP 는 BOOTP 에서 지원되지 않는 몇 가지 기능이 추가된 확장 프로토콜.
• 둘은 호환성이 있음.
  • 서비스 포트 같음
  • BOOTP 클라이언트가 DHCP 서버를 사용 ↔ DHCP 클라이언트가 BOOTP 서버 사용 가능
• 클라이언트 포트 68 , 서버 포트 67 사용

DHCP 동작 방식

1. DHCP Discover

DHCP 클라이언트가 DHCP 서버를 찾기 위해 DHCP Discover 메시지를 브로드캐스트로 전송.

• IP 를 할당받는 과정이라 패킷을 정상적으로 주고받을 수 없어 UDP 사용.

2. DHCP Offer

DHCP Discover 를 수신한 DHCP 서버는 클라이언트에 할당할 IP 주소와 서브넷, 게이트웨이, DNS 정보, Lease Time 등의 정보를 포함한 DHCP 메시지를 클라이언트로 전송.

• “제안”하는 이유는 → DHCP 서버가 다수일 수도 있어서, 할당해놓고 일단 제안함. 쓸래? → 쓸지 안 쓸지 아직 모름.
• 특정 클라이언트의 MAC 주소와 IP 주소를 사전 정의하면, 설정된 IP 를 할당.
  • DHCP 를 사용하면서도 고정 IP 사용 가능.

3. DHCP Request

DHCP 서버로부터 제안받은 IP 주소(Requested IP) 와 DHCP 서버 정보 (DHCP Server Identifier) 를 포함한 DHCP 요청 메시지를 브로드캐스트로 전송.

• DHCP 서버가 여러 대 일 수 있으니 브로드캐스트로 전송.
• 자신이 보낸 DHCP Offer 메시지에 대한 DHCP Request 인지 확인하고 그 패킷에 대해서만 응답함.
  • 여러 대한테 보내더라도 제안한 DHCP 서버만 DHCP Request 에 응답함.

4. DHCP Acknowledgement

DHCP 클라이언트로부터 IP 주소를 사용하겠다는 요청을 받으면 DHCP 서버에 해당 IP 를 어떤 클라이언트가 언제부터 사용하기 시작했는지 정보를 기록하고 DHCP Request 메시지를 정상적으로 수신했다는 응답 전송.

• 브로드캐스트로 전체 전송
• 이 패킷을 전송하며 클라이언트는 DHCP 서버에서 할당받은 IP 를 로컬에서 설정하고 사용.

DHCP IP 할당

DHCP IP Pool 에서 클라이언트에 정해진 시간 동안 IP 를 사용할 수 있도록 할당 → 임대(Lease) 과정.

• IP 정보와 함께 임대 시간을 지정해 전달.
• 임대 시간이 만료되면 클라이언트에 할당된 IP 를 다시 IP Pool 로 회수.

클라이언트가 IP 사용 중 임대 시간이 모두 지나면?

• 사용하던 IP 다시 수거
• 클라이언트는 DHCP Discover 부터 시작해 IP 재할당받기 필요.
• 사용하던 IP 주소가 다른 클라이언트에게 할당되며 다른 IP 할당 가능성…

하지만 사실은!

• 현재 클라이언트가 IP를 사용 중인 경우, 갱신(Renewal) 과정을 거쳐 사용 중인 동안 IP 주소가 IP 풀에 다시 반환되지 않고 계속 사용할 수 있음.

DHCP 갱신

임대 시간의 50% 가 지나면 DHCP 갱신 과정 수행.

• DHCP Request 를 DHCP 로 곧바로 전송 (Discover, Offer 과정 생략)
• DHCP 서버에서는 DHCP ACK 를 보내며 갱신 과정 진행.
  • 유니캐스트로 진행되어 불필요한 브로드캐스트 X

임대 시간의 50% 가 지난 시점에서 갱신이 실패하면 → 남은 시간의 50%가 지난 시점, 즉 75% 가 지난 시점에서 다시 갱신 시도

• 이 때도 갱신 실패하면 추가 시간 갱신 없음
• 임대 시간이 모두 지난 후 IP 반납 → 다시 처음부터 IP 할당 진행.

IP 임대 시간

DHCP 를 사용하는 환경에 맞춰 알맞게 설정

• 클라이언트가 어느 정도 고정되어 있고 IP 풀 범위가 넓다면 → 길게
• 클라이언트가 불특정하며 자주 바뀌면 → 짧게

💡 DHCP Starvation 공격 (기아 상태 공격)
DHCP 서버에서 가용한 모든 IP를 가짜로 할당받아 실제 클라이언트가 IP 주소를 할당받지 못하게 하는 공격 방식

DHCP 서버 구성

설정 값

• IP 주소 풀(IP 범위)
  • 클라이언트에 할당할 IP 주소 범위
• 예외 IP 주소 풀(예외 IP 범위)
  • IP 풀 범위 중 예외적으로 할당하지 않을 대역
• 임대 시간
  • IP 주소 기본 임대 시간
• 서브넷 마스크
  • 클라이언트에 할당할 IP 주소에 대한 서브넷 마스크 정보
• 게이트웨이
  • 클라이언트에 할당할 게이트웨이 정보
• DNS
  • 클라이언트에 할당할 DNS 주소

DHCP 릴레이

• DHCP 클라이언트 ↔ 서버 패킷은 모두 브로드캐스트. (갱신 제외)
  • 브로드캐스트는 동일 네트워크에서만 전송 → DHCP 를 사용하려면 각 네트워크마다 DHCP 서버 필요.
• 하지만 여러 네트워크를 가진 환경에서도 DHCP 릴레이 에이전트를 사용하면 DHCP 서버 한 대로 여러 네트워크 대역에서 IP 풀 관리 가능.
• DHCP 릴레이 에이전트가 DHCP 클라이언트와 서버가 다른 대역에 있다면 → 중간에서 패킷을 중계해줌.
  • 브로드캐스트로 전달되는 DHCP 패킷을 동일 네트워크 대역의 DHCP 릴레이 에이전트가 수신
  • DHCP 서버로 갈 수 있게 유니캐스트로 변환
• 릴레이 에이전트를 이용하면 DHCP 서버를 네트워크마다 구성하지 않고 중앙 DHCP 서버만으로 여러 네트워크에서 DHCP 환경 운영 가능.

DHCP 릴레이 에이전트 동작 과정

1. DHCP Discover (클라이언트 → 릴레이 에이전트)

DHCP 클라이언트는 DHCP 서버를 찾기 위해 브로드캐스트로 패킷 전송.

 

2.DHCP Discover (릴레이 에이전트 → DHCP 서버)

릴레이 에이전트는 패킷 출발지와 목적지를 릴레이 에이전트 IP 와 DHCP 서버 IP 주소로 재작성 → 유니태스트

• 릴레이 에이전트 IP 항목에는 릴레이 에이전트 IP 주소 포함
• 출발지 주소로 사용되는 IP 주소는 DHCP 서버로 가기 위한 방향의 인터페이스 IP 주소
• DHCP 메시지에 사용되는 릴레이 에이전트 IP 주소는 DHCP 클라이언트가 속한 내부 인터페이스 IP 주소

3. DHCP Offer(DHCP 서버 → 릴레이 에이전트)

Discover 를 수신한 DHCP 서버가 DHCP 메시지를 DHCP 릴레이 에이전트로 다시 전송

• DHCP Server Identifier = DHCP 서버 자신
• 유니캐스트
  

4. DHCP Offer(릴레이 에이전트 -> 클라이언트)

• 브로드캐스트로 다시 전송
• DHCP Server Identifier : 실제 DHCP 서버 IP 주소 → 릴레이 에이전트의 외부 인터페이스 IP 주소로 변경되어 전송

5. DHCP Request(클라이언트 → 릴레이 에이전트)

DHCP 서버로부터 제안받은 IP 주소와 DHCP 서버 정보를 포함한 DHCP 요청 메시지를 브로드캐스트로 전송.

 

6. DHCP Request(릴레이 에이전트 → DHCP 서버)

유니캐스트로 다시 변환해 DHCP 서버로 전달.

 

7. DHCP ACK(DHCP 서버 → 릴레이 에이전트)

DHCP 요청을 받은 DHCP 서버가 IP 를 어떤 클라이언트가 언제부터 사용했는지 기록,

- DHCP Request 메시지를 정상적으로 수신했다는 응답 전달.

- 유니캐스트

 

8. DHCP ACK(클라이언트 → 릴레이 에이전트)

DHCP 서버에서 받은 ACK 메시지를 클라이언트에게 다시 브로드캐스트로 전달.

 

💡 DHCP 클라이언트와 DHCP 릴레이 에이전트 간에는 브로드캐스트.
DHCP 릴레이 에이전트와 DHCP 서버 간에는 유니캐스트로 동작.

DHCP 릴레이 에이전트는 DHCP 클라이언트와 같은 L2 네트워크 내에 존재
DHCP 서버에는 유니캐스트로 전달하기 위한 DHCP 서버의 IP 주소가 등록되어 있어야 함.