☰

ipv4 전달로 인해 브리지와 veth가 중단됩니다.

tag-icon • tag-icon linux networking bridge veth
ipv4 전달로 인해 브리지와 veth가 중단됩니다.

나는 다음을 성공적으로 수행했습니다.

ip netns add quarantine
ip link add eth0-q type veth peer name veth-q
ip link add br0 type bridge
ip link set veth-q master br0
ip link set br0 up
ip link set veth-q up
ip link set eth0-q netns quarantine
ip netns exec quarantine ip link set lo up
ip netns exec quarantine ip link set eth0-q up
ip netns exec quarantine ip address add 192.168.66.5/24 dev eth0-q
ip netns exec quarantine dnsmasq --interface=eth0-q --dhcp-range=192.168.66.10,192.168.66.50,255.255.255.0
ip link set eno1 master br0

이를 통해 네트워크 관리자를 방해하지 않고 dnsmasq 인스턴스를 실행할 수 있으며 기본 이더넷 인터페이스(eno1)를 통해 연결된 장치가 192.168.66.0/24에서 IP를 얻도록 할 수 있습니다.

그런 다음 인터넷 액세스를 허용하기로 결정하고 다음과 같이 했습니다.

ip address add 192.168.66.1/24 dev br0

iptables -A FORWARD -i wlp58s0 -o br0 -m state  --state ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -o wlp58s0 -o br0 -j ACCEPT
iptables -A FORWARD -j LOG
iptables -t nat -A POSTROUTING -o wlp58s0 -j MASQUERADE

sysctl -w net.ipv4.ipforward=1
sysctl -p

그 중 wlp58s0은 우리 집 WiFi에 연결된 WiFi 인터페이스입니다. 또한 앞서 설명한 dnsmasq를 종료하고 다음으로 교체해야 했습니다.

ip netns exec quarantine dnsmasq --interface=eth0-q \
  --dhcp-range=192.168.66.10,192.168.66.50,255.255.255.0 \
  --dhcp-option=3,192.168.66.1 --dhcp-option=6,8.8.8.8

이렇게 하면 eno1을 통해 연결된 장치는 게이트웨이를 찾고 Google DNS 서버 8.8.8.8에 DNS 쿼리를 요청하는 방법을 알게 됩니다.

이 모든 것이 잘 작동했습니다. 컴퓨터를 다시 시작한 후 모든 구성이 예상대로 사라지고 모든 것이 잘 작동했습니다.

그러나 초기 시도에서는 패킷 전달을 활성화하기 위해 인터넷에서 찾은 조언을 따랐고 sysctl을 사용하는 대신 다음을 수행했습니다.

echo 1 > /proc/sys/net/ipv4/ip_forward

내 장치를 eno1(이미 IP가 있음)에 연결한 후 인터넷 액세스가 허용되었습니다.

그러나 내 컴퓨터를 다시 시작한 후에는 해당 IP 전달 설정이 지속됩니다. 그리고: 1을 쓴 곳에 0을 쓰는 것은 내구성이 없습니다. 더 나쁜 점은 초기 설정(인터넷 액세스 없음, IP 배포만)이 손상되어 eno1의 내 장치가 처음에 설명한 구성에서 더 이상 IP를 얻을 수 없다는 것입니다. 나는 Wireshark를 사용합니다. IP에 대한 요청은 br0에서 볼 수 있지만 veth-q에서는 사라지고 심지어 낯선 사람에게도 나타납니다. veth-q에서는 IPv6 트래픽만 볼 수 있고 ipv4 트래픽은 완전히 사라졌습니다. /proc/sys/net/ipv4/ip_forward에 0을 써서 IP 전달을 수동으로 비활성화해도 도움이 되지 않습니다. 마지막으로 Linux 배포판(Ubuntu)을 다시 설치하고 echo 명령을 더 이상 사용하지 않도록 주의했으며 sysctl을 사용하여 작업을 수행했는데 아무런 문제가 발생하지 않았습니다.

왜 이런 일이 발생합니까? 내 컴퓨터의 다른 모든 것이 잘 작동하는 것 같기 때문에 이것은 매우 이상하고 특이한 동작입니다. 인터넷에 액세스할 수 있고 모든 것이 정상으로 돌아온 것 같지만 브리지와 veth 사이의 상호 작용이 끊어졌습니다.

이에 대한 깨달음은 크게 감사하겠습니다!

답변1

따라서 내 초기 생각과 달리 /proc/sys/net/ipv4/ip_forward에 1을 쓰는 것은아니요질문.

문제는 도커에 있는 것 같습니다.

도커를 비활성화한 후 브리지와 가상 이더넷에서 보다 정상적인 동작을 관찰했습니다.

나는 이 답변의 주석에서 찾을 수 있는 모든 것을 쓸 예정입니다(보다 정확하게는 docker에서 문제를 일으킨 원인). 그러나 적어도 /proc/sys에 1을 수동으로 쓰는 것은 /net/ipv4/라고 안전하게 말할 수 있습니다. 문제를 ip_forward합니까? 이것이 기술적으로 내 문제를 해결한다고 생각합니다.

관련 정보