[CS/네트워크] 7장 통신을 도와주는 네트워크 주요 기술

IP 주소를 자동으호 할당해주는 DHCP(Dynamic Host Configuration Protocol), 도메인 이름과 IP 주소를 매핑해주는 DNS(Domain Name System), 가장 가까운 지역 데이터 센터에 접속해 신속 서비스를 받게 해주는 GSLB(Global Service Load Balancing), 하나의 IP로 여러 단말 포함하는 네트워크 쉽게 구축하도록 해주는 NAT

7.1 NAT/PAT

NAT(Network Address Translation, 네트워크 주소 변환)은 사용자도 모르게 실생활에서 많이 사용되는 기술. 공유기, 통신사 장비가 NAT를 수행해 외부와 통신. L3 장비에서도 쓰이고 특히 L4 이상의 장비에서는 매우 빈번.

네트워크 1:1변환이 기본이지만 IP 고갈 문제 해결을 위해 여러 IP를 하나의 IP로 다대일 변환하기도. 다대일도 NAT라 불리긴 하지만 실제 공식 용어는 NAPT(NA Port T). 실무에서는 또 PAT라는 용어로 사용.

"NAT는 IP 주소를 다른 IP 주소로 변환해 라우팅을 원활히 해주는 기술" : 인터넷 표준 문서 정의

사설 → 공인(가장 많음), 공인 → 사설, 사설 → 사설, 공인 → 공인 다 NAT로 정의 될 수 있음. 확대해서 IPv4 → IPv6, IPv6→IPv4해주는 AFT(Address Family Translation)도 NAT의 일종.

7.1.1 NAT/PAT의 용도와 필요성

1. IPv4 주소 고갈 문제의 솔루션으로 NAT가 사용3단계 전략
   • 단기 : 서브네팅
   • 중기 : NAT, 사설 IP 체계
   • 장기 : IPv6 전환
   NAT가 큰 기여. 외부 공개 서비스 = 공인 IP, 공개 필요 없는 서비스, 단말 = 사설 IP ⇒ 효율
2. 3단계 IP 주소 보존, 전환 전략이 잘 만들어져서 IPv4 문제가 많이 해소 되었음.
3. 보안을 강화하는데 NAT 기술 사용
4. 외부 통신 시 내부 IP를 다른 IP로 변환, 통신하면 사내 IP 주소 체계를 숨길 수 있음. NAT는 주소 변환 후 역변환이 정상적으로 다시 수행되어야만 통신이 가능 ⇒ 내부→외부 허용, 외부 → 내부 통신 방어 가능.
5. IP 주소 체계가 같은 두 네트워크 간 통신을 가능하게 함.IP 대역이 같은 네트워크와 통신 가능성이 높은 대외계 너트워크를 연결하기 위해 출발지, 도착지를 한꺼번에 변환하는 "더블 나트(Double NAT)" 기술 사용.
6. 사설 IP를 통해서 다른 회사와 직접 연결할 때 충돌 할 수도 있다. 특히 대외계라 부르는 회사간 통신에서 빈번(카드사, 은행 간 연결). 인터넷 구간을 이요하기도 하지만 개인정보 보호, 각종 법규 준수(Compliance)로 별도 전용 회선, 암호화된 별도 네트워크 이용.
7. 불필요한 설정 변경 줄일 수 있음.
8. KISA를 통해 인터넷 독립 기관으로 직접 등록 or 소요한 IP를 받아 운영하는 경우가 아니면 통신사업자나 IDC를 통해 IP 할당 받아 사용하게 된다. 소유가 아니라 임시이기 때문에 사업자,IDC를 바꾸게 되면 기존 공인 IP를 사용 못하고 신규 사업자에게 받은 IP로 변경해야 함. NAT/PAT를 이용해 네트워크 구성하고 있다면 서버, PC IP 변경 없이 회선과 IDC 사업자 이전이 가능. 공인 IP 변경으로 DNS, NAT 수행 네트워크 장비 설정은 변경해야 하지만 내부 변경은 최소화 할 수 있어서 복잡한 작업을 많이 줄일 수 있음. 유연 Infra 기본 요소, 비즈니스 유연성 ⬆️

장점만 있는 건 아님. IP 변환되면 장애 발생시 문제해결 힘듦. 개발시 고려사항이 더 많아지는 문제. IPv6는 이런 어려움을 주는 NAT를 인터넷에서 없애려는 목표도 있음. NAT로 단말 간 직접 연결이 무너졌고 개발자들이 더 고려하는 상황. NAT의 한계 극복을 위해 NAT 밑에 있는 단말도 직접 연결하게 도와주는 홀 펀칭(Hole Punching) 기술. ⇒ 더 복잡 악순환.

7.1.2 NAT 동작 방식

출발지 IP를 NAT 테이블을 통해 공인 IP로 변환 : NAT 테이블에는 출발지 IP와 외부 사용할 공인 IP가 매핑. 웹서버에서 응답시에도 NAT에 기록된 공인 IP로 도착지 IP 지정 응답.

7.1.3 PAT 동작 방식

다수 IP 출발지에서 목적지로 갈 때 NAT 테이블 생성, 응답에 대해 NAT 테이블 참조 가능.

출발지 IP, 포트도 공인 IP, 서비스 포트로 변경. 이 두 정보 역시 NAT 테이블에 기록. 응답 시에도 공인 IP와 서비스 포트로 전송. 다른 IP 사용자가 NAT 통해 갈 경우 동일한 공인 IP 사용, 다른 서비스 포트. 즉, PAT는 NAT와 거의 동일, 서비스 포트까지 함께 변경 ⇒ 하나의 IP 만으로도 다양한 포트 번호를 사용해 구분 가능. 제한된 포트 개수, 재사용되긴 함. 서비스 포트가 모두 사용 중이면 PAT 정상 작동 X. 공인 IP 주소를 풀(Pool)로 구성해야 함.

PAT IP가 목적지일 때는 바인딩 되어있는 NAT 테이블이 없으므로 사용할 수 없다. PAT는 SNAT와 DNAT 중 SNAT에만 적용. 내부에서 외부로 출발하는 경우에만 가능하다.

7.1.4 SNAT와 DNAT

어떤 IP 주소를 변환하는지에 따라 두 가지로 구분한다. 트래픽 출발 시작 지점을 기준으로 구분.

• SNAT(Source NAT) - 출발지 주소를 변경하는 NAT
• DNAT(Destination NAT) - 도착지 주소를 변경하는 NAT

둘 다 기준은 NAT 수행 전 트래픽 출발 지점이다. 예로 들면 SNAT로 전송된 트래픽에 대한 응답은 응답 기준으로는 DNAT가 되는 거 같지만 시작 지점만 고려해 SNAT 설정을 해야한다. 이런 과정을 역 NAT라고 하고 NAT 정상 수행에 필수 불가결

SNAT

1. 사설 → 공인 많이. 사설에서 출발하는 요청이 응답 받으려면 외부에서 당연히 사설이 NAT을 통해 공인된 IP를 목적지로 응답할 수 있기 때문
2. 다른 경우 보안상 SNAT 사용할 때. 회사 내부 IP 아닌 별도 다른 IP 전환해 전송으로 내부 실제 IP 숨김. + 사내 IP와 중복되는 대외사 사내 IP도 중복되지 않도록 해줌. 다만 이 경우는 변경되는 IP가 꼭 공인 IP일 필요는 없다.
3. 로드밸런서 구성에 따라 SNAT 사용하기도 함. 출발지, 목적지가 동일 대역일 경우 로드밸런서를 거쳐야 하는데 거치지 않고 응답할 수 있어서 SNAT을 통해 응답 트래픽이 로드 밸런서를 거치게 할 수 있음.

DNAT

로드 밸런서에서 많이 사용. 로드 밸런서에 설정된 서비스 VIP(Virtual IP)로 서비스를 요청, 로드밸런서에서는 서비스 VIP를 로드 밸런싱될 실제 IP로 DNAT해 내보냄.

대외망과의 네트워크 구성에서도 DNAT를 사용. 사내는 중앙 관리로 겹치지 않게 관리가 되지만, 대외망 연결은 IP가 중복 가능 or 제각각이므로 신규 연동마다 라우터를 개별적으로 설정해야 함. 대외사 IP를 특정 IP 대역으로 NAT.

7.1.5 동적 NAT와 정적 NAT

출발지, 목적지 IP를 미리 매핑해놓은 건 정적 NAT, NAT 수행시 IP를 동적으로 변경하는 것은 동적 NAT

동적 NAT는 다수의 IP 풀에서 정해지므로 최소 출발지 or 목적지 한 곳이 IP 풀이나 Range로 설정. NAT 필요시 IP 풀에서 판단, 수행 시점에 NAT 테이블 생성, 관리. 일정 시간 통신이 없으면 사라지므로(NAT 테이블 타임아웃) 서비스 흐름을 고려해 적용해야 함.

정적 NAT는 1:1NAT라고 부르기도. 방향성 없이 서비스 흐름 고려 않고 NAT 설정 가능

동적 NAT 정적 NAT

설정	1:N, N:1, N:M	1:1
NAT 테이블	NAT 수행시 생성	사전 생성
테이블 타임아웃	O	X
수행 정보	실시간 확인 or 로그	필요 X

7.2 DNS

데이터 프로토콜 - 실제로 데이터를 실어나름

컨트롤 프로토콜 - 데이터 프로토콜이 잘 동작하도록 도움, 통신 직접 관여 X. 처음 통신, 유지에 큰 역할. TCP/IP에서 주요 ARP, ICMP, DNS(Domain Name Service) : 도메인 주소를 IP 주소로 변환.

최근 클라우드 기반 인프라 구성 + MSA(Micro Service Architecture) 기반 서비스 설계 ⬆️ → 다수 API ⇒ DNS 중요도 ⬆️

DNS 소개, 구조, 동작방식, 주요 레코드.

7.2.1 DNS 소개

사이트 접속 시 IP 주소 or 도메인 주소 사용. 실제 접속은 IP로. 하지만 사용자가 사용하기 어려움. 숫자보다는 문자열로 구성된 도메인 주소가 쉬움. 또 IP 주소가 변경돼도 도메인 주소는 유지해서 서비스 유지 가능. 지리적으로 여러 위치에서 서비스 가능.

도메인을 실제 통신에 필요한 IP로 변환하는 DNS를 네트워크 설정에 입력. 도메인 접속시 해당 DNS로 IP 주소 질의, 결과값으로 도메인의 서비스 IP 주소를 받게 됨.

내부 시스템 서비스 연결에도 DNS 사용.

7.2.2 DNS 구조와 명명 규칙

도메인은 계층 구조 ⇒ 효율적. 역트리 구조 최상위 루트 → Top-Level 도메인(TLD) → Second-Level 도메인 → Third-Level 도메인 처럼 하위 레벨로 원하는 주소 단계적으로 찾는다. 각 계층 경계 “.” 뒤에서 앞으로 해석.

third.second.top(.)(root는 생략) ex) www.naver.com

← 이 방향으로 읽는 것

최대 128계층까지 구성 가능. 계층별 길이 최대 63byte. .을 포함한 전체 길이는 최대 255byte. 알파벳, 숫자, - 만 사용 가능. 대소문자 구분 X

7.2.2.1 루트 도메인

도메인 구성 최상위 영역. DNS 서버는 쿼리 값을 직접 갖고 있거나 캐시에 저장된 정보로 응답. DNS 서버에 없으면 루트 DNS(루트 도메인 관리)에서 쿼리. 루트 DNS는 전세계 13개. DNS 설치시 루트 DNS IP 주소를 기록한 힌트(Hint)파일을 가지고 있어 별도 설정 X

7.2.2.2 Top-Level Domain(TLD)

IANA(Internet Assigned Numbers Authority)에서 구분한 6가지 유형

• Generic(gTLD)
• 특별 제한 x. 세글자 이상으로 구성. com, edu, gov, int, miil, net, org
• country-code(ccTLD)
• ISO 3166 표준에 의해 규정된 두 글자 국가 코드. 우리나라 kr 같은.
• sponsored(sTLD)
• 특정 목적, 스폰서를 두고 있음. 특정 민족공동체, 전문가 집단, 지리적 위치. aero, asia, edu, museum
• infrastructure
• 인프라 식별자 공간 지원. arpa : 인터넷 안정성 유지 위해 새로운 모든 하위 도메인 배치될 공간 역할.
• generic-restricted(grTLD)
• 특정 기준 충족하는 사람 or 단체가 사용 가능. biz, name, pro
• test(tTLD)
• IDN(Internationalized Domain Names) 개발 프로세스에서 테스트 목적. test

7.2.3 DNS 동작 방식

DNS 서버 없이 로컬에 도메인과 IP를 직접 설정해 사용할 수도 있음. 이 파일을 hosts 파일이라고 함. → 항상 DNS 캐시에 저장.

도메인 쿼리시 DNS 서버 전에 로컬 DNS 캐시를 먼저 확인. 매번 질의 안하고 성능 향상을 위해. hosts, 기존 조회한 캐시. 캐시에 없으면 DNS 서버로 쿼리 수행, 캐시에 저장.

DNS 캐시 확인하려면 ipconfig/displaydns 명령어로 확인 가능

폭증하는 단말을 중앙 쳬게 수용을 위해 DNS 체계 만들어짐. 그냥 hosts처럼 플랫이 아닌 계층 구조 채택.

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

DNS는 분산된 DB로 서로 도와주도록 설계, 자신이 가지지 않은 도메인은 다른 DNS에 질의해 결과 받을 수 있음. DNS 서버는 기본적으로 루드 DNS 관련 정보를 갖고 있음. 자신에게 없으면 루트 DNS에 쿼리, 루트 DNS에서는 쿼리 도메인의 TLD 확인해 해당 관리 DNS 응답.

클라이언트의 처음 질의를 받은 DNS가 중심이 되어 루트 DNS,상위 DNS에서의 결과값 응답.

재귀적 쿼리(Recursive Query) : 호스트가 DNS 서버에 질의하는 방식. 클라이언트에 서버가 최종 결괏값 반환하는 서버 중심 쿼리. 클라이언트와 로컬 DNS 간 사용

반복적 쿼리(Iterative Query) : DNS 서버가 루트 NS, TLS NS ... 질의하는 방식. 최종값 받을 때까지 클라리언트에서 계속 쿼리 진행하는 방식. 로컬 DNS 서버와 상위 DNS 구간에서 사용. 이때 로컬 DNS가 클라이언트로 동작

7.2.4 마스터와 슬레이브

DNS 서버

• 마스터 서버(Master, Primary) 서버슬레이브 서버 지정해서 복제 제한 가능
• 존(Zone) 파일 직접 생성해 도메인 관련 정보 관리. 도메인 영역 생성, 레코드 직접 관리
• 슬레이브(Slave, Secondary) 서버만들 때 마스터 서버 정보를 입력해야 함.
• 마스터 존 파일 복제(영역 전송(Zone Transfer)). 머스터 서버 설정된 도메인이 가진 레코드 정기 복제

우선 순위 차이는 없다. 두 서버 모두 도메인 쿼리에 응답. 존(Zone) 파일 직접 관리 여부로 구분. 그림 7-19 참고

이중화에서 일반적으로 사용하는 Active-Stanby 나 Active-Active로 구성하지 않는다. 보통 이중화는 액티브에 문제가 생겨도 다른 스탠바이나, 액티브에서 그대로 서비스하는 반면, DNS 서버는 마스터 서버 문제 발생시 일정 시간 후 슬레이브 서버에서도 응답 불가. 이 시간을 만료 시간(Expiry Time), SOA 레코드에 설정. 만료 시간 안에 존 정보를 받아오지 못하면 슬레이브 존 정보 사용 불가.

⇒ 만료 시간 안에 마스터 서버 복구 or 슬레이브를 마스터로 전환 해야 서비스 장애 막을 수 있음.

마스터, 슬레이브는 도메인별로 설정 가능 but 추천하지 않는다. 마스터는 모든 도메인에 대해 마스터, 슬레이브는 모두 슬레이브가 바람직

---

액티브-스탠바이와 액티브-액티브

일부가 정상 작동 아니어도 서비스 지속될 수 있도록 해주는 고가용성 기술(High Availability). 이를 위해 일반적 구조가 액티브-스탠바이, 액티브-액티브.

• 액티브-액티브 : 두 개 노드가 동시 서비스 제공, 한 노드 문제 발생시 다른 노드 계속 서비스 제공
• 액티브-스탠바이 : 한 노드만 서비스, 하나는 대기. 액티브 장애시 스탠바이 서비스 시작

두 대가 모두 죽지 않는 한 정상적 서비스 제공

7.2.5 DNS 주요 레코드

표 7-4 참고

7.2.5.1 A(IPv4) 레코드

기본 레코드. 도메인 주소를 IP 주소로 변환하는 레코드. 하나의 A 레코드에 도메인, IP가 1:1로 매핑. 동일 도메인 가진 A 레코드 여러개로 다른 IP 주소와 매핑 가능. 다수 도메인에 동일 IP 매핑도 가능. HTTP 헤더와 HOST 필드에 도메인 명시로 웹 서버 구분하면 된다.

7.2.5.2 AAAA(IPv6) 레코드

A와 같은 역할. IPv6에서 사용

7.2.5.3 CNAME(Canonical Name) 레코드

별칭 이름을 사용하게 해주는 레코드. A는 레코드 값에 IP 주소 매핑에 반해 CNAME은 도메인 주소를 매핑

7.2.5.4 SOA(Start Of Authority) 레코드

도메인 영역에 대한 권한을 나타내는 레코드. 도메인 영역 선언 시 SOA는 필수. 또한 현재 도메인 관리에 필요한 속성값 설정. 도메인 동기화에 필요한 타이머 값 or TTL, 도메인 네임 서버, 관리자 정보.

7.2.5.5 NS(Name Server) 레코드

도메인에 대한 권한이 있는 네임 서버 정보를 설정하는 레코드. + 하위 도메인에 대한 권한을 다른 네임 서버로 위임(Delegate)하는 역할.

7.2.5.6 MX(Mail eXchange) 레코드

메일 서버를 구성할 때 사용되는 레코드. 해당 도메인을 메일 주소로 갖는 메일 서버를 MX 레코드를 통해 선언. 우선순위 높은(값이 적은) 서버로 메일 보내고 실패시 다음 순서.

7.2.5.7 PTR(Pointer) 레코드

A 레코드는 도메인에 대한 질의를 IP로 응답하기 위한 레코드. 정방향 조회용 레코드.

이에 반해 PTR은 반대로 IP에 대한 질의를 도메인으로 응답하기 위한 레코드. 역방향 조회용 레코드.

A와 달리 하나의 IP에 대해 하나의 도메인만 가질 수 있음. PTR 레코드는 하나의 IP에 대해 하나만 갖는다. 주로 화이트 도메인 구성용으로 사용.

7.2.5.8 TXT(TeXT) 레코드

도메인에 대한 설명 등 간단 텍스트 입력할 수 있는 레코드. 특정 기능으로 사용 가능. 주로 화이트 도메인을 위한 SPF 레코드. 공백 포함 가능. 대소문자 구분. 최대 255자

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

• 도메인 위임 → GSLB 구성 때도 사용
• TTL → 도메인 변경 작업 위해 알면 좋음
• 화이트 도메인 → 메일 서버 운영시 필요
• 한글 도메인 → 기존 영문이 아닌 한글로 운영 위해

7.2.6.1 도메인 위임(DNS Delegation)

도메인은 도메인 정보를 관리할 수 있는 네임 서버를 지정, but 모든 레코드를 그 네임 서버가 직접 관리 않고 일부 영역은 다른 곳에서 레코드를 관리하도록 위임 하는 것이 도메인 위임. 위임한 곳에서 세부 레코드를 관리하도록 하는 것. CDN 이용 or GSLB 사용이 대표적. 도메인은 계층 구조이기에 특정 계층 하위 계층은 함께 위임 처리.

계열사 특정 도메인 분리 or GSLB 등 다양한 용도로 사용

7.2.6.2 TTL

도메인의 TTL(Time To Live) : DNS에 질의해 응답받은 결괏값을 캐시에서 유지하는 시간.

무작정 계속 갖고 있는 것이 아니라 DNS에 설정된 TTL 값에 따라 그 시간만큼 로컬 캐시에 저장. TTL 값을 늘려 캐시를 많이 쓰면 DNS 재귀적 쿼리로 인한 응답 시간 ⬇️ 전체 네트워크 응답 시간 ⬇️ 하지만 DNS에서 변경시 TTL 값이 크면 DNS 정보 갱신이 지연되는 단점. TTL이 너무 작으면 갱신이 너무 빨라져 DNS 쿼리량 ⬆️ DNS 서버 부하 ⬆️ 따라서 TTL값은 적절히 조절하자.

윈도우 DNS 기본 TTL = 3600s = 1시간, 리눅스 DNS 기본 TTL = 10800s = 3시간

---

기타 도메인 관련 시간

• refresh(새로 고침 간격): 보조 네임 서버에서 Zone Transfer로 정보 받아오는 주기
• retry(다시 시도 간격): 보조 → 주 네임 서버 접근 불가능시 재시도 주기
• expire(다음 날짜 이후 만료) : 유지되는 시간. 해당 시간동안 못받아오면 주 네임 서버 삭제로 간주, 보조 네임 서버에서도 해당 도메인 삭제.

---

7.2.6.3 화이트 도메인

정상 발송 대량 이메일이 RBL 이력으로 간주돼 차단을 예방하기 위해 사전 등록 개인, 사업자에 한해 주요 포탈 사이트로의 이메일 전송을 보장해주는 제도.

스팸 차단 활동 예방을 위해 정상 도메인 인증, 관리 제도가 ‘화이트 도메인’. 실시간 블랙리스트를 RBL(Realtime Blackhole List, Realtime Blocking List)라고 한다.

KISA RBL 사이트에서 등록. 사전에 해당 도메인에 SPF 레코드(Sender Policy Framework)가 설정돼야 함. SPF 레코드를 통해 사전 공개된 메일 서버 정보를 수신 측 메일 서버에서 일치하는지 확인할 수 있음. 일치하지 않으면 비정상적 이메일 서버 전송, 스팸 처리

SPF 레코드는 최대 512byte.서버 개수 제한에 유의

---

SPF 등록시 유의 사항

512byte IP는 약 13개. 초과시 모두 지워진다. 길이가 너무 길면 추가 등록 전 백업해둘 것.

---

도메인에 SPF 작성하려면 TXT 레코드 사용.

---

SPF에서 -all과 ~all의 차이

• -all : 발송 IP를 위조한 메일을 서버에서 폐기(Drop)하라
• ~all : 발송 IP를 위조한 메일을 서버 정첵에 따라 결정하라

---

7.2.6.4 한글 도메인

한글 도메인도 가능. 퓨니코드.

---

퓨니코드[Punycode]

IDNA 기반하 다국어 도메인이 아스키로 변환(Encoding)된 구문. 지식 백과 참고

---

한글뿐 아니라 영어 아닌 자국어 도메인을 사용할 수 있도록 해주는 표준 코드. 유니코드 문자열을 인코딩 하는 것 → 유니코드 지원 모든 언어 가능. “다국어 도메인 네임(IDN)”

퓨니 코드 변환기 존재

7.2.7 DNS 설정(Windows)

교재 참고

7.2.8 DNS 설정(Linux)

교재 참고

7.2.9 호스트 파일 설정

교재 참고

---

DNS의 시작

교재 참고

---

7.3 GSLB

DNS에서 동일 레코드 이름으로 서로 다른 IP 주소를 동시 설정하면 도메인 질의 따라 응답 IP를 나눠 로드 밸런싱 : DNS 로드밸런싱. DNS는 설정 서비스 상태 정상 여부 확인 안하고 무조건 응답하기에 문제가 있을 때 감지하지 못해 비정상 IP로 응답하면 사용자는 접근 못함. DNS는 서비스 가용성 향상 방법으로는 부적합.

GSLB(Global Server/Service Load Balancing)는 DNS의 이런 문제를 해결해 도메인 이용한 로드밸런싱 구현을 돕는다. GSLB는 헬스체크까지 수행. 등록 도메인 서비스 체크, 정상만 사용. 이런 이유로 ‘인텔리전스 DNS’라고도 부름.

7.3.1 GSLB 동작 방식

1. 사용자 DNS 질의
2. LDNS ⇒ NS 서버 찾기 위해 root 부터 순차 질의
3. DNS에 질의
4. DNS가 GSLB에 위임했으므로 GSLB 응답
5. 다시 GSLB에 질의
6. GSLB에서 헬스 체크 → 결과 응답
7. GSLB에서 받은 결괏값을 LDNS가 사용자에 최종 응답

GSLB는 갖고 있던 IP를 단순 응답이 아니라 헬스 체크해서 정상 여부 확인한다. 다수가 정상이면 사전 정의 알고리즘 통해 결정.

GSLB는 DNS를 사용하는 것과 거의 동일하게 동작. 다만 헬스 체크, 사전 지정 분산 방법을 이용한 부하 분산이 큰 차이점.(일반 DNS는 두 개 이상에 대해 단순 라운드 로빈(Round Robin, 순서대로 순환하는) 방식으로 응답)

7.3.2 GSLB 구성 방식

GSLB 사용한 도메인 설정 방법 2가지

1. 도메인 자체를 GSLB로 사용헬스체크가 불필요한 경우, 모든 레코드 질의가 GSLB를 통해 이루어지므로 부하.
2. 해당 도메인 속 모든 레코드 설정을 GSLB 장비에서 관리. GSLB 자체가 도메인 네임 서버 역할.
3. 도메인 내 특정 레코드만 GSLB를 사용
   1. 별칭(Alias) 사용(CNAME 레코드 사용)DNS로부터 GSLB 관리 도메인 있으면 받고 다시 root NS부터 질의해서 GSLB 찾기
   2. 외부 사업자, GSLB 사용해야하는 도메인이 많은 경우, 별도의 GSLB 운용 위해 사용
   3. 실제 도메인과 다른 별도의 도메인 레코드가 GSLB에 등록. 외부 CDN 사용 or 회사 내부에 GSLB 사용해야할 도메인이 많은 경우 한꺼번에 관리하기 위해 사용.
   4. 위임(Delegation) 사용(NS 레코드 사용)DNS로부터 해당 도메인 GSLB가 관리한다는 응답 그대로 GSLB에 질의계층적으로 GSLB를 이용한 FQDN을 관리할 때
   5. 계층화해 사용하면 DNS 서버 설정을 최소화해 GSLB로 다수의 FQDN을 위임 처리할 수 있다.
   6. 실제 도메인과 동일 레코드 사용, 도메인 전체 위임하는 것이 대표적
4. DNS에서 도메인 설정시 GSLB를 사용하려는 레코드에 대해서만 GSLB로 처리하도록 설정. 특정 레코드에 대해서만 GSLB로 처리를 이관하는 방법 2가지

많은 환경 다양한 서비스 혼재, NS와 CNAME 방식 혼용하기도

7.3.3 GSLB 분산 방식

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

라운드 로빈(Round Robin), 최소 접속(Least Connection), 해싱(Hashing) + α 방식 제공

장비, 모델에 따라 조금씩 다를 수 있지만 2가지 헬스 체크 모니터링 요소를 지원

1. 서비스 응답 시간/지연(RTT/Latency)
2. 요청에 대한 응답이 얼마나 빠른지, 지연이 얼마나 없나 확인하고 이를 이용해 서비스를 분산처리
3. IP에 대한 지리(Geography) 정보
4. 각 사이트 IP 주소에 대한 Geo 값 확인해 가까운 사이트로 서비스 분산

트래픽 분산 + 신속 서비스 제공 사이트로 접속할 수 있도록 유도하는 것이 궁극적 목표.

이 기준들은 사용자 기준이 아니라 사용자가 바라보는 Local DNS와 GSLB 간 값.

7.4 DHCP

IP를 동적으로 할당하는 데 사용되는 프로토콜이 DHCP(Dynamic Host Configuration Protocol). DHCP를 사용하면 사용자가 직접 입력해야 하는 IP 주소, 서브넷 마스크, 게이트웨이, DNS 정보를 자동으로 할동받아 사용할 수 있음. 사용자, 관리자 모두 편리, 사용하지 않은 IP는 회수, 사용시 재할당, 한정된 IP로 유용히 사용. 자동 관리 ⇒ 직접 입력 오류, 중복 IP 할당 문제 예방

7.4.1 DHCP 프로토콜

BOOTP(Bootstrap Protocol) 프로토콜 기반. 몇가지 기능이 추가된 확장 프로토콜. 둘은 호환성이 있음.

DHCP는 서버(67bootps)와 클라이언트(68bootpc)로 동작.

7.4.2 DHCP 동작 방식

신규 IP를 할당 받는 과정

4단계로 진행

1. DHCP DiscoverIP : 출발지 Zero IP(0.0.0.0), 목적지 브로드캐스트(255.255.255.255)
2. 서비스 포트 : 출발지 UDP 68(bootpc), 목적지 UDP 67(bootps). IP 할당 과정 ⇒ 패킷 정상 주고받을 수 없어 TCP 아닌 UDP 사용
3. DHCP 클라이언트가 DHCP 서버를 찾기 위해 DHCP Discover 메세지를 브로드캐스트 전송
4. DHCP OfferDiscover 메세지를 받은 DHCP 서버는 별도 설정이 없으면 IP Pool에서 임의로 할당. 특정 클라이언트 MAC, IP를 사전 정의해두면 DHCP를 하면서도 고정 IP를 할당 할 수 있다.
5. DHCP 서버가 클라이언트에 IP 주소 사용을 제안하는 단계
6. Discover를 수신한 서버는 클라이언트에 할당할 IP 주소, 서브넷, 게이트웨이, DNS 정보, Lease Time 등의 정보를 포함한 DHCP 메세지를 클라이언트로 전송
7. DHCP RequestOffer 안에 IP 설정 정보가 모두 포함 되어 있어 유니캐스트 해도 되지만 DHCP 여러대 환경을 위해 브로드캐스트. 서버는 자신이 보낸 Offer에 대한 Request인지 확인, 그 패킷에만 응답.
8. 서버로부터 제안받은 IP 주소(Requested IP)와 DHCP 서버 정보(DHCP Server Identifier)를 포함한 DHCP 요청 메세지를 브로드캐스트로 전송
9. DHCP Acknowledgement내용은 Offer와 동일. 역시 브로드캐스트로 전체 전송. 클라이언트는 할당받은 IP를 로컬에 설정하고 사용 시작
10. 클라이언트로부터 IP 주소를 사용하겠다는 요청을 받으면 서버에 해당 IP 사용 시작 정보 기록, DHCP Request 메세지 정상 수신 응답 전송

정해진 시간 동안 IP 사용할 수 있도록 할당하는 것이므로 ‘임대(Lease) 과정’이라고 한다. DHCP 서버 IP Pool에서 잠시 빌려쓰는 것.

IP 임대 시간은 DHCP 서버에서 지정해 전달. 만료시 다시 IP Pool로 회수

사용하는 도중 만료되면 Discover부터 다시 해야함. 이 과정 반복을 하지 않기 위해 사용 중인 경우 갱신(Renewal) 과정을 거쳐 반환되지 않고 계속 사용

DHCP 갱신 절차

임대시간 50% 지나면 갱신과정 수행. Discover, Offer 과정 생략. 3번 DHCP Request붙어 곧바로 전송, DHCP ACK를 통해 갱신 과정 진행. 임대 과정보다 짧고, 브로드캐스트가 아닌 유니캐스트 장점.

50% 지난 시점 갱신 실패시, 다시 남은 시간의 50%. 즉, 전체의 75%때 다시 갱신 시도. 이때도 실패하면 반납하고 다시 할당

권고 시간이 있는 건 아님. 환경에 맞추어 알맞게 설정.

---

DHCP 메시지 타입과 항목

4가지 타입의 DHCP 메시지 외에 더 많은 메시지.

Decline, Nak, Release, Inform 등이 더 있다.

---

---

DHCP Starvation 공격

IP Pool에서 전체 IP 주소 범위, 이미 임대된 IP 정보, 임대 시간, 할당 가능한 IP 주소 리스트 관리. 모든 IP를 소진한 상태에서 새 클라이언트의 Discover가 오면? IP 할당할 수 없다. 이를 악용해 모든 IP를 가짜로 할당 받아 실제 클라이언트가 할당 받지 못하게 공격하는 방식을 DHCP Salvation(기아 상태)

---

7.4.3 DHCP 서버 구성

윈도우 DHCP 서비스, 리눅스 DHCP 데몬, 스위치, 라우터, 방화벽, VPN 등 네트워크, 보안 장비에서도 DHCP 서비스 가능

DHCP 서버 구성시 설정값

• IP 주소 풀(IP 범위)
• 예외 IP 주소 풀(예외 IP 범위)
• 임대 시간
• 서브넷 마스크(Subnet Mask)
• 게이트웨이(Router)
• DNS(Domain Name Server)

7.4.3.1 윈도에서 DHCP 서버 구성

교재 참고

7.4.3.2 리눅스에서 DHCP 서버 구성

교재 참고

7.4.4 DHCP 릴레이

IP 할당 받기 위해 클라이언트 서버간 전송되는 패킷은 모두 브로드캐스트. 브로드캐스트는 동일 네트워크에서만 전송. 따라서 각 네트워크마다 DHCP가 있어야 한다.

하지만 DHCP 릴레이 에이전트(Relay Agent) 기능을 사용하면 DHCP 서버 한대로 여러 네트워크 대역에서 IP Pool을 관리할 수 있다. DHCP 릴레이 에이전트가 DHCP 패킷을 중간에서 중계(Relay)할 수 있음. 중간에서 수신하고서 DHCP 서버로 유니캐스트 해줌.

1. DHCP Discover(클라이언트 → 릴레이 에이전트)
2. 브로드 캐스트
3. DHCP Discover(릴레이 에이전트 → DHCP 서버)출발지에 쓰이는 IP는 서버 방향 인터페이스 IP, DHCP 메시지 내 IP는 클라이언트 내부 인터페이스 IP 주소. 즉, 둘이 다르다.
4. 출발지(릴레이 에이전트 IP), 목적지(DHCP 서버 IP) 재작성. 유니캐스트.
5. DHCP Offer(DHCP 서버 → 릴레이 에이전트)
6. 역시 유니캐스트
7. DHCP Offer(릴레이 에이전트 → 클라이언트)
8. DHCP Server Indentifier만 실제 DHCP 서버 IP주소에서 에이전트 외부 인터페이스 IP로 변경
9. DHCP Request(클라이언트 → 릴레이 에이전트)
10. 브로드캐스트
11. DHCP Request(릴레이 에이전트 → DHCP 서버)
12. 유니캐스트
13. DHCP ACK(DHCP 서버 → 릴레이 에이전트)
14. 유니캐스트
15. DHCP ACK(릴레이 에이전트 → 클라이언트)
16. 브로드캐스트

클라이언트 입장에서는 에이전트가 있든 없든 다르지 않다.

릴레이 에이전트와 DHCP 서버간 유니캐스트를 위해서 릴레이 에이전트는 클라이언트와 같은 L2 네트워크 내에 있어야 하고, DHCP 서버의 IP 주소가 등록되어 있어야 한다.