LINUX.ORG.RU
решено Форум — Admin  

Bridge OpenVZ контейнер

 , , ,


0

1

Не желая сетапать отдельное ядро на свой локалхост, надумал все сделать у виртуалбоксе с CentOS. CentOS получает интернет с использованием настроек Bridget Adapter к eth0:

http://www.zimagez.com/zimage/screenshot-130114-010354.php

Установил последнее ядро от OpenVZ и утилиты. Настроил бридж и теперь все так:

[root@centos conf]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:1b:39:80 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::a00:27ff:fe1b:3980/64 scope link 
       valid_lft forever preferred_lft forever
3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 08:00:27:1b:39:80 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.30/24 brd 192.168.1.255 scope global vmbr0
    inet6 fe80::a00:27ff:fe1b:3980/64 scope link 
       valid_lft forever preferred_lft forever
4: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/void 
    inet6 fe80::1/128 scope link 
       valid_lft forever preferred_lft forever
6: veth102.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link 
       valid_lft forever preferred_lft forever

[root@centos conf]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 vmbr0
169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 vmbr0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 vmbr0
[root@centos conf]#

Бридж настраивал как сдесь (Create a VETH Container):

http://openvz.org/Quick_Installation_CentOS_6

Захожу в контейнер (там тоже CentOS) и проверяю настройки:

[root@server102 /]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN 
    link/void 
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 00:18:51:a6:29:b0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.47/24 brd 192.168.1.255 scope global eth0
    inet6 fe80::218:51ff:fea6:29b0/64 scope link 
       valid_lft forever preferred_lft forever
[root@server102 /]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 eth0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
[root@server102 /]#

Т.е. вроде бы все верно, контейнер может пинговать хост машину, хост машина контейнер, но все отальные IP c той же сети не пингуются и выхода в Интеренет нет (а хотелось чтоб был):

[root@centos conf]# ping 192.168.1.47
PING 192.168.1.47 (192.168.1.47) 56(84) bytes of data.
64 bytes from 192.168.1.47: icmp_seq=1 ttl=64 time=0.039 ms
64 bytes from 192.168.1.47: icmp_seq=2 ttl=64 time=0.037 ms
64 bytes from 192.168.1.47: icmp_seq=3 ttl=64 time=0.038 ms
^C
--- 192.168.1.47 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2166ms
rtt min/avg/max/mdev = 0.037/0.038/0.039/0.000 ms


# ping 192.168.1.30
PING 192.168.1.30 (192.168.1.30) 56(84) bytes of data.
64 bytes from 192.168.1.30: icmp_seq=1 ttl=64 time=0.093 ms
64 bytes from 192.168.1.30: icmp_seq=2 ttl=64 time=0.043 ms
64 bytes from 192.168.1.30: icmp_seq=3 ttl=64 time=0.043 ms
^C
--- 192.168.1.30 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2087ms

Вопрос в том что я не так делаю? Посоветуйте что-либо или киньтесь маном. Спасибо!

★★★★★

Последнее исправление: ipeacocks (всего исправлений: 1)
← Локальная сеть
git.overlays.gentoo.org что с ним →

А arping-ом пинжится? Роутер из виртуалки и из контейнера. И физический хост так-же.

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

centos (192.168.1.30) - это хост-машина в Virtualbox, на котором стоит контейнер.

server102 (192.168.1.47) - сам контейнер. Это тоже CentOS.

192.168.1.41- физический хост в котором работает Virtualbox, а в нем уже CentOS.

192.168.1.1 - роутер.

С хост-машины centos в Virtualbox пингую роутер и физический хост (192.168.1.41): 

[root@centos ~]# arping -I vmbr0 192.168.1.1
ARPING 192.168.1.1 from 192.168.1.30 vmbr0
Unicast reply from 192.168.1.1 [CC:5D:4E:4E:4A:78]  1.638ms
Unicast reply from 192.168.1.1 [CC:5D:4E:4E:4A:78]  0.935ms
Unicast reply from 192.168.1.1 [CC:5D:4E:4E:4A:78]  0.923ms
Unicast reply from 192.168.1.1 [CC:5D:4E:4E:4A:78]  0.893ms
Unicast reply from 192.168.1.1 [CC:5D:4E:4E:4A:78]  0.910ms
^CSent 5 probes (1 broadcast(s))
Received 5 response(s)

[root@centos ~]# arping -I vmbr0 192.168.1.41
ARPING 192.168.1.41 from 192.168.1.30 vmbr0
Unicast reply from 192.168.1.41 [F4:6D:04:15:6F:60]  1.473ms
Unicast reply from 192.168.1.41 [F4:6D:04:15:6F:60]  0.670ms
Unicast reply from 192.168.1.41 [F4:6D:04:15:6F:60]  0.701ms
Unicast reply from 192.168.1.41 [F4:6D:04:15:6F:60]  0.675ms
Sent 4 probes (1 broadcast(s))
Received 4 response(s)
[root@centos ~]#

C контейнера server102: 

[root@server102 /]# arping -I eth0 192.168.1.41
ARPING 192.168.1.41 from 192.168.1.47 eth0
^CSent 5 probes (5 broadcast(s))
Received 0 response(s)
[root@server102 /]# arping -I eth0 192.168.1.30
ARPING 192.168.1.30 from 192.168.1.47 eth0
Unicast reply from 192.168.1.30 [08:00:27:1B:39:80]  0.606ms
Unicast reply from 192.168.1.30 [08:00:27:1B:39:80]  0.546ms
Unicast reply from 192.168.1.30 [08:00:27:1B:39:80]  0.545ms
Unicast reply from 192.168.1.30 [08:00:27:1B:39:80]  0.546ms
^CSent 4 probes (1 broadcast(s))
Received 4 response(s)
[root@server102 /]# 


[root@server102 /]# arping -I eth0 192.168.1.1 
ARPING 192.168.1.1 from 192.168.1.47 eth0
^CSent 53 probes (53 broadcast(s))
Received 0 response(s)
[root@server102 /]#

Спасибо.

ipeacocks ★★★★★
() автор топика
Последнее исправление: ipeacocks (всего исправлений: 2)
Ответ на: комментарий от ipeacocks

А arping -I vmbr0 192.168.1.47 с centos что говорит?
У меня идей, кроме неправильной конфигурации бриджей, нет. Разве-что ещё в etables на центосе заглянуть.

Ещё возможно есть смысл послушать tcpdump-ом что происходит в центосе и физическом компе при arping-е из контейнера. Уходят-ли пакеты на физический хост и приходят-ли на него.

Вообще в vbox сеть какая-то странная местами. Попробуй включить неразборчивый режим (promiscuous mode) в настроках сети в vbox или построить бридж на физической машине вручную (в vbox настраиваешь Host-only networking и дальше поднимаешь мост средствами линуха).

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

просто неясно это туплю я, или это из-за ограничений вбокса.

Спасибо за совет, я проверю.

ipeacocks ★★★★★
() автор топика
Ответ на: комментарий от MrClon

Хм, с контейнера на физический хост arping идет нормально:

[root@server102 /]# arping 192.168.1.41
ARPING 192.168.1.41 from 192.168.1.47 eth0
Unicast reply from 192.168.1.41 [F4:6D:04:15:6F:60]  1.431ms
Unicast reply from 192.168.1.41 [F4:6D:04:15:6F:60]  0.666ms
Unicast reply from 192.168.1.41 [F4:6D:04:15:6F:60]  0.757ms
Unicast reply from 192.168.1.41 [F4:6D:04:15:6F:60]  1.375ms
Unicast reply from 192.168.1.41 [F4:6D:04:15:6F:60]  0.835ms
Unicast reply from 192.168.1.41 [F4:6D:04:15:6F:60]  0.746ms
Unicast reply from 192.168.1.41 [F4:6D:04:15:6F:60]  0.683ms
Unicast reply from 192.168.1.41 [F4:6D:04:15:6F:60]  0.689ms
Unicast reply from 192.168.1.41 [F4:6D:04:15:6F:60]  0.685ms
Unicast reply from 192.168.1.41 [F4:6D:04:15:6F:60]  0.751ms
Unicast reply from 192.168.1.41 [F4:6D:04:15:6F:60]  0.686ms
^CSent 11 probes (1 broadcast(s))
Received 11 response(s)


root@homepc:~# tcpdump -n -nn -ttt src host 192.168.1.47
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:00:00.000000 ARP, Request who-has 192.168.1.41 (ff:ff:ff:ff:ff:ff) tell 192.168.1.47, length 28
00:00:00.000026 ARP, Request who-has 192.168.1.41 (ff:ff:ff:ff:ff:ff) tell 192.168.1.47, length 28
00:00:01.000419 ARP, Request who-has 192.168.1.41 (f4:6d:04:15:6f:60) tell 192.168.1.47, length 28
00:00:01.000432 ARP, Request who-has 192.168.1.41 (f4:6d:04:15:6f:60) tell 192.168.1.47, length 28

А вот с контейнера на centos довольно странно. Запросов производится довольно много:

[root@server102 /]# arping 192.168.1.30
ARPING 192.168.1.30 from 192.168.1.47 eth0
Unicast reply from 192.168.1.30 [08:00:27:1B:39:80]  1.372ms
Unicast reply from 192.168.1.30 [08:00:27:1B:39:80]  0.546ms
Unicast reply from 192.168.1.30 [08:00:27:1B:39:80]  0.547ms
Unicast reply from 192.168.1.30 [08:00:27:1B:39:80]  0.547ms
Unicast reply from 192.168.1.30 [08:00:27:1B:39:80]  0.546ms
Unicast reply from 192.168.1.30 [08:00:27:1B:39:80]  0.546ms
Unicast reply from 192.168.1.30 [08:00:27:1B:39:80]  0.546ms
^CSent 7 probes (1 broadcast(s))
Received 7 response(s)
[root@server102 /]#

А tcpdump ловит только один запрос:

[root@centos ~]# tcpdump -n -nn -ttt src host 192.168.1.47
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:00:00.000000 ARP, Request who-has 192.168.1.30 (ff:ff:ff:ff:ff:ff) tell 192.168.1.47, length 28
ipeacocks ★★★★★
() автор топика
Ответ на: комментарий от MrClon

Спасибо. Проблема была в iptables )

В контейнере забыл его стопнуть

ipeacocks ★★★★★
() автор топика
Последнее исправление: ipeacocks (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Локальная сеть
Admin
git.overlays.gentoo.org что с ним →