최신 정보:
나는 거기에서 해결책을 찾았다 :
http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge#No_traffic_gets_trough_.28except_ARP_and_STP.29
# cd /proc/sys/net/bridge
# ls
bridge-nf-call-arptables bridge-nf-call-iptables
bridge-nf-call-ip6tables bridge-nf-filter-vlan-tagged
# for f in bridge-nf-*; do echo 0 > $f; done
그러나 이것에 대한 전문가 의견을 갖고 싶습니다 : 모든 bridge-nf- *를 비활성화하는 것이 안전합니까? 그들은 무엇을 위해 여기 있습니까?
업데이트 종료
LXC 컨테이너를 호스트의 물리적 인터페이스 (eth0)에 연결하여 주제에 대한 많은 자습서, 문서 및 블로그 게시물을 읽습니다.
컨테이너에는 자체 공개 IP가 있어야합니다 (이전에 KVM / libvirt를 수행했습니다).
이틀 동안 검색하고 시도한 후에도 여전히 LXC 컨테이너에서 작동하지 않습니다.
호스트는 libvirt (여기서는 사용하지 않음)와 lxc 만 설치하여 새로 설치된 Ubuntu Server Quantal (12.10)을 실행합니다.
나는 다음과 같이 컨테이너를 만들었습니다.
lxc-create -t ubuntu -n mycontainer그래서 그들은 우분투 12.10도 실행합니다.
/ var / lib / lxc / mycontainer / config의 내용은 다음과 같습니다.
lxc.utsname = mycontainer
lxc.mount = /var/lib/lxc/test/fstab
lxc.rootfs = /var/lib/lxc/test/rootfs
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.name = eth0
lxc.network.veth.pair = vethmycontainer
lxc.network.ipv4 = 179.43.46.233
lxc.network.hwaddr= 02:00:00:86:5b:11
lxc.devttydir = lxc
lxc.tty = 4
lxc.pts = 1024
lxc.arch = amd64
lxc.cap.drop = sys_module mac_admin mac_override
lxc.pivotdir = lxc_putold
# uncomment the next line to run the container unconfined:
#lxc.aa_profile = unconfined
lxc.cgroup.devices.deny = a
# Allow any mknod (but not using the node)
lxc.cgroup.devices.allow = c *:* m
lxc.cgroup.devices.allow = b *:* m
# /dev/null and zero
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm
# consoles
lxc.cgroup.devices.allow = c 5:1 rwm
lxc.cgroup.devices.allow = c 5:0 rwm
#lxc.cgroup.devices.allow = c 4:0 rwm
#lxc.cgroup.devices.allow = c 4:1 rwm
# /dev/{,u}random
lxc.cgroup.devices.allow = c 1:9 rwm
lxc.cgroup.devices.allow = c 1:8 rwm
lxc.cgroup.devices.allow = c 136:* rwm
lxc.cgroup.devices.allow = c 5:2 rwm
# rtc
lxc.cgroup.devices.allow = c 254:0 rwm
#fuse
lxc.cgroup.devices.allow = c 10:229 rwm
#tun
lxc.cgroup.devices.allow = c 10:200 rwm
#full
lxc.cgroup.devices.allow = c 1:7 rwm
#hpet
lxc.cgroup.devices.allow = c 10:228 rwm
#kvm
lxc.cgroup.devices.allow = c 10:232 rwm
그런 다음 호스트 / etc / network / interfaces를 다음과 같이 변경했습니다.
auto lo
iface lo inet loopback
auto br0
iface br0 inet static
bridge_ports eth0
bridge_fd 0
address 92.281.86.226
netmask 255.255.255.0
network 92.281.86.0
broadcast 92.281.86.255
gateway 92.281.86.254
dns-nameservers 213.186.33.99
dns-search ovh.net
명령 줄 구성 ( “brctl addif”, “ifconfig eth0″등)을 시도하면 원격 호스트에 액세스 할 수 없으므로 하드 재부팅해야합니다.
/ var / lib / lxc / mycontainer / rootfs / etc / network / interfaces의 내용을 다음과 같이 변경했습니다.
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 179.43.46.233
netmask 255.255.255.255
broadcast 178.33.40.233
gateway 92.281.86.254
mycontainer를 시작하는 데 몇 분이 걸립니다 (lxc-start -n mycontainer).
나는 교체를 시도했다
gateway 92.281.86.254으로 :
post-up route add 92.281.86.254 dev eth0
post-up route add default gw 92.281.86.254
post-down route del 92.281.86.254 dev eth0
post-down route del default gw 92.281.86.254
그런 다음 컨테이너가 즉시 시작됩니다.
그러나 / var / lib / lxc / mycontainer / rootfs / etc / network / interfaces에 설정 한 구성에 상관없이 mycontainer에서 호스트를 포함한 모든 IP로 핑할 수 없습니다.
ubuntu@mycontainer:~$ ping 92.281.86.226
PING 92.281.86.226 (92.281.86.226) 56(84) bytes of data.
^C
--- 92.281.86.226 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5031ms
그리고 내 호스트는 컨테이너를 ping 할 수 없습니다.
root@host:~# ping 179.43.46.233
PING 179.43.46.233 (179.43.46.233) 56(84) bytes of data.
^C
--- 179.43.46.233 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4000ms
내 컨테이너의 ifconfig :
ubuntu@mycontainer:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 02:00:00:86:5b:11
inet addr:179.43.46.233 Bcast:255.255.255.255 Mask:0.0.0.0
inet6 addr: fe80::ff:fe79:5a31/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:64 errors:0 dropped:6 overruns:0 frame:0
TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4070 (4.0 KB) TX bytes:4168 (4.1 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:32 errors:0 dropped:0 overruns:0 frame:0
TX packets:32 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2496 (2.4 KB) TX bytes:2496 (2.4 KB)
내 호스트의 ifconfig :
root@host:~# ifconfig
br0 Link encap:Ethernet HWaddr 4c:72:b9:43:65:2b
inet addr:92.281.86.226 Bcast:91.121.67.255 Mask:255.255.255.0
inet6 addr: fe80::4e72:b9ff:fe43:652b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1453 errors:0 dropped:18 overruns:0 frame:0
TX packets:1630 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:145125 (145.1 KB) TX bytes:299943 (299.9 KB)
eth0 Link encap:Ethernet HWaddr 4c:72:b9:43:65:2b
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3178 errors:0 dropped:0 overruns:0 frame:0
TX packets:1637 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:298263 (298.2 KB) TX bytes:309167 (309.1 KB)
Interrupt:20 Memory:fe500000-fe520000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:300 (300.0 B) TX bytes:300 (300.0 B)
vethtest Link encap:Ethernet HWaddr fe:0d:7f:3e:70:88
inet6 addr: fe80::fc0d:7fff:fe3e:7088/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:54 errors:0 dropped:0 overruns:0 frame:0
TX packets:67 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4168 (4.1 KB) TX bytes:4250 (4.2 KB)
virbr0 Link encap:Ethernet HWaddr de:49:c5:66:cf:84
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lxcbr0을 비활성화했습니다 (/ etc / default / lxc에서 USE_LXC_BRIDGE = “false”).
root@host:~# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.4c72b943652b no eth0
vethtest
호스팅 공급자 (OVH) 구성 패널에서 IP 179.43.46.233이 02 : 00 : 00 : 86 : 5b : 11을 가리 키도록 구성했습니다.
(이 게시물의 IP는 실제 IP가 아닙니다.)
이 긴 질문을 읽어 주셔서 감사합니다! 🙂
비 아니
답변
변경 사항을 영구적으로 유지하는 더 좋은 방법은 / proc에 직접 쓰는 대신 sysctl을 사용하는 것입니다. 이는 다음 부팅시 커널 매개 변수가 올바르게 설정되도록 런타임에 커널 매개 변수를 구성하는 표준 방법이기 때문입니다.
# cat >> /etc/sysctl.d/99-bridge-nf-dont-pass.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0
EOF
# service procps start
업데이트의 질문에 대한 답변은 …
bridge-netfilter (또는 bridge-nf) 는 상태 저장 투명 방화벽에 대한 기능을 제공하지만 투명한 IP NAT와 같은 고급 기능은 IPv4 / IPv6 / ARP 패킷 (802.1Q VLAN 또는 PPPoE 헤더에서도 ) 에 대한 매우 간단한 브리지입니다. 추가 처리를 위해 해당 패킷을 arptables / iptables에 전달함으로써 제공되지만 arptables / iptables의 고급 기능이 필요하지 않더라도 해당 프로그램에 패킷 전달은 커널 모듈에서 기본적으로 켜져 있으며 명시 적으로 꺼야합니다 sysctl 사용
그들은 무엇을 위해 여기 있습니까? 이러한 커널 구성 옵션은 bridge-nf FAQ에 설명 된대로 arptables / iptables에 패킷을 전달 (1)하거나 전달하지 않습니다 (0) .
As of kernel version 2.6.1, there are three sysctl entries for bridge-nf behavioral control (they can be found under /proc/sys/net/bridge/):
bridge-nf-call-arptables - pass (1) or don't pass (0) bridged ARP traffic to arptables' FORWARD chain.
bridge-nf-call-iptables - pass (1) or don't pass (0) bridged IPv4 traffic to iptables' chains.
bridge-nf-call-ip6tables - pass (1) or don't pass (0) bridged IPv6 traffic to ip6tables' chains.
bridge-nf-filter-vlan-tagged - pass (1) or don't pass (0) bridged vlan-tagged ARP/IP traffic to arptables/iptables.
모든 bridge-nf- *를 비활성화하는 것이 안전합니까? 그렇습니다. 그렇게하는 것이 안전 할뿐만 아니라 사람들 이 발생한 문제에 대해 혼동 을 피할 수 있도록 배포판을 기본적 으로 해제 하는 것이 좋습니다 .
실제로, 이는 누군가가 다리를 만들고 일부 트래픽이 다리를 통해 전달되지 않는 것을 발견하면 심각한 혼란을 초래할 수 있습니다. IP 방화벽 규칙이 브리지의 프레임에 적용되는 것은 예상치 못한 일이므로 진행 상황을 파악하는 데 상당한 시간이 걸릴 수 있습니다.
그리고 보안 을 강화하기 위해 :
저는 여전히 가상화가있을 때 브리징의 위험이 더 높다고 생각합니다. 한 호스트에 두 개의 VM이 있고 각각 다른 브리지의 트래픽에 대해 전혀 알 필요가없는 전용 브리지가있는 시나리오를 고려하십시오.
브리징의 일부로 conntrack을 실행하면 이제 트래픽이 교차 할 수 있으며 이는 심각한 보안 허점입니다.
업데이트 : 2015 년 5 월
3.18보다 오래된 커널을 실행하는 경우 기본적으로 활성화 된 브리지 필터링의 이전 동작이 적용될 수 있습니다. 3.18보다 최신 버전 인 경우 브리지 모듈을로드하고 브리지 필터링을 비활성화하지 않은 경우 여전히 물릴 수 있습니다. 보다:
https://bugzilla.redhat.com/show_bug.cgi?id=634736#c44
이 몇 년 동안 브리지 필터링의 기본값을 “비활성화”하고 커널 관리자가 변경을 거부 한 후 브리지 모듈이로드 될 때 기본적으로로드되지 않은 별도의 모듈로 필터링이 이동되었습니다. 기본적으로 ‘비활성화 됨’으로 표시됩니다. 예이!
나는 이것이 3.17 현재 커널에 있다고 생각 합니다 (커널 3.18.7-200.fc21에 있고 태그 “v3.17-rc4″보다 git에있는 것처럼 보입니다)
답변
Debian Wheezy 하이퍼 바이저에서 비슷한 설정을 실행했습니다. 컨테이너의 rootfs 내에서 / etc / network / interfaces를 수정할 필요가 없었습니다. LXC 설정에서 lxc.network. *를 설정하면 충분합니다.
컨테이너를 실행 중인지 여부에 관계없이 브리징 작업을 수행 할 수 있어야합니다. 호스트의 / etc / network / interfaces에서 br0 아래에 다음 설정이 구성되어 있습니다.
% grep bridge /etc/network/interfaces
bridge_ports eth0
bridge_fd 0
bridge_stp off
bridge_waitport 0
bridge_maxwait 0
이를 구성하고 IP 주소 구성을 eth0에서 br0으로 이동 한 후 sudo service networking restartSSH 세션을 삭제하지 않고 호스트 시스템의 인터페이스를 투명하게 재구성했습니다.
완료되면 / etc / network / interfaces에서 ‘eth0’구성을 제거하고 컨테이너를 다시 시작하십시오.