호스트가 브리지 장치에서 IP를 가져오지만 virt-manager 가상 머신은 IP를 가져오지 않습니다.

Question

도커 사용iptables이를 관리하는 컨테이너라이브러리 가상 머신그것도 사용하세요. 그러나 일반적으로 Docker는 다음 두 가지 이유로 동일한 시스템에서 실행되는 다른 네트워크 관련 도구와 잘 작동하지 않습니다.

도커 페이로드이것br_netfilter커널 모듈이것은 만든다브리지된프레임 순회iptables(그냥ebtables).
Docker도 설정합니다.iptables'기본 필터/FORWARD 정책은 DROP입니다.

Docker는 또한 체인의 정책 FORWARD을 DROP.Docker 호스트가 라우터 역할도 하는 경우 라우터가 더 이상 트래픽을 전달하지 않게 됩니다. 시스템이 계속해서 라우터 역할을 하도록 하려면 ACCEPT체인에 명시적인 규칙을 추가하여 DOCKER-USER이를 허용할 수 있습니다.

이들의 조합과 사실br_netfilter이것을 기본 동작으로 설정, Docker 관련 여부에 관계없이 시스템에 존재하는 모든 브리지는 기본 DROP 전달 정책을 상속합니다.iptables, 제외ebtables존재하는 경우에도 이 작업을 수행할 수 있습니다. 전달된 프레임은 모두 삭제됩니다.

그래서 모든 다리는 다음과 같이 만들어집니다.라이브러리 가상 머신영향을 받음: Docker 실행으로 인해 가상 머신이 격리됩니다. 위에서 언급한 것처럼 Docker에서 생성한 연결 규칙에 예외를 추가할 수 있습니다(그러나 실제로는 추가하는 것이 아니라 삽입해야 함) DOCKER-USER(원하는 경우 관리자가 먼저 생성할 수 있음). Docker는 항상 규칙을 먼저 삽입하기 때문에 체인에 규칙을 추가하는 것만으로 FORWARD는 충분하지 않을 수 있습니다 DOCKER-USER.

Docker가 아닌 브리지가 필터링되지 않도록 허용iptables, 다음 옵션 중 하나를 사용할 수 있습니다.

IP 주소로 전달이 허용되는 것과 일치합니다. 0.0.0.0, 255.255.255.255 등의 주소를 사용하는 것은 DHCP와 구별하기 어려우므로 반드시 추가해야 합니다. IP LAN 192.0.2.0/24의 경우:

iptables -N DOCKER-USER || true # doesn't matter if done before Docker or after (and thus already existing)
iptables -I DOCKER-USER -s 192.0.2.0/24 -d 192.0.2.0/24 -j ACCEPT
iptables -I DOCKER-USER -s 0.0.0.0/32 -d 255.255.255.255/32 -j ACCEPT

또는 Docker가 아닌 인터페이스를 통해 일치

docker0Docker 인터페이스는 항상 이름이 지정 되거나 이름 지정을 사용자 정의하지 않는 한 지정됩니다 br-.... 동일한 명명 규칙을 사용하지 말고 예외를 추가하십시오.

~에서iptables브리지 포트에서 전달된 브리지 프레임1번예를 들어가상 네트워크 0(가상 머신의 클릭 인터페이스)는 다음과 같이 렌더링됩니다.br0인터페이스: 브리지 포트를 볼 수 없으므로 패킷이 다음에서 오고 있습니다.br0그리고 앞으로br0.

순서가 중요합니다. 삽입 인덱스를 선언하면 아래 규칙이 추가된 것처럼(그러나 Docker가 마지막 규칙을 추가하기 때문에) -A삽입해야 하는 규칙의 자연스러운 순서가 유지됩니다.-j RETURN
```
iptables -N DOCKER-USER || true
iptables -I DOCKER-USER 1 -i docker0 -o docker0 -j RETURN
iptables -I DOCKER-USER 2 -i br-+ -o br-+ -j RETURN
```
허용 br0및 br1:
```
iptables -I DOCKER-USER 3 -i br0 -o br0 -j ACCEPT
iptables -I DOCKER-USER 4 -i br1 -o br1 -j ACCEPT
```
libvirt 및 LXC(또한 일반적인 피해자)의 다른 일반적인 이름으로 넘어가겠습니다.
```
iptables -I DOCKER-USER 5 -i virbr0 -o virbr0 -j ACCEPT
iptables -I DOCKER-USER 6 -i lxcbr0 -o lxcbr0 -j ACCEPT
```
아니면 다음으로 변경하세요.iptables결정을 내리기 위해 교량 정보를 얻으세요

좀 더 일반적인 것처럼 보이더라도 사용을 피해야 합니다.physdev일치 모듈은 br_netfilter커널 모듈이 아직 로드되지 않은 경우 작동하도록 로드하므로 Docker를 사용하지 않더라도 이 정보를 얻을 수 있으며 목표는 Docker 로딩으로부터 자신을 보호하는 것입니다 br_netfilter. 브리지된 프레임과 라우팅된 패킷(브리지를 라우팅 인터페이스로 사용하는 단일 라우팅 사용)을 구별할 수 있으므로 좀 더 강력합니다.

Docker는 자체 체인에서 자체 LAN 필터링을 수행하므로 Docker에는 여전히 예외가 필요합니다. Docker가 아닌 모든 것과 브리징(라우팅 아님)이 허용됩니다.
```
iptables -N DOCKER-USER || true
iptables -I DOCKER-USER 1 -i docker0 -o docker0 -j RETURN
iptables -I DOCKER-USER 2 -i br-+ -o br-+ -j RETURN
iptables -I DOCKER-USER 3 -m physdev --physdev-is-bridged -j ACCEPT
```

이전 옵션이 모든 가능한 상황에 적합하지 않을 수 있다는 점을 고려하세요.라이브러리 가상 머신FORWARD 체인에 있는 규칙은 제대로 작동하지 않거나 Docker 규칙에 의해 단락될 수 있습니다. 하지만냇이 경우 영향을 받는 규칙은 일반적으로 완전히 올바르게 처리될 수 있습니다.라이브러리 가상 머신(및 LXC).

가상 머신의 Docker

Docker를 다른 네트워킹 도구와 혼합하지 마십시오. 브리지가 있는 경우 Docker의 동작이 엉망이 됩니다. 반면에 적절하게 격리된 VM에서 Docker 자체를 실행하면 호스트나 호스트의 다른 VM 및 컨테이너(예: LXC)에 영향을 미치지 않습니다. 그런 다음 현재 호스트의 설정이 이미 허용하는 것처럼 이 VM 자체가 기본 네트워크에 브리지되는 경우 컨테이너에 도달하는 외부 설정은 크게 변경되지 않습니다. Docker는 물리적 LAN이 아닌 물리적 LAN에서 자체 별도의 IP 주소를 갖게 됩니다. 소유자의.
다른 가능성(커널 >= 5.3 필요)

br_netfilter다음을 보장하기 위해 미리 로드하세요 .시스템 제어설정을 사용할 수 있으며 시스템 전체 설정은 비활성화됩니다.iptables그리고:
```
modprobe br_netfilter
sysctl -w net.bridge.bridge-nf-call-iptables=0
```
선택한 Docker 브리지에서 이를 다시 활성화합니다(Docker 명령을 실행하여 이름을 검색하는 스크립트를 사용할 수도 있음).
```
ip link set dev docker0 type bridge nf_call_iptables 1
ip link set dev br-5039242381f0 type bridge nf_call_iptables 1
```
이 작업은 새로 생성된 각 브리지에 대해 수행되어야 합니다.

또 다른 방법은도커 안의 도커전역 설정만 비활성화된 컨테이너에서 자체적으로 실행됩니다(이 설정은 새 네트워크 네임스페이스에서는 여전히 기본적으로 활성화되어 있습니다...). 가상 머신에서 Docker를 실행하는 것에 비해 추가 관리 부담이 필요하기 때문에 이는 점점 더 어려워 보입니다.

저는 4를 선택하겠습니다. (가상 머신: 가능한 모든 Docker 간섭 방지) 또는 2. (간단하지만 충분합니다)

iptables참고: 위의 항목(포함)을 대체하면 ip6tables모든 것이 IPv6에서 작동합니다 sysctl. ~을 위한nftables이 통합을 살펴보세요nftables구체적인 답변대신에.

Answer 1