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

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

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

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

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

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

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

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

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

iface eth0 inet manual
iface eth1 inet manual

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

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

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

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

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

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. Или есть веская причина отойти от привычной схемы?

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

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

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

https://wiki.debian.org/NetworkConfiguration

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

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

Прописал:

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

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

Простите а что вы хотели получить? Вы собрали бриджем два интерфейса, вы хоть понимаете что такое бридж? По простому это просто провод в хабе/свиче. Т.е. вы втыкаете в свич два провода из сетей 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

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

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

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

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

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

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

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

В таком случаи так понимаю, что бридж не нужен. Он используется только для объединения двух интерфейсов в одной подсети, но с игнором 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

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

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

Это лишее оно у вас и так прописано. Начнем сначала. Я правильно понял что у компьютеров в сети 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.

Давай начнём с чистого листа и посмотрим вывод

ip a
ip r
ip ru
sysctl net.ipv4.ip_forward
iptables-save

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

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

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

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

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