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

OpenVZ. Проблема с сетью в контейнере

 , ,


0

1

Добрый день,

разбираюсь с openvz, есть 2 сервера: 1.Сервер OpenVZ

OS:CentOS 6.5 x86_64
eth0 смотрит в интернет
eth1 LAN 10.253.0.2
ip_forwarding включен
iptables все разрешено
в интернет ходит через внешний IP

2.Gateway

eth0 смотрит в инет
eth1=LAN 10.253.0.1
выступает в роли шлюза, для серверов без внешнего IP
DNS сервер

Создаю контейнер вот так:

[openvz]# vzctl create 110 --ostemplate centos-6-x86_64
[openvz]# vzctl set 110 --ipadd 10.253.0.3 --save
[openvz]# vzctl set 110 --nameserver 10.253.0.1 --save
[openvz]# vzctl start 110

Захожу в контейнер, LAN пингуется(шлюз и другие сервера в сети)

Интернет не пингуется. Пробовал руками прописать шлюз в контейнере:

route --add default gw 10.253.0.1
Не помогло.

Цель: нужен интернет в контейнере, не важно будет он через хостовую машину или через gateway. Что я не так делаю?



Последнее исправление: Funny_sailor (всего исправлений: 1)

А нат-то сделан на 10.253.0.1 ? Хотя, если остальная сеть работает... Вывод «ip r» и «ip a» в контейнере какой ? Дефолт там, по-умолчанию, venet0, этого должно быть достаточно.

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

Gateway работает, остальные сервера без проблем ходят, через него в инет.

Вот:

[root@container1 /]# 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,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/void 
    inet 127.0.0.1/32 scope host venet0
    inet 10.253.0.3/32 brd 10.253.0.3 scope global venet0:0

[root@ru2-srv-05 /]# ip r
169.254.0.0/16 dev venet0  scope link  metric 1002 
default dev venet0  scope link 

На другом сервере, с точно такой же конфигурацией и контейнером, но без внешнего интерфеса (ходит в инет через gateway) и там все работает. Подозреваю, что контейнер пытается ломиться через gateway провайдера.

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

127.0.0.1/32 на venet0 зачем ? Хотя, вероятно, это не мешает. Маршрут для 169.254.0.0/16 тоже лишний.

Подозреваю, что контейнер пытается ломиться через gateway провайдера.

Эта фраза непонятна: каким образом он там доступен ? Но tcpdump на интерфейсе хост-ситемы должен прояснить любые вопросы.

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

Решилось все проще, на хосте добавил:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Где-то читал, что в такой конфигруации сети, контейнеры как дефолтный гейтвей для себя используют дефолтный гейтвей хоста.

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

контейнеры как дефолтный гейтвей для себя используют дефолтный гейтвей хоста.

Вообще, если 10.253.0.1 с VPS-ки доступен действительно, можно и его использовать, по идее.

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

Если прохождение есть - то всё работает. Чтобы там появился интернет, необходимо на самом сервере или выходном роутере поднять nat на ip контейнера. Если nat'а нет, то и пакеты дальше(к провайдеру) не пройдут, так-как нету у него маршрута на данную подсеть. Если используется портокол динамической маршрутизации, то тагда всё пройдёт, и дальше уже вышестоящий хост(провайдер) будет решать натить его, или отбросить, или прогнать дальше в неизмкнённом виде.

Это небольшой бонус: Поднять NAT на Linux:

iptables -t nat -A POSTROUTING -s 10.253.0.0/16 -d 0.0.0.0/0 -j MASQUERADE
Прописать статик роут:
(вышестоящий сервер или роутер)
ip route add 10.253.0.0/16 via x.x.x.x dev XXXX
(где x.x.x.x ip вашего сервера, где XXXX - имя интерфейса, к которому подключён данный сервер.)

ne-vlezay ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.