Linux Network Namespace와 Bridge 직접 구성하기
Linux Network Namespace와 Bridge 직접 구성하기
1. Linux Network Namespace란?
Linux 서버에서 네트워크 장애를 분석하려면 IP 주소와 라우팅 테이블뿐만 아니라, 네트워크가 어떤 단위로 분리되고 연결되는지도 이해해야 합니다.
Linux의 Network Namespace는 네트워크 환경을 논리적으로 분리하는 기능입니다. 각 네임스페이스는 독립적인 네트워크 인터페이스, 라우팅 테이블, 네트워크 소켓 등을 가질 수 있습니다.
예를 들어 일반적인 Linux 서버에는 다음과 같은 네트워크 환경이 존재합니다.
Linux Host ├── NIC: ens160 ├── IP: 192.168.10.10/24 ├── Routing Table └── Network Sockets
Network Namespace를 사용하면 하나의 Linux 커널 안에서 여러 개의 독립적인 네트워크 환경을 만들 수 있습니다.
Linux Host
|
+-- Root Namespace
| └── ens160
|
+-- Namespace A
| └── eth0
|
+-- Namespace B
└── eth0
각 네임스페이스의 eth0는 이름이 같더라도 서로 다른 네트워크 인터페이스입니다. 각 네임스페이스에서 설정한 IP 주소와 라우팅 테이블도 기본적으로 분리됩니다.
이 기술은 다음 환경에서 활용됩니다.
- Docker 컨테이너 네트워크
- Kubernetes Pod 네트워크
- 네트워크 기능 가상화
- 라우팅 및 방화벽 실습
- 네트워크 장애 재현과 테스트
2. 실습 환경 구성
이번 실습에서는 실제 물리 NIC를 변경하지 않고 가상 네트워크만 구성합니다.
목표는 다음과 같습니다.
- Network Namespace 두 개를 생성한다.
- veth Pair를 생성한다.
- Linux Bridge에 두 네임스페이스를 연결한다.
- 각 네임스페이스에 IP 주소를 설정한다.
- Ping으로 통신을 검증한다.
tcpdump로 패킷을 확인한다.- 장애를 일부러 발생시키고 원인을 분석한다.
구성도는 다음과 같습니다.
Linux Host
+--------------------------------+
| |
| br-lab |
| 192.168.100.1/24 |
| / \ |
| / \ |
| veth-a veth-b |
+--------|-----------|------------+
| |
veth-a veth-b
| |
+------+---+ +----+------+
| ns-a | | ns-b |
| eth0 | | eth0 |
| .100.10 | | .100.20 |
+-----------+ +-----------+
이 구성에서는 두 네임스페이스가 같은 IP 서브넷에 있으므로 Linux Bridge를 통해 직접 통신할 수 있습니다.
실습은 root 권한이 있는 Linux 테스트 서버에서 진행합니다. 운영 서버에서는 임의로 네트워크 인터페이스를 변경하지 말고 별도의 테스트 환경을 사용하는 것이 안전합니다.
3. 사전 준비
필요한 명령어가 설치되어 있는지 확인합니다.
ip -V bridge -V tcpdump --version
Rocky Linux나 RHEL 계열에서는 환경에 따라 다음 패키지가 필요할 수 있습니다.
sudo dnf install -y iproute tcpdump
폐쇄망 환경이라면 외부 저장소에 접속하지 말고, 사내 패키지 저장소나 설치 미디어를 이용해야 합니다.
현재 네트워크 상태를 확인합니다.
ip -br link ip -br addr ip route
이번 실습에서는 기존 물리 NIC의 IP 주소나 기본 게이트웨이를 변경하지 않습니다.
4. 1단계 — Network Namespace 생성
먼저 두 개의 네임스페이스를 생성합니다.
sudo ip netns add ns-a sudo ip netns add ns-b
생성 결과를 확인합니다.
ip netns list
예상 출력:
ns-b ns-a
각 네임스페이스의 네트워크 인터페이스를 확인합니다.
sudo ip -n ns-a link sudo ip -n ns-b link
처음 생성한 네임스페이스에는 일반적으로 루프백 인터페이스만 존재합니다.
루프백 인터페이스는 각 네임스페이스 내부에서만 사용하는 인터페이스입니다. 실제 네트워크 통신을 하려면 가상 Ethernet 인터페이스를 추가해야 합니다.
5. 2단계 — veth Pair 생성
veth Pair는 서로 연결된 두 개의 가상 Ethernet 인터페이스입니다.
한쪽 인터페이스로 들어간 패킷은 반대쪽 인터페이스로 전달됩니다.
다음 명령으로 가상 인터페이스를 생성합니다.
sudo ip link add veth-a type veth peer name veth-a-peer sudo ip link add veth-b type veth peer name veth-b-peer
현재 인터페이스를 확인합니다.
ip -br link
네임스페이스 내부에서 사용할 인터페이스를 각각 이동합니다.
sudo ip link set veth-a netns ns-a sudo ip link set veth-b netns ns-b
이제 각 네임스페이스에 인터페이스가 존재하는지 확인합니다.
sudo ip -n ns-a link sudo ip -n ns-b link
인터페이스를 이동하면 해당 인터페이스는 호스트의 기본 네임스페이스에서 더 이상 일반 인터페이스로 표시되지 않습니다.
이것이 Network Namespace의 중요한 특징입니다. 인터페이스 자체가 네임스페이스에 소속될 수 있습니다.
6. 3단계 — Linux Bridge 생성
Linux Bridge는 여러 인터페이스를 Layer 2 수준에서 연결하는 가상 스위치와 유사한 기능을 제공합니다.
먼저 Bridge를 생성합니다.
sudo ip link add br-lab type bridge
Bridge에 IP 주소를 설정합니다.
sudo ip addr add 192.168.100.1/24 dev br-lab
Bridge 인터페이스를 활성화합니다.
sudo ip link set br-lab up
상태를 확인합니다.
ip addr show br-lab bridge link
이제 호스트의 기본 네임스페이스에 br-lab이라는 가상 스위치가 만들어졌습니다.
다만 Bridge만 생성했다고 해서 네임스페이스들이 자동으로 연결되는 것은 아닙니다. 각 네임스페이스의 인터페이스를 Bridge에 연결해야 합니다.
7. 4단계 — veth를 Bridge에 연결
네임스페이스 내부에 있는 veth-a, veth-b의 반대쪽 인터페이스는 호스트에 남아 있습니다.
이 호스트 측 인터페이스를 Bridge에 연결합니다.
sudo ip link set veth-a-peer master br-lab sudo ip link set veth-b-peer master br-lab
인터페이스를 활성화합니다.
sudo ip link set veth-a-peer up sudo ip link set veth-b-peer up
네임스페이스 내부의 인터페이스도 활성화합니다.
sudo ip -n ns-a link set lo up sudo ip -n ns-a link set eth0 up sudo ip -n ns-b link set lo up sudo ip -n ns-b link set eth0 up
여기서 인터페이스 이름에 주의해야 합니다. 네임스페이스로 이동한 인터페이스는 이 실습에서 veth-a, veth-b라는 이름을 유지합니다. 아직 eth0으로 이름을 변경하지 않았으므로 실제로는 다음 명령을 사용해야 합니다.
sudo ip -n ns-a link set veth-a name eth0 sudo ip -n ns-b link set veth-b name eth0
이름을 변경한 후 다시 활성화합니다.
sudo ip -n ns-a link set eth0 up sudo ip -n ns-b link set eth0 up
Bridge 구성을 확인합니다.
bridge link
예상 구조:
veth-a-peer master br-lab veth-b-peer master br-lab
출력 형식과 인터페이스 인덱스는 시스템에 따라 다를 수 있습니다.
8. 5단계 — IP 주소 설정
각 네임스페이스에 서로 다른 IP 주소를 설정합니다.
ns-a:
sudo ip -n ns-a addr add 192.168.100.10/24 dev eth0
ns-b:
sudo ip -n ns-b addr add 192.168.100.20/24 dev eth0
IP 주소를 확인합니다.
sudo ip -n ns-a -br addr sudo ip -n ns-b -br addr
예상 결과:
ns-a eth0 UP 192.168.100.10/24 ns-b eth0 UP 192.168.100.20/24
각 네임스페이스의 라우팅 테이블도 확인합니다.
sudo ip -n ns-a route sudo ip -n ns-b route
두 네임스페이스는 같은 192.168.100.0/24 네트워크에 있으므로 직접 연결된 경로가 자동으로 등록됩니다.
별도의 기본 게이트웨이는 아직 설정하지 않았습니다. 이번 실습의 목표는 같은 서브넷 안에서 Bridge를 통한 통신을 확인하는 것이기 때문입니다.
9. 6단계 — Ping으로 통신 확인
이제 ns-a에서 ns-b로 Ping을 실행합니다.
sudo ip netns exec ns-a ping -c 4 192.168.100.20
정상적으로 구성되었다면 Echo Reply가 돌아옵니다.
반대 방향도 확인합니다.
sudo ip netns exec ns-b ping -c 4 192.168.100.10
통신 경로는 다음과 같습니다.
ns-a
192.168.100.10
|
v
eth0
|
v
veth Pair
|
v
br-lab
|
v
veth Pair
|
v
eth0
|
v
ns-b
192.168.100.20
두 네임스페이스는 같은 서브넷에 있으므로 목적지 IP를 향해 ARP를 수행하고, 확인한 MAC 주소를 이용해 Ethernet 프레임을 전달합니다.
여기서 중요한 점은 같은 서브넷의 통신에는 기본 게이트웨이가 필요하지 않다는 것입니다. 다만 인터페이스와 Bridge 상태, IP 설정, ARP 및 방화벽 정책은 정상이어야 합니다.
10. 7단계 — ARP와 Bridge MAC 테이블 확인
Ping을 실행한 후 각 네임스페이스의 이웃 테이블을 확인합니다.
sudo ip -n ns-a neigh show sudo ip -n ns-b neigh show
예상 결과는 다음과 유사합니다.
192.168.100.20 dev eth0 lladdr aa:bb:cc:dd:ee:ff REACHABLE
MAC 주소는 실제 환경에서 자동으로 생성되므로 예시와 다릅니다.
Linux Bridge가 학습한 MAC 주소도 확인합니다.
bridge fdb show br br-lab
Bridge는 Ethernet 프레임의 출발지 MAC 주소를 학습하고, 목적지 MAC 주소에 따라 프레임을 전달합니다.
이 동작은 물리 스위치의 MAC 주소 테이블 학습과 유사합니다.
11. 8단계 — tcpdump로 패킷 분석
이제 패킷이 실제로 어떻게 전달되는지 확인합니다.
먼저 호스트에서 Bridge 인터페이스를 캡처합니다.
sudo tcpdump -nn -e -i br-lab \ 'arp or icmp'
다른 터미널에서 Ping을 실행합니다.
sudo ip netns exec ns-a ping -c 2 192.168.100.20
ARP 요청과 응답, ICMP Echo Request와 Echo Reply를 확인할 수 있습니다.
각 네임스페이스 내부에서도 캡처할 수 있습니다.
sudo ip netns exec ns-a \ tcpdump -nn -e -i eth0 'arp or icmp'
패킷 흐름을 분석할 때는 다음 순서로 확인합니다.
ns-a에서 ARP 요청이 발생하는가?- ARP 응답으로 목적지 MAC 주소를 학습하는가?
- ICMP Echo Request가 Bridge를 통과하는가?
ns-b의 인터페이스에서 요청이 관찰되는가?- Echo Reply가 반대 방향으로 돌아오는가?
이렇게 확인하면 단순히 Ping 성공 여부를 확인하는 것을 넘어, 패킷이 어느 구간까지 도달하는지 분석할 수 있습니다.
12. 장애 실습 — 인터페이스를 DOWN으로 변경하기
이제 일부러 장애를 발생시켜 보겠습니다.
ns-b의 인터페이스를 비활성화합니다.
sudo ip -n ns-b link set eth0 down
다시 Ping을 실행합니다.
sudo ip netns exec ns-a ping -c 4 192.168.100.20
통신이 실패할 수 있습니다.
이제 인터페이스 상태를 확인합니다.
sudo ip -n ns-b link show eth0
원인이 명확해졌습니다. ns-b의 인터페이스가 DOWN 상태이므로 정상적인 통신이 불가능합니다.
복구합니다.
sudo ip -n ns-b link set eth0 up
다시 Ping을 실행합니다.
sudo ip netns exec ns-a ping -c 4 192.168.100.20
실제 운영 환경에서도 통신 실패 시 인터페이스 상태를 확인하는 것이 기본입니다. 다만 실제 장애에서는 NIC가 UP이어도 VLAN, 라우팅, 방화벽, 서비스 상태 등의 문제로 통신이 실패할 수 있습니다.
13. 장애 실습 — 잘못된 IP 주소 설정
이번에는 ns-b의 IP 주소를 변경해 보겠습니다.
기존 IP를 삭제합니다.
sudo ip -n ns-b addr del 192.168.100.20/24 dev eth0
다른 서브넷의 주소를 설정합니다.
sudo ip -n ns-b addr add 192.168.200.20/24 dev eth0
다시 Ping을 실행합니다.
sudo ip netns exec ns-a ping -c 4 192.168.200.20
이번에는 통신이 실패할 수 있습니다. ns-a는 192.168.200.20을 다른 네트워크의 주소로 판단하지만 기본 경로가 없기 때문입니다.
라우팅 테이블을 확인합니다.
sudo ip -n ns-a route
이 실습에서는 두 네임스페이스를 같은 서브넷으로 연결하도록 구성했기 때문에 주소 변경으로 통신 조건이 달라졌습니다.
이처럼 IP 주소뿐 아니라 Subnet Mask와 라우팅 테이블도 함께 확인해야 합니다.
실습이 끝나면 ns-b의 IP를 원래대로 복구합니다.
sudo ip -n ns-b addr del 192.168.200.20/24 dev eth0 sudo ip -n ns-b addr add 192.168.100.20/24 dev eth0
14. Network Namespace에서 외부 네트워크까지 연결하려면?
이번 실습에서는 같은 서브넷에 있는 두 네임스페이스만 연결했습니다.
네임스페이스에서 외부 네트워크로 통신하려면 별도의 라우팅과 네트워크 연결 구성이 필요합니다.
일반적으로 다음 요소를 고려해야 합니다.
- 네임스페이스의 기본 게이트웨이
- 호스트의 IP 포워딩 설정
- 호스트의 라우팅 테이블
- 필요한 경우 SNAT 또는 MASQUERADE
- 호스트와 외부 네트워크의 방화벽 정책
- 반환 경로
예를 들어 컨테이너 네트워크에서 외부로 통신할 때는 호스트가 패킷을 전달하고 NAT를 수행하는 구조가 사용될 수 있습니다.
다만 IP 포워딩을 활성화하거나 NAT 규칙을 추가하면 시스템의 네트워크 동작에 영향을 줄 수 있으므로, 이번 기본 실습에서는 해당 설정을 변경하지 않습니다.
15. 실습 환경 정리
실습이 끝나면 생성한 네트워크 리소스를 삭제합니다.
먼저 네임스페이스를 삭제합니다.
sudo ip netns del ns-a sudo ip netns del ns-b
그다음 호스트에 남아 있는 가상 인터페이스와 Bridge를 삭제합니다.
sudo ip link del veth-a-peer sudo ip link del veth-b-peer sudo ip link del br-lab
인터페이스가 이미 삭제되어 오류가 발생한다면 현재 상태를 확인한 후 진행하면 됩니다.
ip netns list ip -br link ip route
이번 실습은 전용으로 생성한 인터페이스만 사용했습니다. 기존 물리 NIC나 운영 네트워크 인터페이스를 삭제하거나 변경하지 않도록 주의해야 합니다.
16. 시스템 엔지니어가 반드시 기억해야 할 핵심
이번 실습의 핵심은 다음과 같습니다.
구성 요소역할Network Namespace네트워크 환경 분리veth Pair네임스페이스와 호스트 사이의 가상 Ethernet 연결Linux BridgeLayer 2 프레임 전달IP Address네트워크 계층에서 통신 대상을 식별Routing Table목적지까지의 경로 결정ARPIPv4 주소에 대응하는 MAC 주소 확인tcpdump패킷 흐름 관찰 및 장애 분석
Docker 네트워크는 이러한 Linux 네트워크 기능을 기반으로 동작합니다. 따라서 Network Namespace와 Bridge를 직접 구성할 수 있다면 컨테이너 네트워크의 동작을 훨씬 명확하게 이해할 수 있습니다.
마무리
이번 편에서는 Linux Network Namespace와 veth Pair, Linux Bridge를 직접 구성해 서로 다른 네임스페이스 사이의 통신을 구현했습니다. 또한 ARP와 Bridge MAC 테이블을 확인하고, tcpdump로 패킷을 분석했으며, 인터페이스 상태와 IP 설정을 변경해 장애를 재현했습니다.
실무에서 중요한 것은 네트워크가 정상인지 여부만 확인하는 것이 아니라, 어떤 인터페이스에서 패킷이 발생하고 어느 지점에서 전달이 끊기는지 확인하는 능력입니다.
다음 편에서는 이러한 네트워크 기술이 Docker Compose 환경에서 어떻게 활용되는지 살펴보겠습니다. 웹 서버, 애플리케이션 서버, 데이터베이스를 분리하고 각 서비스가 어떤 네트워크를 통해 통신하는지 실습하겠습니다.
다음 편은 시스템 엔지니어 실전 교육 23편 — Docker Compose 다중 컨테이너 네트워크 구성과 장애 분석입니다. Nginx, FastAPI, PostgreSQL을 연결해 서비스 간 통신과 네트워크 분리까지 실습하는 단계로 이어가겠습니다.
댓글
아직 댓글이 없습니다.
로그인 후 댓글을 남길 수 있습니다.