IT 엔지니어를 위한 네트워크 입문 - 3주차

임상규·2024년 2월 21일

DHCP DNS GSLB NAT/PAT SNAT/DNAT 방화벽

Network

목록 보기

5/7

6.3 방화벽

방화벽: 네트워크 중간에 위치해 해당 장비를 통과하는 트래픽을 사전에 주어진 정책 조건에 맞추어 허용(Permit)하거나 차단(Deny)하는 장비
일반적으로 네트워크 3, 4계층에서 동작하고 세션을 인지, 관리하는 SPI(Stateful Packet Inspection) 엔진을 기반으로 동작하는 장비를 방화벽이라 부름
방화벽은 NAT(Network Address Translation) 동작 방식과 유사하게 세션 정보를 장비 내부에 저장
패킷이 외부로 나갈 때 세션 정보를 저장하고 패킷이 들어오거나 나갈 때 저장했던 세션 정보를 먼저 참조해 들어오는 패킷이 외부에서 처음 시작된 것인지, 내부 사용자가 외부로 요청한 응답인지 가려냄
세션 테이블을 이용해 패킷의 인과 관계를 파악할 수 있어 정책을 간단히 유지

6.4 4계층 장비를 통과할 때의 유의점(세션 관리)

세션 장비는 일반적인 2, 3계층 네트워크 장비와 달리 세션을 이해하고 세션 테이블을 유지
세션 테이블 정보를 이용해 패킷을 변경하거나 애플리케이션 성능을 최적화하고 보안을 강화하기 위해 패킷을 포워드(Foward)하거나 드롭(Drop)할 수 있음
특히 애플리케이션의 세션 시간과 서비스 방향성을 고려하고 비대칭 경로를 피해주는 것이 매우 중요

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

종단 장비에서 통신을 시작하면 중간에 있는 세션 장비는 해당 세션 상태를 테이블에 기록
통신이 없더라고 종단 장비 간 통신이 정상적으로 종료되지 않았다면 일정 시간 동안 세션 테이블을 유지
세션 테이블은 메모리에 저장되므로 메모리 사용률을 적절히 유지하기 위해 일정 시간만 세션 정보를 저장
악의적인 공격자가 과도한 세션을 발생시켜 정상적인 세션 테이블 생성을 방해하는 세션 공격으로부터 시스템을 보호하기 위해 타임아웃 값을 더 줄이기도 함
하지만 일부 애플리케이션은 세션을 한 번 연결해 놓고 다음 통신이 시도될 때까지 세션이 끊기지 않도록 세션 타임아웃 값을 길게 설정하기도 함
이런 종류의 애플리케이션이 통신할 때, 세션 장비의 세션 타임아웃 값이 애플리케이션의 세션 타임아웃 값보다 짧으면 통신에 문제가 생김
세션 장비의 세션 테이블에 세션이 없는 상황에서 SYN이 아닌 ACK로 표시된 패킷이 들어오면 세션 장비에서는 비정상 통신으로 판단해 패킷을 차단하고 그런 종류의 패킷을 통과시키는 옵션을 설정해 패킷을 강제로 통과시키더라도 반대 방향으로 데이터가 들어오면 정책에 막힐 수 있음

6.4.1.1 세션 장비 운영자 입장

세션 만료 시간 증가
- 세션 장비의 운영자가 애플리케이션에 맞게 세션 만료 시간을 늘리는 방법이 있음
- 이 경우, 애플리케이션의 세션 유지 시간보다 방화벽 세션 유지 시간이 길어야 함
세션 시간을 둔 채로 중간 패킷을 수용할 수 있도록 방화벽 설정(세션 장비 중 방화벽에 해당)
- 세션 테이블에 정보가 없는 ACK 패킷이 방화벽에 들어오면 방화벽은 패킷을 차단하지만 방화벽 옵션을 조정해 세션 테이블에 정보가 없는 ACK 패킷이 들어오더라도 세션을 새로 만들어 통과시킬 수 있는 옵션이 있음
- 하지만 이런 해결책은 전체적인 보안이 취약해지는 기능임
세션 장비에서 세션 타임아웃 시 양 단말에 세션 종료 통보
- 양 종단 장비의 세션 정보와 중간 세션 장비의 세션 정보가 일치하지 않아 발생하는 문제를 해결하기 위해 사용하는 기능

6.4.1.2 개발자 입장

애플리케이션에서 주기적인 패킷 발생 기능 추가
- 애플리케이션과 세션 장비의 세션 타임아웃 시간을 일치시키는 가장 좋은 방법은 애플리케이션에서 패킷을 주기적으로 발생시키는 것
- 세션 상태 정보를 체크하는 더미 패킷(Dummy Packet)을 보내는 기능을 추가하면 패킷이 주기적으로 발생해 중간 방화벽에서 세션 타임아웃이 발생하기 전에 세션을 유지할 수 있음

6.4.2 비대칭 경로 문제

네트워크의 안정성을 높이기 위해 네트워크 회선과 장비를 이중화
이때 패킷이 지나가는 경로가 2개 이상이므로 인바운드 패킷과 아웃바운드 패킷의 경로가 같거나 다를 수 있음
인바운드 패킷과 아웃바운드 패킷이 같은 장비를 통과하는 것을 대칭 경로(Symmetric Path)
다른 장비를 통과하는 것을 비대칭 경로(Asymmetric Path)라고 함
비대칭 경로를 방화벽에서 처리할 수 있는 첫 번째 방법은 세션 테이블 동기화
- 세션 테이블을 동기화하면 두 개 경로상의 두 장비가 하나의 장비처럼 동작하므로 비대칭 경로에서도 정상적으로 동작
- 이 기능은 응답시간이 비교적 긴 인터넷 게이트웨이로 방화벽이 사용될 때 유용하게 사용할 수 있음
두 번째 방법은 비대칭 경로가 생길 경우, 세션 장비에서 다양한 방법으로 이를 보정
- 인바운드 패킷이 통과하지 않았는데 아웃바운드 패킷이 장비로 들어온 경우, 인바운드 패킷이 통과한 다른 세션 장비 쪽으로 패킷을 보내 경로를 보정
- 강제로 대칭 경로를 만들어 주므로 문제 해결 가능

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

현대 프로토콜은 하나의 통신을 위해 한 개의 세션만 사용하는 경우가 대부분이지만 특별한 목적으로 두 개 이상의 세션을 만드는 경우가 있음
프로토콜은 데이터 프로토콜과 컨트롤 프로토콜로 구분할 수 있음
데이터 프로토콜은 데이터를 실어 나르고 컨트롤 프로토콜은 데이터가 잘 전송되도록 세션을 제어
현대 프로토콜들은 대부분 컨트롤 프로토콜 기능과 데이터 프로토콜 기능을 하나의 프로토콜에서 헤더나 별도 메시지로 해결하지만 특별한 목적이 있거나 오래된 프로토콜은 두 개의 프로토콜이 분리된 경우가 있음
가장 대표적인 프로토콜이 FTP(File Tranfer Protocol)

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

종단 장비에서 패킷이 시작되어 중간 네트워크 장비에서 이 패킷을 처리하는 과정 외에도 IP 네트워크에는 통신을 도와주고 사용자를 편리하게 해주는 다양한 서비스와 프로토콜이 있음
사용자가 IP 설정을 하지 않더라도 IP 주소를 자동으로 할당해 주는 DHCP(Dynamic Host Configuration Protocol), 사용자가 복잡한 목적지 IP를 기억하지 않고 쉬운 도메인 이름을 사용하도록 도메인 이름과 IP 주소를 매핑해주는 DNS(Domain Name Service), 사용자가 가장 가까운 지역의 데이터 센터에 접속해 신속한 서비스를 받게 해주는 GSLB(Global Service Load Balancing), 하나의 IP를 사용해 여러 단말 장비를 포함하는 네트워크를 손쉽게 구축하도록 도와주는 NAT

7.1 NAT/PAT

라우터나 L3 스위치와 같은 L3 장비에서도 쓰이고 특히 방화벽과 로드 밸런서와 같이 세션을 다루는 L4 이상의 장비에서는 매우 빈번히 사용되는 기술
NAT는 이름 그대로 네트워크 주소를 변환하는 기술
NAT는 기본적으로 하나의 네트워크 주소에 다른 하나의 네트워크 주소로 변환하는 1:1 변환이 기본이지만 IP 주소가 고갈되는 문제를 해결하기 위해 1:1 변환이 아닌 여러 개의 IP를 하나의 IP로 변환하기도 함
여러 개의 IP를 하나의 IP로 변환하는 기술도 NAT 기술 중 하나이고 NAT로 통칭하여 불리기도 하지만 실제 공식 용어는 NAPT(Network Address Port Translation)임
"NAT는 IP 주소를 다른 IP 주소로 변환해 라우팅을 원활히 해주는 기술"이라고 인터넷 표준 문서에서 정의
사설 IP에서 공인 IP로 전환하는 것뿐만 아니라 공인 IP에서 사설 IP로 주소를 전환할 수 있고 사설 IP에서 또 다른 사설 IP나 공인 IP에서 또 다른 공인 IP로의 전환도 NAT로 정의될 수 있음
개념을 좀 더 확장하면 IPv4 주소를 IPv6 주소로 변환하거나 그 반대로 IP 주소를 변환하는 기술인 AFT(Address Family Translation)도 NAT 기술의 일종

7.1.1 NAT/PAT의 용도와 필요성

첫째, IPv4 주소 고갈 문제의 솔루션으로 NAT가 사용
둘째, 보안을 강화하는 데 NAT 기술을 사용
- 외부와 통신할 때 내부 IP를 다른 IP로 변환해 통신하면 외부에 사내 IP 주소 체계를 숨길 수 있음
- NAT는 주소 변환 후 역변환이 정상적으로 수행되어야만 통신이 가능
- 이 성질을 이용해 복잡한 룰 설정 없이 방향성을 통제
- 내부 네트워크에서 외부 네트워크로 나가는 방향 통신은 허용하지만 외부에서 시작해 내부로 들어오는 통신은 바어
셋째, IP 주소 체계가 같은 두 개의 네트워크 간 통신을 가능하게 함
- IP 네트워크에서 서로 통신하려면 식별 가능한 유일한 IP 주소가 있어야 함
- 공인 IP는 인터넷에서 유일한 주소로 IP 주소가 중복되면 안 되지만 사설 IP는 외부와 통신할 때 공인 IP로 변환되어 통신하므로 서로 다른 회사에서 중복해 사용할 수 있음
넷째, 불필요한 설정 변경을 줄일 수 있음
- KISA를 통해 인터넷 독립기관으로 직접 등록하고 소유한 IP 주소를 직접 운영하는 경우가 아니라면 통신사업자나 IDC 쪽에서 IP를 할당받아 사용
- 이 IP들은 자신이 소유한 것이 아니라 임시로 빌려 사용하는 것이므로 회선 사업자를 바꾸거나 IDC를 이전하면 그동안 빌려 써왔던 공인 IP를 더 이상 사용할 수 없고 신규 사업자가 빌려주는 IP로 변경해야 함
- 만약 사용자가 NAT/PAT를 이용해 내부 네트워크를 구성하고 있었다면 서버와 PC의 IP 주소 변경 없이 회선과 IDC 사업자 이전이 가능

7.1.4 SNAT와 DNAT

NAT를 사용해 네트워크 주소를 변환할 때 어떤 IP 주소를 변환하는지에 따라 두 가지로 구분
- SNAT(Source NAT) - 출발지 주소를 변경하는 NAT
- DNAT(Destination NAT) - 도착지 주소를 변경하는 NAT
SNAT와 DNAT는 트래픽이 출발하는 시작 지점을 기준으로 구분
SNAT와 DNAT의 기준은 NAT가 수행되기 이전의 트래픽이 출발하는 시작 지점
즉, 요청 시 SNAT를 해 목적지로 전송하면 해당 트래픽에 대한 응답을 받을 때는 출발지와 목적지가 반대가 되므로 DNAT가 되는데 이떄 트래픽을 요청하는 시작 지점만 고려해 SNAT 설정을 함
NAT 장비를 처음 통과할 때 NAT 테이블이 생성되므로 응답 패킷이 NAT 장비에 들어오면 별도의 NAT 설정이 없더라고 NAT 테이블을 사용해 반대로 패킷을 변환해 줄 수 있음
이 과정을 역 NAT라고 하며 NAT가 정상적으로 수행되려면 역 NAT 과정이 함께 수행되어야 함
SNAT
- SNAT는 사설에서 공인으로 통신할 때 많이 사용
- 공인 IP의 목적지로 서비스를 요청할 때 출발지에서는 사설 IP를 별도의 공인 IP로 NAT 해 서비스를 요청
- 다른 경우는 보안상 SNAT을 사용할 때
- 회사에서 다른 대외사와 통신 시 내부 IP 주소가 아니라 별도의 다른 IP로 전환해 전송함으로써 대외에 내부의 실제 IP 주소를 숨길 수 있음
- 로드 밸런서의 구성에 따라 SNAT를 사용하기도 함
- 출발지와 목적지 서버가 동일한 대역일 때는 로드 밸런서 구성에 따라 트래픽이 로드 밸런서를 거치지 않고 응답할 수 있어 SNAT를 통해 응답 트래픽이 로드 밸런서를 거치게 할 수 있음
DNAT
- DNAT는 로드 밸런서에서 많이 사용
- 사용자는 서비스 요청을 위해 로드 밸런서에 설정된 서비스 VIP(Virtual IP)로 서비스를 요청하고 로드 밸런서에서는 서비스 VIP를 로드 밸런싱될 서버의 실제 IP로 DNAT해 내보냄
- 사내가 아닌 대외망과의 네트워크 구성에도 DNAT를 사용
- 사내가 아닌 대외망과의 연동에서는 IP가 중복될 수 있음
- IP가 중복되지 않더라고 IP 주소가 제각각이므로 신규 대외사와의 연동마다 라우팅을 개별적으로 설정
- 이 경우, 대외망에 NAT 장비를 이용해 대외사의 IP를 특정 IP 대역으로 NAT 함

7.1.5 동적 NAT와 정적 NAT

출발지와 목적지의 IP를 미리 매핑해 고정해 놓은 NAT를 정적 NAT라고 함
반대로 출발지나 목적지 어느 경우든 사전에 정해지지 않고 NAT를 수행할 때 IP를 동적으로 변경하는 것을 동적 NAT라고 함
동적 NAT는 출발지와 목적지가 모두 정의된 것이 아니라 다수의 IP 풀에서 정해지므로 최소한 출발지나 목적지 중 한 곳이 다수의 IP로 구성된 IP 풀이나 레인지(Range)로 설정되어 있음
NAT가 필요할 때 IP 풀에서 어떤 IP로 매핑될 것인지 판단해 NAT를 수행하는 시점에 NAT 테이블을 만들어 관리
NAT 테이블은 설정된 시간 동안 유지되고 일정 시간 동안 통신이 없으면 다시 사라지므로(NAT 테이블 타임아웃) 동적 NAT의 설정은 서비스 흐름을 고려해 적용해야 함
정적 NAT는 출발지와 목적지 매핑 관계가 특정 IP로 사전에 정의된 것이므로 1:1 NAT라고 부르기도 함
실제 IP 매핑도 A라는 IP와 B라는 IP가 항상 고정되어 매핑된 상태이므로 서비스 방향에 따라 고려할 필요가 없음

7.2 DNS

네트워크 프로토콜은 크게 두 가지로 나눌 수 있음
실제로 데이터를 실어 나르는 데이터 프로토콜과 이 데이터 프로토콜이 잘 동작하도록 도와주는 컨트롤 프로토콜
컨트롤 프로토콜은 통신에 직접 관여하지 않지만 처음 통신 관계를 맺거나 유지하는 데 큰 역할을 함
TCP/IP 프로토콜 체계를 유지하기 위한 주요 컨트롤 프로토콜에는 ARP, ICMP, DNS가 있음
이중 DNS는 도메인 주소를 IP 주소로 변환하는 역할을 함
MSA(Micro Service Architecture) 기반의 서비스 설계가 많아지면서 다수의 API를 이용하다 보니 사용자의 호출뿐만 아니라 서비스 간 API 호출이나 인터페이스가 많아져 DNS의 역할이 더 중요해짐

7.2.1 DNS 소개

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

7.2.2 DNS 구조와 명명 규칙

도메인은 계층 구조여서 수많은 인터넷 주소 중 원하는 주소를 효율적으로 찾아갈 수 있음
역트리 구조로 최상위 루트부터 Top-Level 도메인, Second-Level 도메인, Third-Level 도메인과 같이 하위 레벨로 원하는 주소를 단계적으로 찾아감
우리가 도메인 주소를 사용할 때는 각 계층의 경계를 "."으로 표시하고 뒤에서 앞으로 해석함

7.2.2.1 Root Domain

도메인을 구성하는 최상위 영역
루트 DNS는 전 세계에 13개가 있고 DNS 서버를 설치하면 루트 DNS의 IP 주소를 기록한 힌트 파일을 가지고 있어 루트 DNS 관련 정보를 별도로 설정할 필요가 없음

7.2.2.2 Top-Level Domain(TLD)

최상위 도메인인 TLD는 IANA(Internet Assigned Numbers Authority)에서 구분한 6가지 유형으로 구분
- Generic TLD(gTLD)
  - gTLD는 특별한 제한 없이 일반적으로 사용되는 최상위 도메인이며 세 글자 이상으로 구성
  - 초기 7개의 gTLD(.com, .edu, .gov, .int, .mil, .net, .org)로 시작했으며 필요에 의해 새로운 gTLD가 지속적으로 만들어지고 있음
- Country Code TLD(ccTLD)
  - ccTLD는 국가 최상위 도메인으로 ISO 3166 표준에 의해 규정된 두 글자의 국가 코드를 사용
  - 우리나라는 'kr'을 사용
- Sponsored(sTLD)
  - sTLD는 특정 목적을 위한 스폰서를 두고 있는 최상위 도메인
  - 스폰서는 특정 민족공동체, 전문가 집단, 지리적 위치 등이 속할 수 있음
  - sTLD의 종류에는 '.aero', '.asia', '.edu', '.museum'등이 있음
- Infrastructure
  - 운용상 중요한 인프라 식별자 공간을 지원하기 위해 전용으로 사용되는 최상위 도메인
  - Infrastructure에 속하는 TLD는 '.arpa'
- Generic-restricted(grTLD)
  - grTLD는 특정 기준을 충족하는 사람이나 단체가 사용할 수 있는 최상위 도메인
  - grTLD의 종류에는 '.biz', '.name', '.pro'가 있음
- Test(tTLD)
  - tTLD는 IDN(Internationalized Domain Names) 개발 프로세스에서 테스트 목적으로 사용하는 최상위 도메인
  - tTLD의 종류에는 '.test'가 있음

7.2.3 DNS 동작 방식

도메인을 IP 주소로 변환하려면 DNS 서버에 도메인 쿼리하는 과정을 거쳐야 함
하지만 DNS 서버 없이 로컬에 도메인과 IP 주소를 직접 설정해 사용할 수도 있음
로컬에서 도메인과 IP 주소를 관리하는 파일을 hosts 파일이라고 함
hosts 파일에 도메인과 IP 주소를 설정해 두면 해당 도메인 리스트는 항상 DNS 캐시에 저장됨
도메인을 쿼리하면 DNS 서버에 쿼리를 하기 전 로컬에 있는 DNS 캐시 정보를 먼저 확인 (캐시를 통한 성능 향상)
이런 DNS 캐시 정보에는 기존 DNS 조회를 통해 확인한 동적 DNS 캐시와 함께 hosts 파일에 저장되어 있는 정적 DNS 캐시가 함께 저장되어 있음
DNS 캐시 정보에 필요한 도메인 정보가 없으면 DNS 서버로 쿼리를 수행하고 DNS 서버로부터 응답을 받으면 그 결과를 캐시에 먼저 저장
전에 쿼리를 한 번 수행한 DNS 정보는 캐시부터 조회하므로 DNS 서버에 별도로 쿼리하지 않고 캐시 정보를 사용
전 세계 도메인 정보를 DNS 서버 하나에 저장할 수는 없음
데이터 자체도 방대하지만 인터넷에 엄청나게 많은 사용자가 등록하고 삭제하는 도메인 리스트를 실시간으로 업데이트할 수 없기 때문
그래서 DNS는 분산된 데이터베이스로 서로 도와주도록 설계되었는데 자신이 가진 도메인 정보가 아니면 다른 DNS에 질의해 결과를 받을 수 있음
DNS 기능을 서버에 올리면 DNS 서버는 기본적으로 루트 DNS 관련 정보를 가지고 있음
클라이언트의 쿼리가 자신에게 없는 정보라면 루트 DNS에 쿼리하고 루트 DNS에서는 쿼리한 도메인의 TLD 값을 확인해 해당 TLD 값을 관리하는 DNS가 어디인지 응답
클라이언트에서 처음 질의를 받은 DNS가 중심이 되어 책임지고 루트 DNS부터 상위 DNS에 차근차근 쿼리를 보내 결괏값을 알아낸 후 최종 결괏값만 클라이언트에 응답
클라이언트는 한 번의 쿼리를 보내지만 이 요청을 받은 DNS 서버는 여러 단계로 쿼리를 상위 DNS 서버에 보내 정보를 획득
호스트가 DNS 서버에 질의했던 방식을 재귀적 쿼리(Recursive Query)라고 하고 DNS 서버가 루트 NS와 TLS NS, zigspace NS에 질의한 방식을 반복적 쿼리(Iterative Query)라고 함

재귀적 쿼리와 반복적 쿼리

재귀적 쿼리는 쿼리를 보낸 클라이언트에 서버가 최종 결괏값을 반환하는 서버 중심 쿼리

반복적 쿼리는 최종값을 받을 때까지 클라이언트에서 쿼리를 계속 진행하는 방식

7.2.4 마스터와 슬레이브

DNS 서버는 마스터 서버와 슬레이브 서버로 나눌 수 있음
마스터 서버가 우선순위가 더 높지 않고 두 서버 모두 도메인 쿼리에 응답
마스터와 슬레이브는 도메인에 대한 존 파일을 직접 관리하는지 여부로 구분
마스터 서버는 존 파일을 직접 생성해 도메인 관련 정보를 관리하고 슬레이브 서버는 마스터에 만들어진 존 파일을 복제
이 과정을 '영역 전송(Zone Transfer)'이라고 함
DNS 마스터 서버와 슬레이브 서버는 이중화에서 일반적으로 사용하는 액티브-스탠바이나 액티브-액티브 형태로 구성하지 않음
보통 이중화 방식은 액티브 장비의 문제가 발생하더라도 또 다른 액티브나 스탠바이 장비가 그대로 서비스
반면 DNS 서버는 마스터 서버에 문제가 발생하고 일정 시간이 지나면 슬레이브 서버도 도메인에 대한 질의에 정상적으로 응답할 수 없음
이 시간을 만료 시간이라고 함
만료 시간 안에 슬레이브 서버가 마스터 서버에서 존 정보를 받아오지 못하면 슬레이브의 존 정보는 사용할 수 없게 됨

7.2.5 DNS 주요 레코드

도메인에는 다양한 내용을 매핑할 수 있는 레코드가 있음

7.2.5.1 A(IPv4) 레코드

A 레코드는 기본 레코드로 도메인 주소를 IP 주소로 변환하는 레코드
사용자가 DNS에 질의한 도메인 주소를 A 레코드에 설정된 IP 주소로 응답
하나의 A 레코드에는 한 개의 도메인 주소와 한 개의 IP 주소가 1:1로 매핑되는데 동일한 도메인을 가진 A 레코드를 여러 개 만들어 서로 다른 IP 주소와 매핑할 수 있음
반대로 다수의 도메인에 동일한 IP를 매핑한 A 레코드를 만들 수 있음

7.2.5.2 AAAA(IPv6) 레코드

A 레코드가 IPv4 주소 체계에서 사용되는 레코드라면 AAAA 레코드는 IPv6 주소 체계에서 사용되는 레코드
역할은 A 레코드와 같음

7.2.5.3 CNAME(Canonical Name) 레코드

CNAME 레코드는 별칭 이름을 사용하게 해주는 레코드
레코드값에 IP 주소를 매핑하는 A 레코드와 달리 CMAME 레코드는 도메인 주소를 매핑
대표적인 예로 'www'가 있음

7.2.5.4 SOA(Start of Authority) 레코드

도메인 영역에 대한 권한을 나타내는 레코드
현재 네임 서버가 이 도메인 영역에 대한 관리 주체임을 의미하므로 해당 도메인에 대해서는 다른 네임 서버에 질의하지 않고 직접 응답
도메인 영역 선언 시 SOA 레코드는 필수 항목이므로 반드시 만들어야 함

7.2.5.5 NS(Name Server) 레코드

도메인에 대한 권한이 있는 네임 서버 정보를 설정하는 레코드
NS 레코드의 경우, 권한이 있는 네임 서버 정보를 해당 도메인에 설정하는 역할 외에 하위 도메인에 대한 권한을 다른 네임 서버로 위임(Delegate)하는 역할로도 많이 사용

7.2.5.6 MX(Mail eXchange) 레코드

메일 서버를 구성할 때 사용되는 레코드

7.2.5.7 PTR(Pointer) 레코드

A 레코드는 도메인 주소에 대한 질의를 IP로 응답하기 위한 레코드이고 PTR 레코드는 그와 반대로 IP 주소에 대한 질의를 도메인 주소로 응답하기 위한 레코드
A 레코드가 정방향 조회용 레코드라면 PTR 레코드는 역방향 조회용 레코드

7.2.5.8 TXT(TeXT) 레코드

도메인에 대한 설명과같이 간단한 텍스트를 입력할 수 있는 레코드

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

7.2.6.1 도메인 위임

도메인은 그 도메인에 대한 정보를 관리할 수 있는 네임 서버를 지정하지만 도메인 내의 모든 레코드를 그 네임 서버가 직접 관리하지 않고 일부 영역에 대해서는 다른 곳에서 레코드를 관리하도록 위임하기도 함
자신이 가진 도메인 관리 권한을 다른 곳으로 일부 위임해 위임한 곳에서 세부 레코드를 관리하도록 하는 것
CDN을 이용하거나 GSLB를 사용하는 것이 대표적
도메인 위임 기능을 쓰면 특정 영역을 다른 네임 서버에 관리할 수 있는 권한을 위임
특정 영역에 대한 관리 주체를 분리하는 용도로 사용할 수 있어 계열사에서 특정 도메인을 분리하거나 GSLB 등 다양한 용도로 사용

7.2.6.2 TTL

도메인의 TTL 값은 DNS에 질의해 응답받은 결괏값을 캐시에서 유지하는 시간을 뜻함
로컬 캐시에 저장된 도메인 정보를 무작정 계속 갖고 있는 것이 아니라 DNS에 설정된 TTL 값에 따라 그 시간만 로컬 캐시에 저장
DNS 서버에서 TTL 값을 늘려 캐시를 많이 이용하면 DNS 재귀적 쿼리로 인한 응답 시간을 많이 줄일 수 있고 결과적으로 전체적인 네트워크 응답 시간이 단축
하지만 DNS에서 해당 도메인 관련 정보가 변경되었을 때, TTL 값이 크면 새로 변경된 값으로 DNS 정보 갱신이 그만큼 지연되는 단점이 발생
반대로 TTL 값이 너무 작으면 DNS의 정보 갱신이 빨라지므로 DNS 쿼리량이 늘어나 DNS 서버 부하가 증가

7.2.6.3 화이트 도메인

KISA에서는 불법적인 방법으로 발송되는 스팸메일 차단활동을 하고 있음
이를 위해 정상적인 도메인을 인증, 관리하는 제도가 '화이트 도메인'
반대로 불법적인 스팸메일을 발송하는 사이트를 실시간 블랙리스트 정보로 관리해 메일 발송을 제한
실시간 블랙리스트를 RBL(Realtime Blackhole List, Realtime Blocking List)라고 함

7.2.6.4 한글 도메인

도메인 주소는 영문뿐만 아니라 "http://대한민국.한국"처럼 한글로 주소를 만들 수 있음
사용자가 도메인을 한글로 등록하고 사용하기 위해 DNS에서는 해당 한글을 "퓨니코드"로 변경하고 이 퓨니코드로 DNS에 도메인을 생성해야 함

7.2.8 DNS 설정(Linux)

bind 패키지 설치

$ yum install -y bind

bind 버전 확인

$ /usr/sbin/named -v

초기 설정은 bind가 설치된 로컬 서버에서만 도메인 질의를 할 수 있게 되어 있음
DNS를 위한 53번 포트에 대한 Listen과 질의 허용(Allow-Query)이 로컬 호스트(localhost/127.0.0.1)로 설정되어 있기 때문
로컬뿐만 아니라 외부에서도 도메인 질의를 하려면 다음과 같이 네임 서버 설정 파일(named.conf)의 option 안에 'listen-on port 53','listen-on-v6 port 53', 'allow-query'항목 값을 any로 수정

/etc/named.conf

options {
        listen-on port 53 { any; };    // 기본값 127.0.0.1;
        listen-on-v6 port 53 { any; }; // 기본값 ::1
directory       "/var/named";
... 생략 ...
        allow-query       { any;};    // 기본값 localhost
... 생략 ...

bind에서 관리할 도메인 영역을 추가하기 위해 도메인 영역을 관리하는 설정 파일(named.rfc1912.zones)에 신규 도메인 영역(zigispace.kr)을 추가

/etc/named.rfc1912.zones

zone "zigispace.kr" IN {
        type master;
        file "zigispace.kr.zone";
        allow-update { none; };
};

도메인 영역을 동기화할 슬레이브 서버는 따로 없으니 allow-update는 'none'으로 설정
도메인 영역을 지정한 후에는 해당 도메인에 대한 존(Zone) 파일을 만들어 도메인의 속성과 레코드를 정의

$ 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

만들어진 존 파일은 bind에서 사용할 수 있도록 권한 수정

$ chown root:named /var/named/zigispace.kr.zone

bind 서비스 데몬 실행

$ systemctl start named.service

7.3 GSLB

DNS 로드밸런싱
- DNS에서 동일한 레코드 이름으로 서로 다른 IP 주소를 동시에 설정할 수 있음
- 도메인 질의에 따라 응답받는 IP 주소를 나누어 로드밸런싱 가능
DNS는 설정된 서비스 상태의 정상 여부를 확인하지 않고 도메인에 대한 질의에 대해 설정된 값을 무조건 응답
특정 서비스에 문제가 있을 때 DNS 서버는 이것을 감지하지 못해 사용자의 도메인 질의 요청에 비정상 상태인 서비스 IP 주소를 응답한 경우, 사용자는 해당 서비스에 접근할 수 없음
즉 DNS 서버는 서비스 가용성 향상 방법으로는 부적합
GSLB는 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에 대해 질의
GLSB는 web.zigispace.net에 대한 IP 주솟값 중 현재 설정된 분산 방식에 따라 서울 또는 부산 데이터 센터의 IP 주솟값을 DNS에 응답
서울과 부산 데이터 센터로 헬스 체크해 정상적인 값만 응답
GSLB에서 결괏값을 응답받은 LDNS는 사용자에게 web.zigispace.net이 1.1.1.1로 서비스하고 있다고 최종 응답

GSLB는 zigispace.net이라는 FQDN에 대한 IP 주소 정보를 단순히 갖고 있다가 응답해 주는 것이 아니라 헬스 체크를 통해 해당 IP가 정상적인 서비스가 가능한 상태인지 확인
정리하면 GSLB는 앞의 동작 방식처럼 일반 DNS를 사용하는 것과 거의 동일하게 동작
다만 GSLB에서 서비스 IP 정보에 대한 헬스 체크와 사전에 지정한 다양한 분산 방법을 이용한 부하 분산이 일반 DNS와 큰 차이점이라고 볼 수 있음

7.3.2 GSLB 구성 방식

GSLB를 사용한 도메인 설정 방법은 두 가지가 있음
도메인 자체를 GSLB로 사용
- 도메인 자체를 GSLB로 사용하면 해당 도메인에 속하는 모든 레코드 설정을 GSLB 장비에서 관리
- 즉, 도메인에 대한 모든 레코드를 GSLB에서 설정
- 도메인 자체를 GSLB로 사용하는 것은 도메인에 대한 네임 서버를 GSLB로 지정하고 GSLB에서 도메인에 대한 모든 레코드를 등록해 처리하는 방식
- 즉, GSLB 자체가 도메인의 네임 서버 역할을 하는 경우
도메인 내의 특정 레코드만 GSLB로 사용
- DNS에서 도메인 설정 시 GSLB를 사용하려는 레코드에 대해서만 GSLB로 처리하도록 설정
- 회사 대표 도메인에 속한 레코드 중 GSLB 적용이 불필요한 경우가 많아 도메인 내의 특정 레코드에 대해서만 GSLB로 처리를 이관하는 방식을 사용
- 특정 레코드에 대해서만 GSLB로 처리를 이관하는 방법은 두 가지가 있음
  - 별칭(Alias) 사용(CNAME 레코드 사용)
    - 일반적으로 외부 CDN을 사용하거나 회사 내부에 GSLB를 사용해야 할 도메인이 많은 경우 한꺼번에 관리하기 위해 사용
    - DNS 서버에 CNAME 레코드로 CDN과 같은 외부 GSLB를 지정하면 CNAME 레코드의 값으로 등록된 FQDN을 GSLB로 재질의해 서버를 찾아가게 됨
    - 즉, CNAME 값으로 등록되는 FQDN이 GSLB가 네임 서버로 등록된 도메인을 사용해 GSLB로 재질의하게 만드는 것
  - 위임(Delegation) 사용(NS 레코드 사용)
    - 실제 도메인과 동일한 도메인 레코드를 사용하며 도메인 전체를 위임하는 것이 대표적
    - DNS에서 특정 FQDN에 대한 설정을 NS 레코드로 설정하면 해당 FQDN에 대한 값을 NS 레코드의 값으로 설정된 네임 서버로 재질의
    - 이때 NS 레코드에 지정된 네임 서버가 GSLB
    - 이렇게 NS 레코드를 이용한 위임으로 재질의하는 경우, 최초 요청한 FQDN을 그대로 재질의하므로 GSLB에서 관리되는 도메인은 사용자가 최초 호출하는 동일한 FQDN이 됨
정리하면 별칭을 이용해 GSLB를 사용하는 경우, CDN처럼 GSLB를 운영해 주는 외부 사업자가 있거나 GSLB를 사용해야 하는 도메인이 매우 많은 경우, 별도의 GSLB를 운영하기 위해 사용
위임의 경우에는 DNS와 같은 도메인으로 GSLB를 운영하면서 계층적으로 GSLB를 이용한 FQDN을 관리할 때 사용
많은 환경에서 다양한 서비스가 혼재되어 있으므로 NS와 CNAME 방식을 혼용하여 사용하기도 함

7.3.3 GSLB 분산 방식

GSLB를 이용해 서비스를 분산하면 다음과 같은 주요 목적을 달성할 수 있음
- 서비스 제공의 가능 여부를 체크해 트래픽 분산
- 지리적으로 멀리 떨어진 다른 데이터 센터에 트래픽 분산
- 지역적으로 가까운 서비스에 접속해 더 빠른 서비스 제공이 가능하도록 분산
서비스 헬스 체크를 통해 서비스를 안정적으로 제공하는 것 외에 서로 다른 사이트로 서비스를 분산시키는 것이 GSLB의 중요한 역할
이를 위해 GSLB는 라운드 로빈(Round Robin)이나 최소 접속(Least Connection), 해싱(Hashing) 방식 외에 추가적인 분산 방식을 제공
대부분 다음 두 가지 헬스 체크 모니터링 요소를 지원
- 서비스 응답 시간/지연(RTT/Latency)
  - 서비스 요청에 대한 응답이 얼마나 빠른지 또는 지연이 얼마나 없는지를 확인하고 이것을 이용해 서비스를 분산 처리
- IP에 대한 지리 정보
  - 서비스 제공이 가능한 각 사이트의 IP 주소에 대한 Geo 값을 확인해 가까운 사이트로 서비스 분산을 처리
위의 두 가지 요소에 따른 분산 방법은 다르겠지만 기본적으로 추구하는 목표는 다음과 같음
서비스가 가능한 사이트로 트래픽을 분산하는 것은 물론 더 신속히 서비스를 제공할 수 있는 사이트로 접속할 수 있도록 유도하는 것이 궁극적인 목표

7.4 DHCP

정적 할당: 수동으로 IP와 네트워크 정보를 직접 설정하는 것
동적 할당: 자동으로 설정하는 것
IP를 동적으로 할당하는 데 사용되는 프로토콜이 DHCP
DHCP를 사용하면 사용자가 직접 입력해야 하는 IP 주소, 서브넷 마스크, 게이트웨이, DNS 정보를 자동으로 할당받아 사용할 수 있음
별도의 IP 설정 작업이 필요 없어 사용자와 관리자 모두 편리하게 네트워크에 접속할 수 있고 사용하지 않는 IP 정보는 회수되어 사용하는 경우에만 재할당되어 사용자 이동이 많고 한정된 IP 주소를 가진 경우 유용하게 사용될 수 있음
또한, IP가 자동으로 관리되므로 사용자가 직접 입력하면서 발생할 수 있는 설정 정보오류나 중복 IP 할당과 같은 문제를 예방할 수 있음

7.4.1 DHCP 프로토콜

DHCP는 BOOTP라는 프로토콜을 기반으로 작동
DHCP는 BOOTP와 유사하게 동작하지만 BOOTP에서 지원되지 않는 몇 가지 기능이 추가된 확장 프로토콜
DHCP와 BOOTP 프로토콜 사이에는 호환성이 있어 BOOTP와 DHCP에서 사용되는 서비스 포트가 같고 BOOTP 클라이언트가 DHCP 서버를 사용하거나 DHCP 클라이언트가 BOOTP 서버를 사용해 정보를 수신할 수 있음
DHCP는 서버와 클라이언트로 동작하며 클라이언트의 서비스 포트는 68(bootpc), 서버의 서비스 포트는 67(bootps)

7.4.2 DHCP 동작 방식

DHCP를 이용해 IP를 자동으로 할당받기 위해 DHCP 클라이언트는 DHCP 서버를 찾기 위한 메시지를 전송하는데 이 메시지를 DHCP Discover 메시지라고 함
IP를 할당받는 과정이므로 패킷을 정상적으로 주고받을 수 없어 TCP가 아닌 UDP를 사용
클라이언트에 IP를 할당할 때는 단순히 IP 주소뿐만 아니라 서브넷, 게이트웨이, DNS 정보와 IP 주소 임대 시간, DHCP 서버 자신의 IP 정보를 포함한 메시지를 DHCP 클라이언트에 전송
이 메시지를 DHCP Offer 메시지라고 하며 서버가 클라이언트에 IP 주소 사용을 제한하는 단계
DHCP 클라이언트는 DHCP 서버로부터 제안받은 IP 정보를 사용하기 위해 DHCP Request 메시지를 DHCP 서버에 전송
DHCP 서버를 찾기 위한 Discover 메시지를 보낼 때는 현재 DHCP 서버가 어느 서버인지 알 수 없으므로 브로드캐스트로 전송하고 DHCP Request 메시지를 보낼 때도 유니캐스트가 아닌 브로드캐스트로 전송
마지막으로 DHCP 서버는 DHCP Request를 보낸 클라이언트에 최종 확인을 위한 응답 메시지 패킷을 보내는데 이것을 DHCP Acknowledgement 메시지라고 하며 내용은 DHCP Offer의 내용과 동일
DHCP를 통해 IP를 할당할 때는 IP 임대 시간이 있음
- DHCP 서버는 클라이언트에 할당할 IP 정보와 함께 임대 시간을 지정해 전달
- 임대 시간이 만료되면 클라이언트에 할당된 IP를 다시 IP Pool로 회수
- 만약 클라이언트가 IP를 사용하는 도중 이렇게 임대 시간이 모두 지나면 클라이언트가 사용하던 IP는 다시 수거되고 클라이언트는 다시 처음부터 DHCP Discover부터 시작해 IP를 재할당받아야 함
- 사용하던 IP 주소가 다른 클라이언트에 할당되면서 다른 IP가 할당될 수도 있음
- 실제 동작 방식은 이처럼 매번 할당받은 IP 주소를 반환하고 다시 새로운 할당을 요청하는 과정을 반복하지는 않음
- 현재 클라이언트가 IP를 사용 중인 경우, 갱신 과정을 거쳐 사용 중인 동안 IP 주소가 IP 풀에서 다시 반환되지 않고 계속 사용 가능

7.4.3 DHCP 서버 구성

DHCP 서버를 구성할 때는 클라이언트에 할당하게 될 IP 주소 풀을 포함해 다양한 속성과 정보를 설정할 수 있음
- IP 주소 풀(IP 범위)
  - 클라이언트에 할당할 IP 주소 범위
- 예외 IP 주소 풀(예외 IP 범위)
  - 클라이언트에 할당할 IP 주소로 선언된 범위 중 예외적으로 할당하지 않을 대역
- 임대 시간
  - 클라이언트에 할당할 IP 주소의 기본 임대 시간
- 서브넷 마스크
  - 클라이언트에 할당할 IP 주소에 대한 서브넷 마스크 정보
- 게이트웨이(Router)
  - 클라이언트에 할당할 게이트웨이 정보
- DNS
  - 클라이언트에 할당할 DNS 주소

7.4.3.2 리눅스에서 DHCP 서버 구성

dhcp 패키지 설치

$ yum install dhcp

dhcp 서버를 구성하기 위해 dhcp 설정 파일 확인

/etec/dhcp/dhcpd.conf

DHCP Server Configuration file.
  see /usr/share/doc/dhcp*/dhcpd.conf.example
  see dhcpd.conf(5) man page

복사한 샘플 파일이나 man 페이지를 참조해 다음과 같이 설정 파일을 작성

default-lease-time 600; // 기본 임대 시간을 600초로 설정
max-lease-time 7200; // 최대 임대 시간을 7200초로 설정

subnet 10.10.10.0 netmask 255.255.255.0 {
range 10.10.10.10. 10.10.10.250; // 10.10.10.0 네트워크에 10.10.10.10부터 10.10.10.250까지 클라이언트에 IP가 할당

option routers 10.10.10.254; // 디폴트 게이트웨이를 10.10.10.254로 설정
option domain-name-servers 8.8.8.8; // DNS 서버를 8.8.8.8로 설정
}

설정 파일을 작성한 후 dhcp 서비스 데몬을 실행

$ systemctl start dhcpd.service

7.4.4 DHCP 릴레이

여러 네트워크를 가진 환경에서도 DHCP 릴레이 에이전트 기능을 사용하면 DHCP 서버 한 대로 여러 네트워크 대역에서 IP 풀을 관리할 수 있음
DHCP 릴레이 에이전트가 DHCP 클라이언트와 DHCP 서버가 서로 다른 대역에 있는 경우, DHCP 패킷을 중간에서 중계하는 역할을 해주기 때문
즉, 릴레이 에이전트를 이용하면 DHCP 서버를 네트워크마다 구성하지 않고 중앙 DHCP 서버만으로도 여러 네트워크에서 DHCP 환경을 운영할 수 있음

임상규

Junior DevOps Engineer

이전 포스트

IT 엔지니어를 위한 네트워크 입문 - 2주차

다음 포스트

IT 엔지니어를 위한 네트워크 입문 - 3주차

Network

6.3 방화벽

6.4 4계층 장비를 통과할 때의 유의점(세션 관리)

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

6.4.1.1 세션 장비 운영자 입장

6.4.1.2 개발자 입장

6.4.2 비대칭 경로 문제

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

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

7.1 NAT/PAT

7.1.1 NAT/PAT의 용도와 필요성

7.1.4 SNAT와 DNAT

7.1.5 동적 NAT와 정적 NAT

7.2 DNS

7.2.1 DNS 소개

7.2.2 DNS 구조와 명명 규칙

7.2.2.1 Root Domain

7.2.2.2 Top-Level Domain(TLD)

7.2.3 DNS 동작 방식

7.2.4 마스터와 슬레이브

7.2.5 DNS 주요 레코드

7.2.5.1 A(IPv4) 레코드

7.2.5.2 AAAA(IPv6) 레코드

7.2.5.3 CNAME(Canonical Name) 레코드

7.2.5.4 SOA(Start of Authority) 레코드

7.2.5.5 NS(Name Server) 레코드

7.2.5.6 MX(Mail eXchange) 레코드

7.2.5.7 PTR(Pointer) 레코드

7.2.5.8 TXT(TeXT) 레코드

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

7.2.6.1 도메인 위임

7.2.6.2 TTL

7.2.6.3 화이트 도메인

7.2.6.4 한글 도메인

7.2.8 DNS 설정(Linux)

7.3 GSLB

7.3.1 GSLB 동작 방식

7.3.2 GSLB 구성 방식

7.3.3 GSLB 분산 방식

7.4 DHCP

7.4.1 DHCP 프로토콜

7.4.2 DHCP 동작 방식

7.4.3 DHCP 서버 구성

7.4.3.2 리눅스에서 DHCP 서버 구성

7.4.4 DHCP 릴레이

IT 엔지니어를 위한 네트워크 입문 - 2주차

IT 엔지니어를 위한 네트워크 입문 - 4주차

0개의 댓글