LINUX.ORG.RU
ФорумAdmin

Не удается создать мост на Debian.

 , , ,


2

1

Есть сервер Debian с двумя интерфейсами.

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static
        address 10.3.1.1
        netmask 255.255.255.0

allow-hotplug eth1
iface eth1 inet static
        address 10.3.5.1
        netmask 255.255.255.0
        gateway 10.3.5.3
        dns-nameservers 10.3.5.3

В /etc/sysctl.conf снят коммент с net.ipv4.ip_forward=1

Локальный компьютер сети 10.3.1.0 не пингует 10.3.5.1, хотя на нем в качестве шлюза прописан 10.3.1.1

При этом трафик внутри сервера свободно гуляет между интерфейсами. Пинги идут. 10.3.1.10 имеет интернет с маршрутизатора 10.3.5.3

Посчитал стоящим поставить в таком случаи мост и установил bridge-utils.

Почитал http://xgu.ru/wiki/Linux_Bridge

Отключил все интерфейсы и изменил их конфигурацию вот так:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 0.0.0.0

auto eth1
iface eth1 inet static
        address 0.0.0.0

auto br0
iface br0 inet static
bridge_ports eth0 eth1
address 10.3.1.1
netmask 255.255.255.0
network 10.3.1.0
broadcast 10.3.1.255

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

auto lo
iface lo inet loopback

Вношу в автозагрузку скрипт с темы https://forum.linux.by/viewtopic.php?f=3&t=9335

# Чистим настройки от предыдущего запуска скрипта
ifconfig br0 down # Отключаем интерфейс моста
ifconfig eth0 down # Отключаем сетевую карту eth0
ifconfig eth1 down # Отключаем сетевую карту eth1
brctl delbr br0 # Удаляем имя моста

# Запускаем бридж
brctl addbr br0 # Задаём имя бриджу
brctl addif br0 eth0 # Указываем какие интерфейсы 
brctl addif br0 eth1 # работают в режиме моста.

brctl stp br0 off # Отключаем режим STP
# brctl setfd br0 15 # Актуально только при
# brctl setageing br0 60 # использовании STP

# Задаём IP моста, для дальнейшего управления им через ssh
ifconfig br0 10.3.1.1 netmask 255.255.255.0 broadcast 10.3.1.255

# Удаляем IP сетевых карт
ifconfig eth0 0.0.0.0
ifconfig eth1 0.0.0.0

# Поднимаем интерфейсы сетевых карт и моста
ifconfig eth0 up
ifconfig eth1 up
ifconfig br0 up

Не поднялся eth1. Вместо UP стоит UNKNOWN. Поднятие через ifup не помогает.

eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master mybridge state UNKNOWN group default qlen 1000

На другом компе мне удалось создать рабочий NAT, только вот не думаю, что тут оно того стоит. Прошу помочь мне с решением данной проблемы. У меня стойкое ощущение, что я что-то элементарное упустил, но никак не могу взять в толк что это.

1. интерфейсы, участвующие в бридже, должны быть в manual
2. для форварда между разными сетями должен быть включен forward

это тёплое и мягкое, не смешивай

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

1. интерфейсы, участвующие в бридже, должны быть в manual

Про manual информацию в http://xgu.ru/wiki/Linux_Bridge и в https://wiki.archlinux.org/index.php/Iptables_(Русский) не обнаружил. В гугле тоже никакой конкретной инфы.

2. для форварда между разными сетями должен быть включен forward

net.ipv4.ip_forward включен. Шлюз отключен. До etc1 не достучаться. Что может быть не так?

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

1. интерфейсы, участвующие в бридже, должны быть в manual

Подтверждаю:

iface eth0 inet manual
iface eth1 inet manual

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

Был бы рад узнать отличие manual от statik. Подскажите пожалуйста хорошую статью. Хотя хотелось бы обойтись без шлюза, используя только форвард.

Так же в этой теме Настройка моста один из пользователей утверждает, что использует статик на интерфейсах. Значит ли это, что данная настройка интерфейса не критична при использовании шлюза?

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

Был бы рад узнать отличие manual от statik

static: предопределённый IP-адрес, manual: без IP-адреса (анонимное устройство/мост/...).

gag ★★★★★ ()

Изначальная настройка:

allow-hotplug eth1
iface eth1 inet static
        address 10.3.5.1
        netmask 255.255.255.0
        gateway 10.3.5.3
        dns-nameservers 10.3.5.3

Кстати: как правило, шлюз с dns заканчиваются на 1. Или есть веская причина отойти от привычной схемы?

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

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

Эмм... Ну, без шлюза можно обойтись только в одной подсети. Как только адрес чужой, пакет направляют в шлюз, который и есть для выхода в другую подсеть.

А форвард для того, чтобы пакет из одного шлюза пошёл не в нирвану, а если есть куда - то именно туда.

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

Такой IP маршрутизатору был выдан прошлым системным администратором. Не вижу смысла его менять. Главное не выдать такой же IP другому сетевому интерфейсу в этой сети.

puffiftik ()
Ответ на: комментарий от gag

Да, что-то затупил. Спасибо всем за пояснения. Сегодня вечером попробую вновь поднять шлюз. Отпишусь по результату.

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

Прописал:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto eth1
iface eth1 inet manual

auto br0
iface br0 inet static
bridge_ports eth0 eth1
address 10.3.1.1
netmask 255.255.255.0
network 10.3.1.0
broadcast 10.3.1.255

IP A утверждает, что все интерфейсы UP.

brctl show утверждает

bridge name     bridge id               STP enabled     interfaces
br0             8000.08606e7daef8       no                    eth0
                                                              eth1

При пинге маршрутизатора 10.3.5.3 выдает:

connect: Network is unreachable

Все это при включенном форварде. У меня печаль и непонимание, что я делаю не так.

puffiftik ()

Простите а что вы хотели получить? Вы собрали бриджем два интерфейса, вы хоть понимаете что такое бридж? По простому это просто провод в хабе/свиче. Т.е. вы втыкаете в свич два провода из сетей 10.3.1.0/24 и 10.3.5.0/24 какой результат получить хотим?

Локальный компьютер сети 10.3.1.0 не пингует 10.3.5.1, хотя на нем в качестве шлюза прописан 10.3.1.1

Смотрите что говорит tcpdump. Вангую или iptables или правила iproute2

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

Для полной картины было бы неплохо увидеть вывод route, а также настройки той пары ПК, что подключены к вот этому серверу.

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

По простому это просто провод в хабе/свиче.

ТС указал в топике:

В /etc/sysctl.conf снят коммент с net.ipv4.ip_forward=1

Так что это уже «не просто».

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

Так что это уже «не просто».

Роли не играет. ТС собрал бридж из двух реальных сетевок, на которых при этом хочет повесить разные подсети.

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

В таком случаи так понимаю, что бридж не нужен. Он используется только для объединения двух интерфейсов в одной подсети, но с игнором IP адресов. Значит мне стоит лишь настроить маршрутизацию, верно?

Если пропишу следующее, то будет ли трафик через сервер проходить в обе подсети?

route add -net 10.3.1.0 netmask 255.255.255.0 eth0
route add -net 10.3.5.0 netmask 255.255.255.0 eth1

Помню, что ранее проверял такое, но толку не было. Вроде вообще все отваливалось из-за этого, но надо перепроверить.

puffiftik ()
Ответ на: комментарий от gag

В следующий раз буду скидывать более подробную информацию.

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

Это лишее оно у вас и так прописано. Начнем сначала. Я правильно понял что у компьютеров в сети 10.3.1.0/24 шлиз по умолчанию 10.3.1.1 форвард включен но при этом из сети 10.3.1.0/24 не пингуется 10.3.5.1 ? Если да, то для начала проверьте настройки fw.
Второе. На компьютерах сети 10.3.5.0/24 шлюз по умолчанию 10.3.5.3. Для того что бы компы из сети 10.3.5.0/24 могли общаться с сетью 10.3.1.0/24 у них должен быть прописан роутиг на нее через 10.3.5.1.

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

Первое все верно и проверено. Насчет лишнего роутинга согласен, не так давно проверял route, они там присутствовали по умолчанию. Второе так и было сделано. Потому и хватаюсь за голову.

puffiftik ()
Ответ на: комментарий от zolden

Пожалуй действительно надо все с чистого листа рассматривать. Когда сервер освободится, то скину записи.

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

Очень интересно (я про первый пункт) но все таки это должен быть «слоненок» fw либо у клиента либо на сервере. Ведь по факту 5.1 этот тот же 3.1 т.е. второй пункт мы пока даже не рассматриваем (в нем могут и скорее будут подводные камни для виндовых машин в виде антивирей/виндового-fw)
Ждем инфы которую попросил zolden

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

Вот вывод.

root@proxy:~# 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 10:fe:ed:03:8f:ae brd ff:ff:ff:ff:ff:ff
    inet 10.3.1.1/24 brd 10.3.1.255 scope global eth0
    inet6 fe80::12fe:edff:fe03:8fae/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:60:6e:7d:ae:f8 brd ff:ff:ff:ff:ff:ff
    inet 10.3.5.1/24 brd 10.3.5.255 scope global eth1
    inet6 fe80::a60:6eff:fe7d:aef8/64 scope link
       valid_lft forever preferred_lft forever


root@proxy:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

root@proxy:~# ip r
default via 10.3.5.3 dev eth1
10.3.1.0/24 dev eth0  proto kernel  scope link  src 10.3.1.1
10.3.5.0/24 dev eth1  proto kernel  scope link  src 10.3.5.1

root@proxy:~# ip ru
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

root@proxy:~# iptables-save
# Generated by iptables-save v1.4.14 on Thu Sep  8 17:24:15 2016
*filter
:INPUT ACCEPT [15385:4097809]
:FORWARD ACCEPT [117:7403]
:OUTPUT ACCEPT [14213:4616881]
:fail2ban-PROXY - [0:0]
:fail2ban-ssh - [0:0]
:fail2ban-ssh-ddos - [0:0]
-A INPUT -j fail2ban-PROXY
-A INPUT -p tcp -m multiport --dports 2299 -j fail2ban-ssh-ddos
-A INPUT -p tcp -m multiport --dports 2299 -j fail2ban-ssh
-A fail2ban-PROXY -j RETURN
-A fail2ban-ssh -j RETURN
-A fail2ban-ssh-ddos -j RETURN
COMMIT
puffiftik ()
Ответ на: комментарий от puffiftik

«всё чудесатее и чудесатее» (с)
Предлагаю посмотреть tcpdump как на клиенте который из сети 3.0 пингует так и на сервере с 3.1, что бы понять где все-таки пакетики теряются.

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

В следующий раз сделаю дамп. Так же скину настройки клиентской машины, в прошлый раз забыл.

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