7장. 통신을 도와주는 네트워크 주요 기술

1. NAT / PAT

✍ NAT(Network Address Translation, 네트워크 주소 변환) : 네트워크 주소를 변환하는 기술
📌 기본적으로 하나의 네트워크 주소에 다른 하나의 네트워크 주소로 변환하는 1:1 변환이 기본이지만 IP 주소가 고갈되는 문제를 해결하기 위해 1:1 변환이 아닌 여러 개의 IP를 하나의 IP로 변환하기도 함
✍ PAT(Port Address Translation) : 공인 IP 주소 1개에 사설 IP 주소 여러개를 매핑하는 것

1-1. NAT / PAT의 용도와 필요성

• IPv4 주소 고갈문제의 솔루션으로 NAT가 사용
• 보안을 강화하는 데 NAT 기술 사용(내부 네트워크에서 외부 네트워크로 나가는 방향통신은 허용하지만 외부에서 시작해 내부로 들어오는 통신은 방어 가능)

			외부 구간에서는 내부 장비의 IP가 보이지 않도록 NAT를 사용

• IP 주소 체계가 같은 두 개의 네트워크 간 통신을 가능하게 해줌(공인 IP는 인터넷에서 유일한 주소로 IP 주소가 중복되면 안 되지만 사설 IP는 외부와 통신할 때 공인 IP로 변환하여 통신하므로 서로 다른 회사에서 중복해 사용 가능)

			사용하는 사설 IP 대역이 같은 회사끼리의 통신을 위해 더블 NAT를 사용

• 불필요한 설정 변경을 줄일 수 있음

1-2. NAT 동작 방식

									NAT 동작 순서

1. 사용자는 웹 서버에 접근하기 위해 출발지 IP와 포트를 10.10.10.10과 2000으로, 목적지 IP와 서비스 포트는 20.20.20.20과 80으로 패킷 전송
2. NAT 역할을 수행하는 장비에서 사용자가 보낸 패킷을 수신한 후 NAT 정책에 따라 외부 네트워크와 통신이 가능한 공인 IP인 11.11.11.11로 IP 주소를 변경
3. NAT 장비에서 출발지 주소를 11.11.11.11로 변경해 목적지 웹 서버로 전송
4. 패킷을 수신한 웹 서버는 사용자에게 응답을 보냄, 수신한 내용과 반대로 출발지는 웹 서버(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)로 변경해 사용자에게 전송하면 사용자는 최종적으로 패킷 수신

1-3. PAT 동작 방식

									PAT 동작 순서

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

						PAT는 내부에서 외부로 출발하는 경우에만 가능

1-4. SNAT와 DNAT

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

									SNAT와 DNAT

• SNAT는 사설에서 공인으로 통신할 때, 보안상, 대외사와 통신해야 하는 사내 IP가 대외사의 사내 IP 대역과 중복될 때, 로드 밸런서의 구성에 따라 사용

									SNAT를 하는 경우

• DNAT은 로드 밸런서, 사내가 아닌 대외망과의 네트워크 구성에 사용

									DNAT을 하는 경우
                                    

1-5. 동적 NAT와 정적 NAT

✍ 정적 NAT : 출발지와 목적지의 IP를 미리 매핑해 고정해놓은 NAT
✍ 동적 NAT : 출발지나 목적지 어느 경우든 사전에 정해지지 않고 NAT를 수행할 때 IP를 동적으로 변경하는 것

• 동적 NAT는 최소한 출발지나 목적지 중 한 곳이 다수의 IP로 구성된 IP 풀이나 레인지로 설정되어 있음
• 정적 NAT는 출발지와 목적지 매핑 관계가 특정 IP로 사전에 정의된 것이므로 1:1 NAT라고 부르기도 함
• NAT 테이블은 설정된 시간 동안 유지되고 일정 시간 동안 통신이 없으면 다시 사라짐

								동적 NAT와 정적 NAT의 테이블

2. DNS

✍ DNS(Domain Name System) : 도메인 주소를 IP 주소로 변환하는 역할을 수행

2-1. DNS 소개

• IP 주소 대신 도메인 주소를 이용하면 하나의 IP 주소를 이용해 여러 개의 웹 서비스를 운영할 수 있음
• 서비스 중인 IP 주소가 변경되더라도 도메인 주소 그대로 유지해 접속 방법 변경 없이 서비스를 그대로 유지할 수 있음
• 대부분의 웹사이트는 도메인 주소 기반으로 운영

	naver.com 접속을 위한 절차. DNS 서버에 이름 풀이를 요청한 후 IP 주소를 알아내 통신을 시작

1. 사용자가 웹 브라우저에 naver.com을 입력 시 DNS 서버에 naver.com의 주소가 무엇인지 질의하고 DNS 서버는 naver.com의 IP 주소가 202.179.177.21이라고 사용자에게 알려줌
2. 사용자는 DNS로 응답받은 202.179.177.21이라는 IP 주소를 이용해 실제 naver.com에 접속

2-2. DNS 구조와 명명 규칙

• 역트리 구조로 최상위 루트부터 Top-Level 도메인, Second-Level 도메인, Third-Level 도메인과 같이 하위 레벨로 원하는 주소를 단계적으로 찾아감
• 각 계층의 경계를 "."으로 표시하고 뒤에서 앞으로 해석

									도메인 계층

루트 도메인

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

Top-Level Domain(TLD)

• Generic TLD(gTLD) : 일반적으로 사용되는 최상위 도메인이며 세 글자 이상으로 구성

					1980년대에 만들어진 초기 Generic TLD 리스트

• Country Code TLD(ccTLD) : 국가 최상위 도메인, 우리나라는 'kr'을 사용
• Sponsored(sTLD) : 특정 목적을 위한 스폰서를 두고 있는 최상위 도메인(ex. ".aero", ".asia", ".edu", ".museum")
• Infrastructure : 운용상 중요한 인프라 식별자 공간을 지원하기 위해 전용으로 사용되는 최상위 도메인(ex. ".arpa")
• Generic-restricted(grTLD) : 특정 기준을 충족하는 사람이나 단체가 사용할 수 있는 최상위 도메인(ex. ".biz", ".name", ".pro")
• Test(tTLD) : IDN 개발 프로세스에서 테스트 목적으로 사용하는 최상위 도메인(ex. ".test")

2-3. DNS 동작 방식

• 도메인을 IP 주소로 변환하려면 DNS 서버에 도메인 쿼리하는 과정을 거쳐야 함(DNS 서버 없이 로컬에 도메인과 IP 주소를 직접 설정해 사용 가능)
• 도메인을 쿼리하면 DNS 서버에 쿼리를 하기 전 로컬에 있는 DNS 캐시 정보를 먼저 확인
  - 캐시 정보에는 기존 DNS 조회를 통해 확인한 동적 DNS 캐시와 함께 hosts 파일에 저장되어 있는 정적 DNS 캐시가 함께 저장

  ✍ hosts 파일 : 도메인과 IP 주소를 관리하는 파일

• DNS 캐시 정보에 필요한 도메인 정보가 없을 시 DNS 서버로 쿼리를 수행하고 DNS 서버로부터 응답을 받으면 그 결과를 캐시에 먼저 저장

						로컬 캐시 유무에 따른 도메인 쿼리 방법
                        

• 클라이언트에서 처음 질의를 받은 DNS가 중심이 되어 루트 DNS부터 상위 DNS에 차근차근 쿼리를 보내 결괏값을 알아낸 후 최종 결괏값만 클라이언트에 응답

						도메인의 재귀적 쿼리와 반복적 쿼리
                        

• 재귀적 쿼리(Recursive Query) : 호스트가 DNS 서버에 질의했던 방식(클라이언트와 로컬 DNS 간에서 사용)
• 반복적 쿼리(Iterative Query) : DNS 서버가 루트 NS와 TLS NS, zigispace NS에 질의한 방식(로컬 DNS 서버와 상위 DNS 구간에서 사용)

위 그림 동작 방식
1. 사용자 호스트는 'zigispace.net'이라는 도메인 주소의 IP 주소가 로컬 캐시에 저장되어 있는지 확인
2. 'zigispace.net'이 로컬 캐시에 저장되어 있지 않으면 사용자 호스트에 설정된 DNS에 'zigispace.net'에 대해 쿼리
3. DNS 서버는 'zigispace.net'이 로컬 캐시와 자체에 설정되어 있는지 직접 확인하고 없으면 해당 도메인을 찾기 위해 루트 NS에 .net에 대한 TLD 정보를 가진 도메인 주소를 쿼리
4. 루트 DNS는 'zigispace.net'의 TLD인 '.net'을 관리하는 TLD 네임 서버 정보를 DNS 서버에 응답
5. DNS는 TLD 네임 서버에 'zigispace.net'에 대한 정보를 다시 쿼리
6. TLD 네임 서버는 'zigispace.net'에 대한 정보를 가진 zigi 네임 서버에 대한 정보를 DNS 서버로 응답
7. DNS는 zigi 네임 서버에 'zigispace.net'에 대한 정보를 쿼리
8. zigi 네임 서버는 'zigispace.net'에 대한 정보를 DNS 응답
9. DNS는 'zigispace.net'에 대한 정보를 로컬 캐시에 저장하고 사용자 호스트에 'zigispace.net'에 대한 정보를 응답
10. 사용자 호스트는 DNS로부터 받은 'zigispace.net'에 대한 IP 정보를 이용해 사이트에 접속

2-4. 마스터와 슬레이브

• DNS 서버는 마스터(Master, Primary) 서버와 슬레이브(Slave, Secondary) 서버로 나뉨
• 두 서버 모두 도메인 쿼리에 응답, 도메인에 대한 존(Zone) 파일을 직접 관리하는지 여부에 따라 마스터 서버와 슬레이브 서버로 구분
• 마스터 서버
  • 존 파일을 직접 생성해 도메인 관련 정보 관리
• 슬레이브 서버
  • 마스터에 만들어진 존 파일을 복제

						DNS 서버의 영역 전송(Zone Transfer)

✍ 영역 전송(Zone Transfer) : 마스터 서버에서 존 파일을 직접 생성 및 관리하고 슬레이브 서버는 마스터에 만들어진 존 파일을 복제하는데 이러한 과정을 영역 전송이라 함

• DNS 서버는 마스터 서버에 문제가 발생하고 일정 시간이 지나면 슬레이브 서버도 도메인에 대한 질의에 정상적으로 응답할 수 없음(만료 시간)
• 만료 시간 안에 마스터 서버를 복구하거나 슬레이브 서버를 마스터로 전환해야 서비스 장애를 막을 수 있음

2-5. DNS 주요 레코드

• A(IPv4) 레코드 : 기본 레코드로 도메인 주소를 IP 주소로 변환하는 레코드, IPv4 주소 체계에서 사용
• AAAA(IPv6) 레코드 : IPv6 주소 체계에서 사용
• CNAME(Canonical Name) 레코드 : 별칭 이름을 사용하게 해주는 레코드(ex. www)
• SOA(Start Of Authority) 레코드 : 도메인 영역에 대한 권한을 나타내는 레코드
• NS(Name Server) 레코드 : 도메인에 대한 권한이 있는 네임 서버 정보를 설정하는 레코드
• MX(Mail eXchange) 레코드 : 메일 서버를 구성할 때 사용하는 레코드
• PTR(Pointer) 레코드 : IP 주소에 대한 질의를 도메인 주소로 응답하기 위한 레코드
• TXT(TeXT) 레코드 : 도메인에 대한 설명과 같이 간단한 텍스트를 입력할 수 있는 레코드

2-6. DNS에서 알아두면 좋은 내용

✍ 도메인 위임(DNS Delegation) : 도메인은 그 도메인에 대한 정보를 관리할 수 있는 네임 서버를 지정하지만 도메인 내의 모든 레코드를 그 네임 서버가 직접 관리하지 않고 일부 영역에 대해서는 다른 곳에서 레코드를 관리하도록 위임하는 방식

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

✍ 화이트 도메인 : 정상적인 도메인을 인증, 관리하는 제도

📌 도메인 주소는 영문 뿐만 아니라 한글로 주소를 만들 수 있음, 사용자가 도메인을 한글로 사용하기 위해 DNS에서 해당 한글을 "퓨니코드"로 변경하고 이 퓨니코드로 DNS에 도메인을 생성해야 함

📌 퓨니코드 : 애플리케이션 국제화 도메인 네임(IDNA) 기반 하에서 다국어 도메인이 아스키로 변환된 구문

3. GSLB

✍ DNS 로드밸런싱 : DNS에서 동일한 레코드 이름으로 서로 다른 IP 주소를 동시에 설정할 수 있는데 이런 설정으로 도메인 질의에 따라 응답받는 IP 주소를 나누어 로드밸런싱 한 것

					서비스가 불가능한 경우에도 도메인 질의에 응답

• 특정 서비스에 문제가 있을 때 DNS 서버는 이것을 감지하지 못해 사용자의 도메인 질의 요청에 비정상 상태인 서비스 IP 주소를 응답한 경우, 사용자는 해당 서비스에 접근할 수 없음

✍ GSLB(Global Server/Service Load Balancing) : 도메인을 이용한 로드밸런싱 구현을 도와줌

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

		GSLB는 서비스에 대한 헬스 체크를 수행해 서비스가 가능한 도메인 질의에 대해서만 응답

3-1. GSLB 동작 방식

							GSLB를 통한 도메인 질의 흐름
                            

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

3-2. GSLB 구성 방식

• GSLB를 사용한 도메인 설정 방법
  • 도메인 자체를 GSLB로 사용 : 해당 도메인에 속하는 모든 레코드 설정을 GSLB 장비에서 관리, 도메인에 대한 모든 레코드를 GSLB에서 설정
  • 도메인 내의 특정 레코드만 GSLB를 사용 : DNS에서 도메인 설정 시 GSLB를 사용하려는 레코드에 대해서만 GSLB로 처리하도록 설정

3-3. GSLB 분산 방식

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

4. DHCP

✍ DHCP(Dynamic Host Configuration Protocol) : IP를 동적으로 할당하는 데 사용하는 프로토콜, 사용자가 직접 입력해야 하는 IP 주소, 서브넷 마스크, 게이트웨이, DNS 정보를 자동으로 할당받아 사용할 수 있음

4-1. DHCP 프로토콜

• DHCP는 BOOTP(Bootstrap Protocol)라는 프로토콜을 기반으로 함
• DHCP는 서버와 클라이언트로 동작하며 클라이언트의 서비스 포트는 68(bootpc), 서버의 서비스 포트는 67(bootps)임

4-2. DHCP 동작 방식

								DHCP 패킷의 4단계 흐름

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

									DHCP 갱신 흐름

✍ 임대시간 : DHCP 할당 IP 주소는 영구적이지 않으며 약 24 시간 후에 만료되는 시간

• DHCP에서 IP를 할당받은 후 임대 시간의 50%가 지나면 DHCP 갱신 과정을 수행
• DHCP 클라이언트는 처음 수행한 임대 과정과 달리 DHCP 서버 정보와 이미 사용 중인 IP 정보가 있어 DHCP Discover와 DHCP Offer 과정을 생략하고 DHCP Request를 DHCP로 곧바로 전송하고 DHCP 서버에서 DHCP ACK를 보내면서 갱신 과정을 진행
• 임대 시간이 50%가 지난 시점에서 갱신이 실패하면 남은 시간의 50%가 지난 시점, 즉 초기 임대 시간의 75%가 지난 시점에서 갱신을 다시 시도하게 됨
• 초기 임대 시간의 75%가 지난 시점에서도 갱신을 실패할 시 추가 갱신 없이 임대 시간이 모두 지난 후에 IP를 반납하고 다시 처음부터 IP를 할당받음

4-3. DHCP 서버 구성

• DHCP 서버 구성 시 주로 설정하는 값
  • IP 주소 풀(IP 범위) : 클라이언트에 할당할 IP 주소 범위
  • 예외 IP 주소 풀(예외 IP 범위) : 클라이언트에 할당할 IP 주소로 선언된 범위 중 예외적으로 할당하지 않을 대역
  • 임대 시간 : 클라이언트에 할당할 IP 주소의 기본 임대 시간
  • 서브넷 마스크(Subnet Mask) : 클라이언트에 할당할 IP 주소에 대한 서브넷 마스크 정보
  • 게이트웨이(Router) : 클라이언트에 할당할 게이트웨이 정보
  • DNS(Domain Name Server) : 클라이언트에 할당할 DNS 주소

4-4. DHCP 릴레이

• DHCP 서버에서 IP 주소를 할당받기 위해 DHCP 클라이언트와 DHCP 서버 간에 전송되는 패킷은 모두 브로드캐스트인데 브로드캐스트는 동일 네트워크에만 전송되므로 DHCP를 사용하려면 각 네트워크마다 DHCP 서버가 있어야 함

			네트워크가 분리된 환경에서는 각 네트워크별로 DHCP 서버를 구성해야 한다.

• DHCP 릴레이 에이전트(Relay Agent) 기능을 사용하면 DHCP 서버 한 대로 여러 네트워크 대역에서 IP 풀을 관리할 수 있음

					DHCP 릴레이 에이전트의 구성과 통합된 DHCP 서버 구성

• 릴레이 에이전트를 이용하면 DHCP 서버를 네트워크마다 구성하지 않고 중앙 DHCP 서버만으로 여러 네트워크에서 DHCP 환경을 운영할 수 있음

1. DHCP Discover(클라이언트 -> 릴레이 에이전트) : DHCP 클라이언트는 DHCP 서버를 찾기위해 브로드캐스트로 패킷을 전송
   
   
2. DHCP Discover(릴레이 에이전트 -> DHCP 서버) : DHCP 릴레이 에이전트는 클라이언트가 보낸 DHCP Discover 메시지를 다른 네트워크에 있는 DHCP 서버로 전달하기 위해 출발지와 목적지를 릴레이 에이전트 IP 주소와 DHCP 서버 IP 주소로 재작성
   
   
3. DHCP Offer(DHCP 서버 -> 릴레이 에이전트) : DHCP Discover를 수신한 DHCP 서버는 클라이언트에 할당할 IP 주소와 서브넷, 게이트웨이, DNS 정보, 임대 시간(Lease Time)등의 정보를 포함한 DHCP 메시지를 DHCP 릴레이 에이전트로 다시 전송
   
   
4. DHCP Offer(릴레이 에이전트 -> 클라이언트) : DHCP 릴레이 에이전트는 DHCP Offer 메시지를 DHCP 클라이언트에 브로드캐스트로 다시 전송, DHCP 메시지 내의 다른 값은 모두 동일하게 전송되지만 DHCP Server Identifier는 실제 DHCP 서버의 IP 주소에서 릴레이 에이전트의 외부 인터페이스 IP 주소로 변경되어 전송
   
   
5. DHCP Request(클라이언트 -> 릴레이 에이전트) : DHCP 클라이언트는 DHCP 서버로부터 제안받은 IP 주소(Requested IP)와 DHCP 서버정보(DHCP Server Identifier)를 포함한 DHCP 요청 메시지를 브로드캐스트로 전송
   
   
6. DHCP Request(릴레이 에이전트 -> DHCP 서버) : DHCP 클라이언트에서 보낸 DHCP 요청 메시지를 유니캐스트로 다시 변환해 DHCP 서버로 전달
   
   
7. DHCP ACK(DHCP 서버 -> 릴레이 에이전트) : DHCP 요청을 받은 DHCP 서버는 해당 IP를 어떤 클라이언트가 언제부터 사용하기 시작했는지 정보를 기록하고 DHCP Request 메시지를 정상적으로 수신했다는 응답을 전송
   
   
8. DHCP ACK(릴레이 에이전트 -> 클라이언트) : DHCP 서버에서 받은 ACK 메시지를 클라이언트에 브로드캐스트로 다시 전달