네트워크 네임스페이스는 장치, IP 스택, 라우팅 테이블, 방화벽 규칙과 소켓 포트 공간을 서로 분리합니다. veth 페어는 두 네임스페이스 사이에 패킷을 전달하는 가상 이더넷 링크입니다. 다만 케이블에 해당하는 링크를 만들었다고 주소와 경로, 포워딩 정책까지 자동으로 설정되는 것은 아닙니다.

서로 분리된 두 Linux 네트워크 스택을 veth 쌍이 연결하고 별도 경로 설정이 필요한 점을 나타낸 개념도

네임스페이스마다 달라지는 네트워크 상태

리눅스 네트워크 네임스페이스는 프로세스가 보는 네트워크 자원의 범위를 나눕니다. 한 네임스페이스에 있는 인터페이스와 다른 네임스페이스의 인터페이스는 같은 이름을 쓸 수 있고, 주소와 라우팅 테이블, 방화벽 규칙도 각 공간에서 따로 관리됩니다. 따라서 한쪽의 기본 경로를 바꿔도 다른 쪽의 경로가 함께 바뀌지 않습니다.

이 분리는 네트워크 설정이 어디에서 적용되는지 이해할 때 중요합니다. 예를 들어 ip route 결과는 명령을 실행한 네임스페이스의 경로표를 보여 줍니다. 호스트에서 본 경로만 확인하면 컨테이너나 다른 네임스페이스가 실제로 선택한 출구를 놓칠 수 있습니다. 같은 이유로 방화벽 규칙도 어느 네임스페이스의 규칙인지 구분해야 합니다.

veth 페어는 두 끝이 맞닿은 링크

veth 장치는 항상 쌍으로 만들어집니다. 한쪽 끝으로 보낸 프레임은 반대쪽 끝에서 수신됩니다. 한 끝을 별도 네임스페이스로 옮기면 두 공간을 잇는 가상 케이블이 됩니다. Red Hat의 예제처럼 각 끝을 서로 다른 네임스페이스에 두고 주소를 할당하면 두 지점 사이에서 통신을 시험할 수 있습니다.

여기서 veth를 터널 전체나 라우터로 오해하면 진단이 꼬입니다. veth가 제공하는 것은 링크 계층의 연결입니다. 인터페이스를 올리고 양쪽 주소와 서브넷을 맞춰야 직접 연결된 상대를 찾을 수 있습니다. 링크의 한쪽이 내려가면 짝인 링크도 연결 상태를 잃으므로, 양쪽 끝의 상태를 함께 확인하는 편이 좋습니다.

연결과 라우팅은 다른 단계

같은 서브넷의 두 인터페이스끼리 통신하는 경우에는 주소와 링크 상태가 핵심입니다. 다른 네트워크로 패킷을 보내려면 송신 측 라우팅 테이블에 목적지에 맞는 다음 경로가 있어야 합니다. 목적지까지 가는 경로가 여러 네임스페이스나 호스트를 거친다면 각 구간의 라우팅과 전달 설정도 맞아야 합니다. 한 네임스페이스의 경로표가 다른 네임스페이스의 경로를 대신해 주지는 않습니다.

예를 들어 A 네임스페이스의 목적지가 B의 직접 연결 범위를 벗어났는데 B가 중계 역할을 하지 않는다면, A와 B를 잇는 링크가 살아 있어도 그 뒤 네트워크까지 패킷이 전달되지는 않습니다. 링크 확인과 목적지까지의 전체 경로 확인을 분리하면 이 차이를 파악하기 쉽습니다.

호스트를 경유해 외부 네트워크까지 연결하려는 구성은 여기서 한 단계 더 나아갑니다. 호스트 인터페이스 연결만으로 패킷 전달이 켜지는 것은 아니며, 필요한 IP 포워딩과 방화벽 정책, 경우에 따라 주소 변환을 운영자가 설정해야 합니다. 따라서 “veth가 연결됐는데 인터넷이 안 된다”는 현상은 veth 고장 하나로 단정할 수 없습니다. 인터페이스 상태와 주소, 각 공간의 경로, 포워딩 및 필터 규칙을 패킷이 지나는 순서로 확인해야 합니다.

패킷이 멈춘 경계를 좁혀 보기

점검은 먼저 패킷의 출발 네임스페이스와 목적지를 정하는 데서 시작합니다. 출발지 안에서 인터페이스 주소와 링크 상태, 경로 선택을 확인하고, veth 반대편에서도 수신 여부와 인터페이스 상태를 봅니다. 양쪽이 연결된 뒤에도 원격 네트워크에 닿지 않으면 그 다음 홉을 맡은 네임스페이스의 경로표와 포워딩·방화벽 설정을 이어서 살핍니다. 이렇게 경계를 하나씩 이동하면 링크 문제와 라우팅 문제를 구분하기 쉽습니다.

네트워크 네임스페이스는 네트워크 스택의 자원을 나누는 커널 기능이지 완전한 가상 머신은 아닙니다. veth 페어 역시 그 자체로 보안 경계나 완성된 네트워크 구성을 보장하지 않습니다. 실제 격리 수준과 도달 가능성은 권한, 커널, 인터페이스 배치, 경로 및 필터 정책에 따라 달라집니다.

참고 자료