Network Namespaces

• 네트워크 네임스페이스는 도커와 같이 네트워크 독립성을 위해 사용된다.

• 간단한 호스트를 보자.

• 호스트를 집으로 상상해보면 네임스페이스는 집 안의 방이다.

• 방 안의 자식들은 오직 방 안만 볼 수 있고 그 밖은 볼 수 없다.

• 부모의 경우 모든 집안의 방을 볼 수 있다.

• 필요하다면 두 방을 연결할 수 있다.

Process Namespace

• 호스트안에 프로세스를 만들고 그 네임스페이스를 줘보자.

• 컨테이너 안에서보면 프로세스는 하나이다.

• 호스트 안의 프로세스를 확인해보면, 컨테이너 안의 프로세스를 포함한 모든 프로세스를 확인할 수 있다.

• 같은 프로세스가 다른 ID로 컨테이너 안과, 밖에 동작하고 있는 것이다.

• 이것이 네임스페이스가 동작하는 원리이다.

Network Namespace

• 호스트는 라우팅 테이블과 ARP 테이블을 갖는다.

• 컨테이너는 자신만의 라우팅 테이블과 ARP 테이블을 갖는다.

• 이말은 즉, 컨테이너안의 네트워크는 자신만의 독자적인 네트워크 체계를 갖는다는 것을 의미한다.

Create Network Namespace

• ip netns add red 명령어로 네트워크 네임스페이스를 만들 수 있다.

• ip netns 명령어를 사용하면 현재 호스트 안에 생성된 네임스페이스를 확인할 수 있다.

Exec in Network Namespace

• ip link 명령어를 입력하면 호스트 내에 존재하는 eth0 인터페이스와 루프백 인터페이스를 볼 수 있다.

• 방금 만든 네임스페이스의 정보를 확인하기 위해서는 ip netns exec red ip link 명령어로 확인할 수 있다.

• 네임스페이스를 사용하면 컨테이너가 호스트의 인터페이스를 보는 것을 막을 수 있다.

• 호스트에서 arp 며열ㅇ어를 입력하면 엔트리 리스트를 볼 수 있다.

• 그러나 컨테이너 안에서 같은 명령어를 수행하면 볼 수 없다.

• 이러한 두 네임스페이스간의 연결을 위해서는 가상 케이블을 연결해주어야한다. 이는 명령어로 가능하다.

• ip link add veth-red type veth peer name veth-blue

• 이러면 veth-red 케이블이 veth-blue와 연결된다. ( blue 네임스페이스가 있다고 가정 )

• 그 후 이렇게 만들어진 인터페이스를 네임스페이스와 연결해주어야한다. 명령어는 다음과 같다.

• ip link set veth-red netns red, ip link set veth-blue netns blue

• 이렇게 하면 각각의 가상 케이블이 두 네임스페이스를 연결하고 있게 되며 이제 두 네임스페이스는 서로 통신할 수 있게 된다.

• 그리고 나서 호스트 내부 ip를 각각의 네임스페이스에 부여해주자.

• ip -n red addr add 192.158.15.1 dev veth-red, ip -n blue addr add 192.158.15.2 dev veth-blue

• 그 후 ip link set up 명령어를 통해 각각의 네임스페이스에 닿을 수 있게 셋팅해주자.

• ip -n red link set veth-red up, ip -n blue link set veth-blue up

• ip netns exec red ping 192.168.15.2 레드에서 블루로 핑을 날려보면 핑이날아가는 것을 확인할 수 있고, ip netns exec red arp ARP 테이블에도 블루의 IP 주소가 매핑되어있는 것을 확인할 수 있다.

• 그러면 호스트 내의 모든 네임스페이스들이 서로 통신할 수 있게 하려면 어떻게 해야할까?

• physical 환경에서 스위치가 필요했듯이, 호스트 내의 네임스페이스들 사이에 virtual 스위치가 필요하다.

• 이런 호스트 내의 가상 스위치를 생성하는 여러 방법이 있지만 Linux Bridge의 ip link add v-net-0 type bridge 명령어로 가상 스위치를 생성하자.

• 최초 생성하면 다운되어있으므로 ip link set dev v-net-0 up 명령어를 사용하여 실행해주자.

• 가상 스위치가 생겼으므로 더 이상 가상 케이블이 필요없어졌다. ip -n red link del veth-red 명령어를 사용해 케이블을 지우면 blue도 자동으로 지워진다.

• 가상 스위치에 연결할 케이블을 생성할건데, ip link add veth-red type veth peer name veth-red-br로 생성한다.

• 여기서 veth-red-br에서의 br은 일종의 컨벤션인데 가상 스위치에 연결될 인터페이스라는 것을 쉽게 알려주기 위함이다.

• ip linek set veth-red netns red 명령어를 통해 레드 네임스페이스에 케이블을 붙여준다.

• ip link set veth-red-br master v-net-0 명령어를 통해 br 케이블은 아까 만들어둔 가상 스위치에 연결해준다.

• 그 후 이전과 마찬가지로 각각의 네임스페이스에 IP를 할당해주고, link set up 명령어를 사용해 실행하면 이제 이 가상 스위치를 통해 모든 호스트 내의 네임스페이스 네트워크가 상호 연결이 가능해진다!

• 그럼 다른 호스트에서 이 네임스페이스들에 접근이 가능할까? 별도의 설정 없이는 불가능하다.

• 가상 스위치와 네임스페이스는 호스트 내의 격리된 호스트이며, 외부의 요청은 이더넷을 통해 받을 뿐 그것이 내부의 네임스페이스로까지는 연결이 되지 않는다.

• 네트워크 네임스페이스는 철저히 호스트 내에서 격리된 네트워크라는 것을 잊지 말자.

• 그러면 내부 네임스페이스가 외부의 다른 호스트에 요청을 보내기 위해선 어떻게 해야할까?

• 가령 blue 네임스페이스에서 외부 호스트 B로 전달한다고 가정해보자.

• B의 IP는 192.16.1.3인데, ip netns exec blue route를 확인해보면 블루 네임스페이스의 라우팅 테이블에는 호스트 네트워크인 192.168.15.0만이 존재할 것이다.

• 우리는 이전 시간에 게이트웨이는 일종의 문이며, 이를 통해 외부로 트래픽을 전송할 수 있다고 배웠다.

• 네임스페이스 blue가 존재하는 호스트 A와 전달할 호스트 B 사이에는 LAN 192.168.1.0이 존재한다.

• ip netns exec blue ip route add 192.168.1.0/24 via 192.168.15.5로 네임스페이스의 접근 인터페이스인 v-net-0 (스위치) IP를 게이트웨이로 두고, 목적지인 192.168.1.0으로 전달 가능하게 라우팅 테이블에 추가해준다.

• 이러면 이후부터 블루 네임스페이스는 스위치를 타고 게이트웨이를 이용해 호스트 B로 전달될 수 있는 것이다.

• 여기서 우리는 게이트웨리를 사용해 LAN으로 메시지를 보내고 있다.

• A 호스트와 B 호스트를 연결하는 LAN이 만약 인터넷과 연결된다면 네임스페이스는 외부 서비스로 요청을 보낼 수 있을 것이다.

• 그러나 실제로 요청을 날려보면 요청이 가지 않는데, 이는 라우팅 테이블에 외부로 나갈 목적지가 명시되지않았기 때문이다.

• 이를 하기 위한 Default Gateway가 호스트에 이미 존재하므로, ip nets exec blue ip route add default via 192.16.15.5 그저 default와 스위치의 IP주소만 입력하면 네임스페이스가 외부 세계로 요청을 보내는 것이 가능해질 것이다.