컨테이너에는 네트워크 인터페이스가 있지만 호스트에는 없습니다. eth0을 컨테이너에 노출하는 방법

Question 1

네트워크 카드를 하드웨어의 특정 부분으로 잊어버리십시오. 네트워크 인터페이스가 있고 이를 컨테이너로 옮겨야 한다고 가정해 보겠습니다. 이는 USB 또는 PCI 패스스루가 아닙니다. 우리는 이것을 인터페이스 전달이라고 부릅니다.네트워크 네임스페이스 논리예를 들어ip link:

회로망네트워크 이름|PID

이름과 연결된 네트워크 네임스페이스로 장치를 이동합니다.네트워크 이름또는 프로세스PID. 일부 장치에서는 루프백, 브리지, ppp, 무선과 같은 네트워크 네임스페이스 변경을 허용하지 않습니다. 이는 네트워크 네임스페이스 로컬 장치입니다. 이 경우 ip 도구는 "잘못된 인수" 오류를 반환합니다. 장치가 단일 네트워크 네임스페이스에 대해 로컬인지 확인할 수 있습니다.netns-local출력의 플래그ethtool:
ethtool -k DEVICE
무선 장치의 네트워크 네임스페이스를 변경하려면iw도구를 사용할 수 있습니다. 그러나 물리적 장치 및 프로세스의 네트워크 네임스페이스 변경만 허용됩니다.PID.

인터페이스는 처음에 호스트 시스템에 나타나야 하지만 컨테이너로 이동할 수 있습니다. 플러그인할 때 컨테이너에 직접 표시되도록 하는 옵션은 없지만(물론 컨테이너가 시작될 때 컨테이너의 특정 구성을 통해 인터페이스를 이동할 수 있음, 아래 참조) 작동할 수도 있습니다 udev. 호스트와 컨테이너 네트워킹이 전혀 사용되지 않더라도 호스트는 물론 필요한 모든 네트워킹 옵션을 사용하여 컴파일해야 하며 필요할 때 관련 커널 모듈을 로드하는 일을 계속 담당해야 합니다(대개 투명하게 수행됨).

따라서 결국 카드가 eth0호스트에서 호출되고 실제로 이더넷(무선 아님)인 경우 이 명령은 카드를 대상 네임스페이스로 이동합니다.

ip link set eth0 netns NETNSNAME

여기서 NETNSNAME은 위에서 설명한 대로 대상 네트워크 네임스페이스에 있는 프로세스의 pid이거나 "설치"되어 처리되는 네트워크 네임스페이스일 수 있습니다 ip netns add NETNSNAME.

두 가지 일반적인 컨테이너 기술인 LXC와 Docker의 경우 NETNSNAME을 다음과 같은 대상 컨테이너로 바꾸는 방법은 다음과 같습니다 containername.

LXC:

ip link set eth0 netns $(lxc-info -H -p -n containername)

루스트어바웃:

ip link set eth0 netns $(docker inspect --format '{{.State.Pid}}' containername)

무선의 경우 (잘 문서화되지 않은) 명령은 다음과 명시적으로 연결된 무선 인터페이스가 하나만 있는 경우입니다 phy0.

iw phy phy0 set netns $(lxc-info -H -p -n containername)

그러나 이는 아래와 같이 드라이버가 지원하는 경우에만 작동합니다.

# iw phy0 info|grep netns
     * set_wiphy_netns

아마도수동으로 할 수 없습니다위 명령을 특정 컨테이너(LXC, Docker...)의 구성과 함께 사용하세요. 예를 들어, LXC 3.0(LXC 2.x에서 구문이 변경됨)의 경우 구성 파일에는 다음 줄이 포함됩니다.

lxc.net.1.type = phys
lxc.net.1.link = eth0

동일한 구성으로 이더넷이나 무선을 처리합니다.

그리고 컨테이너가 시작될 때마다 인터페이스는 컨테이너에 의해 흡수됩니다. 컨테이너(보다 정확하게는 해당 네트워크 네임스페이스)가 중지되면 인터페이스가 호스트로 반환됩니다(다른 컨테이너로 직접 반환될 수 없음).

설명일부 사용 사례.

Answer