CKA 준비과정 - Networking (2) / DNS, Network Namespaces

DNS 기초를 살펴본다

A 서버와 B 서버가 있고 B 서버는 DB 서버라고 가정한다.

이 때, A는 B를 찾을 때 IP 주소가 아닌 호스트명을 입력하여 연결할 수 있도록 할 때, hosts 설정을 통해 진행할 수 있다.

 

hosts 파일에서, 192.168.1.11 ip에 대해 db라고 설정한 뒤, ping db 명령어를 입력하면 자동으로 192.168.1.11 에 연결을 시도하는 것을 알 수 있다.

이러한 연결 방식은 Name Resolution 이라고 한다.

 

이런 주소책 기록 방식은 소규모 네트워크에선 문제가 없지만 역시 대규모 네트워크에서는 일일히 hosts 파일을 통해 도메인을 관리할 수는 없다. 따라서 사용하는 것이 DNS 이다.

 

DNS 서버는 도메인 주소를 가지는 서버이다. 다른 서버들은 DNS 서버에 주소를 질의함으로써 도메인에 대한 IP 주소를 얻어올 수 있다.

 

/etc/resolv.conf 파일에서 DNS 도메인 주소록을 확인 가능하다.

각 서버는 host 값을 호출하였는데 IP주소를 모를 경우, DNS 에 질의하는 방식으로 동작한다. 

DNS 서버에 질의하기 전, 먼저 /etc/hosts 를 통해 로컬 도메인 주소록을 확인한다.

=> 로컬 hosts 파일과 DNS 서버의 값이 다를 경우, hosts 파일의 데이터를 우선하게 된다.

 

도메인 주소의 구조는 다음과 같다.

구글을 예시로 보았으 ㄹ때,

Root : . 온점이 도메인의 시작이다.

.com : top level domain (com, net, edu 등)

google : 도메인 이름

Subdomain : www., maps, 등 기능별로 구분한 그룹화된 서브 도메인

도메인 질의 시 절차를 확인한다.

1. Org DNS : 로컬 DNS, hosts 파일에서 도메인에 매칭되는 ip 주소가 있는지 확인

2. Root DNS 서버 질의

3. .com DNS => google DNS => ~~ DNS : DNS 서버는 세부 DNS 서버를 리턴해주고, 단계적으로 계속해서 질의해가며 IP 주소를 색인한다.

4. 최종적으로 확인한 IP 주소 확인, 최초 질의 요청한 서버에 IP 주소 리턴

5. 로컬 DNS 서버에 해당 값을 캐싱, 이후 동일한 도메인 주소로 접속 시 새로 질의할 필요 없이 바로 접속한다.

 

대표적으로 사용되는 DNS 레코드 타입은 위와 같다.

A : IPv4 주소를 도메인으로 등록

AAAA : IPv6 주소를 도메인으로 등록

CNAME : 도메인을 다른 도메인을 등록

 

일반적으로 DNS Resolution 을 확인할 때 사용하는 명령어는 nslookup 또는 dig 를 사용한다.

이 때 참고할 만한 점은, 두 명령어들은 DNS 서버의 주소를 조회할 뿐 로컬 hosts 파일은 참조하지 않는다.

 

 

Network Namespaces

Docker와 쿠버네티스같은 컨테이너는 네트워크 격리를 구현하기 위해 네트워크 네임스페이스를 사용한다.

각 네임스페이스는 호스트와 분리된 공간을 제공한다. 외부에서는 네임스페이스 내 프로세스들에 대해서 알 수 없다.

 

컨테이너 내에서는 다른 컨테이너의 프로세스를 알 수 없다. 따라서, 컨테이너 내 프로세스는 호스트 내 다른 프로세스와는 격리되어 실행되는 점을 기억하자.

 

컨테이너 노드, 즉 host는 통신에 필요한 eth0 과 같은 인터페이스를 가지고 있다. 또한 OS 에서 라우팅 테이블과 ARP 테이블이 있다. 노드 내 컨테이너들은 namespace로 분리되어 있더라도, 호스트의 인터페이스를 가상으로 공유한다.

따라서 컨테이너는 호스트로부터 공유받은 가상의 통신 인터페이스를 이용하며, 가상 라우팅 테이블과 ARP 테이블을 생성하여 통신하게 된다.

 

네트워크 Namespace를 만들어 구성하는 과정을 확인해보자.

 

ip netns add (이름)

위 명령어를 통해 namespace를 새로 생성한다. ip netns 명령어로 생성된 NS를 확인한다.

 

ip link 명령어로 host의 네트워크 인터페이스를 확인할 수 있다.

 

namespace 내에서 네트워크 인터페이스를 확인하고 싶다면, ip netns exec (이름) 뒤에 명령어를 입력하면 된다.

ip netns exec red ip link => red NS 내 인터페이스 확인

* 위의 이미지를 통해 NS 내에서는 호스트의 인터페이스가 표기되지 않음을 확인할 수 있다.

이와 동일하게 arp 테이블도 확인해볼 수 있다.

 

namespace 내부에서 네트워크 인터페이스와 라우팅, arp 테이블이 없는 것을 확인했다. 따라서 NS는 지금 통신이 불가능한 상태이다. 통신이 가능하게끔 구성을 진행해줘야 한다.

 

아래와 같은 순서대로 진행한다.

1. ip link add veth-red type veth peer name veth-blue : 두 NS 간 통로 생성

2. ip link set veth-red/blue netns red/blue : NS에 네트워크 인터페이스 연결

3. ip -n red/blue addr add (IP주소) dev veth-red/blue : 각 NS의 인터페이스에 IP 주소 할당

4. ip -n red/blue link set veth-red/blue up : 인터페이스 활성화

 

연결이 활성화되면, 두 NS간 통신이 정상적으로 되고 arp 주소도 공유되었음을 확인할 수 있다.

다만, host 에서는 NS 내 arp 테이블의 정보는 없기 때문에 host에서 조회할 경우 추가했던 연결 정보가 표기되지 않는다.

 

 

위와같은 1:1 통신 상황이 아닌, 여러 ns가 통신을 해야 하는 상황이라면 네트워크 정리가 필요해진다. 이 때는 물리 장비인 switch 를 가상으로 생성하여 동일한 역할을 수행하도록 한다.

예시에서는 Linux Bridge 를 사용하여 가상 스위치를 생성한 뒤 각 ns를 연결한다.

 

가상의 스위치를 위와같이 생성하여 ns를 연결한다. 

가상 이더넷 인터페이스를 생성하고 연결하는 것은 동일하지만, ns끼리 연결하는 것이 아닌 가상 스위치에 연결한다.

또한, 가상 스위치는 호스트에서는 네트워크 인터페이스로 동작한다. 따라서 호스트에서 해당 인터페이스에 IP 주소를 추가해주어야 제대로 가상 스위치가 동작하게 된다.

설정 후 활성화하면 ns 간 통신이 가능해졌음을 확인할 수 있다.

 

네임스페이스 내에서 외부 네트워크의 연결이 필요할 때는, 호스트가 외부 네트워크로 나가기 위한 게이트웨이 역할을 해줘야 한다. 따라서 호스트와 가상 스위치 간 라우팅을 설정해주어 통신이 가능하도록 한다.

 

또한, 내부 네트워크에서 외부 연결을 위해서는, 목적지 네트워크가 출발지의 IP를 알아야 한다. 설정하지 않으면 아웃바운드는 가능하지만 인바운드가 불가능하여 통신에 애로사항이 생긴다. 따라서 호스트에서 NAT 를 설정하여 게이트웨이 역할을 하도록 한다.

iptables -t nat -A POSTROUTING -s 192.168.15.0/24 -j MA

위와같이 NAT 세팅 할 수 있다. 이렇게 설정하면, 외부에서는 호스트가 접근을 시도한 것으로 판단하고 인바운드 통신이 가능하게 된다.