Udemy CKA 강의 정리 201: Prerequisite - Network Namespaces

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.

⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.

---

이번 강의에서는 Linux의 네트워크 네임스페이스를 소개합니다. 네트워크 네임스페이스는 Docker와 같은 컨테이너에서 네트워크 격리를 구현하는 데 사용됩니다. 간단한 호스트부터 시작하겠습니다. 이미 알고 있듯이 컨테이너는 네임스페이스를 사용하여 default 호스트와 분리됩니다.

Process Namespace

그렇다면 네임스페이스란 무엇인가요? 호스트가 집이라면 네임스페이스는 각 자녀에게 할당하는 집 안의 방입니다. 이 방은 각 어린이에게 프라이버시를 제공하는 데 도움이 됩니다. 각 어린이는 자신의 방 안에 있는 것만 볼 수 있고 방 밖에서 일어나는 일은 볼 수 없습니다. 그 방만 생각한다면, 그들은 집에 사는 유일한 사람입니다. 그러나 부모는 집안의 모든 방과 집안의 다른 영역을 볼 수 있습니다. 원하는 경우 집안의 두 방을 연결할 수 있습니다. 컨테이너를 생성할 때 컨테이너가 격리되어 있는지 확인하고 호스트의 다른 프로세스나 다른 컨테이너를 볼 수 없도록 해야 합니다. 그래서 네임스페이스를 사용하여 호스트에 특별한 공간을 만듭니다. 컨테이너 안에서는 컨테이너는 자신이 실행하는 프로세스만 보고 자체 호스트에 있다고 생각합니다. 그러나 default 호스트는 컨테이너 내부에서 실행되는 프로세스를 포함하여 모든 프로세스를 볼 수 있습니다.

이것은 컨테이너 내에서 프로세스를 조회할 때 볼 수 있습니다. 프로세스 ID가 1인 단일 프로세스가 표시됩니다. default 호스트에서 동일한 프로세스를 루트 사용자로 나열하면 컨테이너 내부에서 실행 중인 프로세스와 함께 이번에는 다른 프로세스 ID를 사용하여 다른 모든 프로세스가 표시됩니다. 컨테이너 내부와 외부에서 서로 다른 프로세스 ID로 실행되는 동일한 프로세스입니다. 네임스페이스가 작동하는 방식입니다.

Network Namespace

네트워킹과 관련하여 호스트에는 로컬 영역 네트워크에 연결하는 자체 인터페이스가 있습니다. 호스트에는 나머지 네트워크에 대한 정보가 포함된 자체 라우팅 및 ARP 테이블이 있습니다. 컨테이너에서 이러한 모든 세부 정보를 봉인하려고 합니다. 컨테이너가 생성되면 네트워크 네임스페이스를 생성하므로 호스트의 네트워크 관련 정보를 볼 수 없습니다. 네임스페이스 내에서 컨테이너는 자체 가상 인터페이스, 라우팅 및 ARP 테이블을 가질 수 있습니다. 컨테이너에는 자체 인터페이스가 있습니다.

Create Network Namespace

Linux 호스트에서 새 네트워크 네임스페이스를 만들려면 ip netns add 커맨드를 실행합니다. 이 경우 두 개의 네트워크 네임스페이스를 생성합니다. 네트워크 네임스페이스를 조회하려면 ip netns 커맨드를 실행합니다.

Exec in Network Namespace

내 호스트의 인터페이스를 조회하기 위해 ip link 커맨드를 실행합니다. 호스트에 루프백 인터페이스와 80 인터페이스가 있는 것을 확인했습니다. 이제 red 또는 blue 네임스페이스 내에서 동일한 커맨드를 어떻게 실행하나요? 커맨드 앞에 ip netns exec 커맨드를 붙인 다음 네임스페이스 이름(red)을 붙입니다. 이제 red 네임스페이스 내에서 ip link 커맨드가 실행됩니다. 이를 수행하는 또 다른 방법은 원래 ip link 커맨드에 -n 옵션을 추가하는 것입니다. 이 둘은 동일합니다. 두 번째는 더 간단하지만 네임스페이스 내에서 ip 커맨드를 실행하려는 경우에만 작동한다는 점을 기억하세요.

보시다시피 루프백 인터페이스만 나열되며 호스트에서 80 인터페이스는 볼 수 없습니다. 따라서 네임스페이스를 사용하여 컨테이너가 호스트 인터페이스를 보지 못하도록 성공적으로 방지했습니다.

ARP and Routing Table

ARP 테이블도 마찬가지입니다. 호스트에서 ARP 커맨드를 실행하면 항목 목록이 표시되지만 컨테이너 내부에서 실행하면 항목이 표시되지 않습니다.

라우팅 테이블도 마찬가지입니다.

Virtual Cable

현재로서는 이러한 네트워크 네임스페이스에는 네트워크 연결이 없고 자체 인터페이스가 없으며 underlying 호스트 네트워크를 볼 수 없습니다. 네임스페이스 자체 간의 연결 설정을 먼저 살펴보겠습니다. 케이블을 사용하여 두 개의 물리적 머신을 각 머신의 인터넷 인터페이스에 연결하는 것과 마찬가지로 가상 이더넷 쌍 또는 가상 케이블을 사용하여 두 개의 네임스페이스를 함께 연결할 수 있습니다. 흔히 파이프라고 부르지만 저는 양쪽 끝에 두 개의 인터페이스가 있는 가상 케이블이라고 부르고 싶습니다.

케이블을 생성하려면 유형을 veth로 설정하고 ip link at 커맨드를 실행하고 두 끝 veth red 및 veth blue를 지정합니다. 다음 단계는 각 인터페이스를 적절한 네임스페이스에 연결하는 것입니다. 그렇게 하려면 ip link set veth red netns red 커맨드를 사용하십시오. 마찬가지로 blue 인터페이스를 blue 네임스페이스에 연결합니다. 그런 다음 이러한 각 네임스페이스에 IP 주소를 할당할 수 있습니다. 일반적인 ip addr 커맨드를 사용하여 IP 주소를 할당하지만 각 네임스페이스 내에서 사용합니다. red 네임스페이스에 ip 192.168.15.1을 할당합니다. 그런 다음 blue 네임스페이스에 ip 192.168.15.2를 할당했습니다. 그런 다음 각 네임스페이스 내의 각 장치에 대해 ip link setup 커맨드를 사용하여 인터페이스를 불러옵니다. 링크가 작동하고 이제 네임스페이스가 서로 연결할 수 있습니다.

red 네임스페이스에서 ping을 시도하여 blue네임스페이스의 ARP 테이블을 보면 MAC 주소가 있는 192.168.15.2에서 blue 이웃을 식별하는 것을 볼 수 있습니다. 마찬가지로 blue 네임스페이스에 ARP 테이블을 나열하면 red 이웃으로 식별되는 것을 볼 수 있습니다. 이것을 호스트의 ARP 테이블과 비교하면 호스트 ARP 테이블은 우리가 생성한 이러한 새 네임스페이스에 대해 전혀 모르고 그 안에 생성한 인터페이스에 대해 전혀 모른다는 것을 알 수 있습니다.

Linux Bridge

이제 네임스페이스가 두 개뿐이었을 때는 효과가 있었습니다. 네임스페이스가 더 많으면 어떻게 해야 할까요? 그들 모두가 서로 의사 소통을 할 수 있게 하려면 어떻게 해야 할까요? 실제 세계에서와 마찬가지로 호스트 내부에 가상 네트워크를 만듭니다. 네트워크를 생성하려면 스위치가 필요하므로 가상 네트워크를 생성하려면 가상 스위치가 필요합니다. 따라서 호스트 내에 가상 스위치를 생성하고 여기에 네임스페이스를 연결합니다. 그러나 호스트 내에서 가상 스위치를 어떻게 생성하나요? Linux 브리지라고 하는 네이티브 솔루션과 open V switch 등 여러 가지 솔루션을 사용할 수 있습니다. 이 예에서는 Linux 브리지 옵션을 사용합니다.

내부 브리지 네트워크를 생성하기 위해 유형이 bridge로 설정된 ip link add 커맨드를 사용하여 호스트에 새 인터페이스를 추가합니다. 이름은 v-net-0입니다. 우리 호스트에 관한 한 그것은 80 인터페이스와 같은 또 다른 인터페이스일 뿐입니다. 다른 인터페이스와 함께 ip link 커맨드의 출력에 나타납니다. 현재 꺼져 있으므로 켜야 합니다. ip link setup 커맨드를 사용하여 켭니다.

이제 네임스페이스의 경우 이 인터페이스는 연결할 수 있는 스위치와 같습니다. 따라서 호스트를 위한 인터페이스이자 네임스페이스를 위한 스위치라고 생각하세요.

다음 단계는 네임스페이스를 이 새로운 가상 네트워크 스위치에 연결하는 것입니다. 이전에는 두 네임스페이스를 직접 연결하기를 원했기 때문에 한쪽 끝에 veth red 인터페이스가 있고 다른 쪽 끝에 blue 인터페이스가 있는 케이블 또는 eth 쌍을 만들었습니다. 이제 모든 네임스페이스를 브리지 네트워크에 연결합니다. 따라서 이를 위해서는 새로운 케이블이 필요합니다. 이전 케이블은 더 이상 의미가 없으므로 제거하겠습니다. ip link delete 커맨드를 사용하여 케이블을 삭제합니다. 한쪽 끝이 있는 링크를 삭제하면 다른 쪽 끝은 쌍이기 때문에 자동으로 삭제됩니다.

이제 네임스페이스를 브리지에 연결하는 새 케이블을 만들어 보겠습니다. ip link add 커맨드를 실행하고 이전과 같이 한쪽 끝에 veth red가 있는 쌍을 생성하지만 이번에는 다른 쪽 끝에 이름이 지정됩니다. 브리지 네트워크에 연결되는 이름은 veth-red-br입니다. 이 명명규칙은 red 네임스페이스와 관련된 인터페이스를 쉽게 식별하는 데 도움이 됩니다. 마찬가지로 blue 네임스페이스를 브리지 네트워크에 연결하는 케이블을 만듭니다.

이제 케이블이 준비되었으므로 네임스페이스에 연결할 차례입니다. 인터페이스의 한쪽 끝을 red 네임스페이스에 연결하려면 ip link set veth-red netns red 커맨드를 실행합니다. 다른 쪽 끝을 브리지 네트워크에 연결하려면 ip link set  veth-red-br커맨드를 실행하고 v-net-0 네트워크로 이에 대한 마스터를 지정합니다. 동일한 절차에 따라 blue 네임스페이스와 브리지 네트워크에 blue 케이블을 연결합니다. 이제 이러한 링크에 대한 IP 주소를 설정하고 활성화하겠습니다. 192.168.15.1 및 192.168.15.2 으로, 이전에 사용했던 것과 동일한 IP 주소를 사용합니다. 그리고 마지막으로 장치를 켜세요.

이제 컨테이너는 네트워크를 통해 서로 도달할 수 있습니다. 따라서 동일한 절차에 따라 나머지 두 네임스페이스를 동일한 네트워크에 연결합니다.

이제 네 개의 네임스페이스가 모두 내부 브리지 네트워크에 연결되어 있으며 모두 서로 통신할 수 있습니다. 그들은 모든 IP 주소를 가지고 있습니다. 192.168.15.1, 2, 3, 4. 그리고 기억하세요. 우리 호스트는 내 호스트의 IP 192.168.1.2를 할당했습니다. 이러한 네임스페이스에서 이러한 인터페이스 중 하나에 도달하려고 하면 어떻게 될까요? 작동할까요? 아니요. 내 호스트는 한 네트워크에 있고 네임스페이스는 다른 네트워크에 있습니다. 하지만 내 호스트와 이러한 네임스페이스 간에 연결을 설정하고 싶다면 어떻게 해야 할까요? virt 스위치는 실제로 호스트의 네트워크 인터페이스라고 말한 것을 기억하세요. 따라서 호스트의 192.168.15 네트워크에 인터페이스가 있습니다. 이것은 단지 또 다른 인터페이스이기 때문에 우리가 해야 할 일은 IP 주소를 할당하여 이를 통해 네임스페이스에 도달할 수 있도록 하는 것입니다.

ip addr 커맨드를 실행하여 IP 192.168.15.5를 이 인터페이스로 설정합니다. 이제 로컬 호스트에서 red 네임스페이스를 ping할 수 있습니다. 이제 이 전체 네트워크는 여전히 비공개이며 호스트 내에서 제한된다는 점을 기억하세요. 네임스페이스 내에서 외부 세계에 도달할 수 없으며, 외부 세계의 누구도 내부에서 호스팅되는 서비스나 애플리케이션에 도달할 수 없습니다. 외부 세계로 통하는 유일한 문은 호스트의 이더넷 포트입니다.

그렇다면 이더넷 포트를 통해 회선 네트워크에 도달하도록 이 브리지를 구성하려면 어떻게 해야 할까요? 주소가 192.168.1.3인 line 네트워크에 다른 호스트가 연결되어 있다고 가정합니다. 내 네임스페이스 내에서 이 호스트에 도달하려면 어떻게 해야 합니까? ping을 시도하면 어떻게 됩니까? 내 네임스페이스에서 이 호스트를 사용하시겠습니까? blue 네임스페이스는 내가 현재 네트워크인 192.168.15와 다른 192.168.1에서 네트워크에 연결하려고 시도하고 있음을 확인합니다. 따라서 해당 네트워크를 찾는 방법을 알아보기 위해 라우팅 테이블을 살펴봅니다. 라우팅 테이블에는 다른 네트워크에 대한 정보가 없습니다. 그래서 네트워크에 연결할 수 없다는 메시지가 나타납니다. 따라서 외부 세계에 대한 관문이나 문을 제공하기 위해 라우팅 테이블에 항목을 추가해야 합니다.

그렇다면 그 게이트웨이를 어떻게 찾을 수 있을까요? 이전에 논의한 것처럼 도어 또는 게이트웨이는 다른 네트워크에 연결되는 로컬 네트워크의 시스템입니다. 그렇다면 192.168.15 네트워크인 blue 네임스페이스에 로컬인 네트워크에 하나의 인터페이스가 있고, 외부 LAN 네트워크에도 연결되는 시스템은 무엇입니까? 아래 logical view를 봅시다.

 

이것은 네임스페이스를 ping할 수 있도록 모든 네임스페이스가 있는 로컬 호스트입니다. 로컬 호스트에는 개인 네트워크를 연결하는 인터페이스가 있으므로 네임스페이스를 ping할 수 있습니다. 따라서 로컬 호스트는 두 네트워크를 함께 연결하는 게이트웨이입니다. 이제 blue 네임스페이스에 행 항목을 추가하여 192.168.15.5의 게이트웨이를 통해 모든 트래픽을 192.168.1 네트워크로 라우팅할 수 있습니다. 이제 호스트에는 두 개의 IP 주소가 있습니다. 하나는 1925.168.15.5의 브리지 네트워크에 있고 다른 하나는 192.168.1.2의 외부 네트워크에 있습니다. route에서 사용할 수 있습니까? 아니요. blue 네임스페이스는 192.168.15.5의 로컬 네트워크에 있는 게이트웨이에만 도달할 수 있기 때문입니다. default 게이트웨이는 route에 추가할 때 네임스페이스에서 연결할 수 있어야 합니다.

지금 ping을 시도하면 더 이상 네트워크에 연결할 수 없다는 메시지가 표시되지 않지만 여전히 ping에서 응답을 받지 못합니다. 무엇이 문제일까요? 우리는 이전 강의 중 하나에서 홈 네트워크에서 라우터를 통해 외부 인터넷에 도달하려고 시도한 것과 유사한 상황에 대해 이야기했습니다. 우리의 홈 네트워크에는 대상 네트워크가 알지 못하는 내부 사설 IP 주소가 있으므로 다시 연결할 수 없습니다. 이를 위해 자체 주소가 있는 자체 이름으로 LAN에 메시지를 보낼 수 있도록 여기에서 게이트웨이 역할을 하는 호스트에서 NAT 활성화가 필요합니다.

그렇다면 호스트에 NAT 기능을 추가하려면 어떻게 해야 할까요? IP 테이블을 사용하여 이를 수행해야 합니다. 포스트 라우팅 체인의 NAT IP 테이블에 새 rule을 추가하여 원본 네트워크에서 오는 모든 패킷의 보낸 사람 주소를 자체 IP 주소가 있는 192.168.15.0로 바꿉니다. 그렇게 하면 네트워크 외부에서 이러한 패킷을 받는 사람은 네임스페이스 내에서가 아니라 호스트에서 오는 것으로 생각할 것입니다. 지금 ping을 시도하면 외부 세계에 연결할 수 있음을 알 수 있습니다.

마지막으로 LAN이 인터넷에 연결되어 있다고 가정합니다. 네임스페이스가 인터넷에 연결되기를 원합니다. 그래서 blue 네임스페이스에서 8.8.8.8의 인터넷 서버에 ping을 시도합니다. 네트워크에 연결할 수 없다는 유사한 메시지가 표시됩니다. 이제 우리는 그 이유를 알고 있습니다. 우리는 라우팅 테이블을 보고 네트워크 192.168.1에 대한 route가 있지만 다른 route는 없음을 확인합니다. 이러한 네임스페이스는 호스트가 도달할 수 있는 모든 네트워크에 도달할 수 있으므로 외부 네트워크에 도달하려면 호스트와 대화한다고 간단히 말할 수 있습니다. 따라서 호스트를 지정하는 default 게이트웨이를 추가합니다. 이제 이러한 네임스페이스 내에서 외부 세계에 도달할 수 있어야 합니다.

이제 외부 세계에서 네임스페이스 내부로의 연결은 어떨까요? 예를 들어 blue 네임스페이스가 포트 80에서 웹 애플리케이션을 호스팅한다고 가정해 보겠습니다. 현재 네임스페이스는 내부 사설 네트워크에 있으며 외부 세계의 누구도 이에 대해 알지 못합니다. 호스트 자체에서만 액세스할 수 있습니다. 다른 네트워크에 있는 다른 호스트에서 네임스페이스의 사설 IP로 ping을 시도하면 해당 호스트가 이 사설 네트워크에 대해 모르기 때문에 분명히 연결할 수 없다는 것을 알 수 있습니다. 이러한 통신을 가능하게 하려면 두 가지 옵션이 있습니다. 이전 강의에서 본 두 가지 옵션입니다. 첫 번째는 개인 네트워크의 ID를 두 번째 호스트에 제공하는 것입니다. 따라서 기본적으로 두 번째 호스트에 ip route 항목을 추가하여 호스트에 네트워크 192.168.15가 192.168.1.2의 호스트를 통해 도달할 수 있음을 알려줍니다. 하지만 우리는 그렇게 하고 싶지 않습니다. 다른 옵션은 로컬 호스트의 포트 80으로 들어오는 모든 트래픽이 blue 네임스페이스에 할당된 IP의 포트 80으로 전달되도록 IP 테이블을 사용하여 포트 전달 롤을 추가하는 것입니다.