bridge между двумя vlan

Ты хочешь трафик между разными подсетями гонять через bridge? Не выйдет.

auto eth2
allow-hotplug eth2

Так делать нельзя.

Да, я хочу чтоб одна тачка была связующей для тачек в разных подсетях. Как тогда сделать?

Нужно vlan1 и vlan2 объединить через мост или есть другой вариант (помимо правил в iptables)?

Не, нужно просто разрешить на этой тачке роутинг между этими сетями.

я хочу чтоб одна тачка была связующей для тачек в разных подсетях

А они через неё в сеть ходят или как-то еще? Чтобы она кого-то связывала, надо чтобы это кто-то знал о её существовании (default gateway).

Было бы более убедительно, если кидать ссылки на какие-то доки, а не на свой же коммент.

Включаешь net.ipv4.ip_forward=1 и указываешь тачку в качестве маршрута к подсети 192.18.1.0/24 на машинах из 192.18.2.0/24 и наоборот. Ну и в iptables не забудь разрешить forward трафик между подсетями.

Включаешь net.ipv4.ip_forward=1 и указываешь тачку в качестве маршрута к подсети 192.18.1.0/24 на машинах из 192.18.2.0/24 и наоборот. Ну и в iptables не забудь разрешить forward трафик между подсетями.

Ну iptables для меня не открытие, спасибо. Я хотел каким-то другим способом это осуществить.

Так делать нельзя.

Емнип при allow-hotplug #iface писать auto #iface уже не нужно.

«Нельзя» или «не обязательно»?

https://wiki.debian.org/ru/NetworkConfiguration

...

Если Вы хотите использовать DHCP вам необходимо написать следующие:

    auto eth0
    allow-hotplug eth0
    iface eth0 inet dhcp

И там же ниже ещё много примеров с allow-hotplug+auto.

А они через неё в сеть ходят или как-то еще? Чтобы она кого-то связывала, надо чтобы это кто-то знал о её существовании (default gateway).

В vlan1 сидит БД, надо чтоб тачки из vlan2 ходили по ip к БД - брали и записывали данные.

iptables за передачу пакетов не отвечает, главное маршруты...

«Нельзя» или «не обязательно»?

Я не знаю когда это поменялось, но на Debian 9 и убунтах начиная с 16.04 это заканчивается вот так:

RTNETLINK answers: File exists

http://dragonflybsd.blogspot.ru/2013/10/debian-allow-hotplug-auto.html

if eth0 is allow-hotplug but not auto it will be started at boot when the hardware is found, or when the hardware is attached (eg USB) but not when /etc/init.d/networking is run, which only calls ifup -a.

Может вопрос неуместный: нельзя ли переложить эту функцию (роутить между vlan) на маршрутизатор?

Я просто поэтому и спрашивал:

А они через неё в сеть ходят или как-то еще?

Просто иначе придется добавлять маршруты до подсети к ней на всех клиентах в vlan.

Просто иначе придется добавлять маршруты до подсети к ней на всех клиентах в vlan.

Да, это звучит очень хреново. Короче, выше log4tmp это уже писал.

Вот с dhcp я этого даже не проверял, каюсь. Со статикой networking.service падает с ошибкой.

iptables за передачу пакетов не отвечает, главное маршруты...

Правильно, iptables отвечает за обработку пакетов. И чем больше правил обработки тем хуже это скажется на производительности

Осуществить передачу трафику между сетями другим способом, кроме как маршрутизацией между ними? Ну, socks-прокси можно.

Тебе по сути хватит таких правил:

iptables -A FORWARD -i eth1 -o eth2 -s 192.18.1.0/24 -d 192.18.2.0/24 -j ACCEPT
iptables -A FORWARD -i eth2 -o eth1 -s 192.18.2.0/24 -d 192.18.1.0/24 -j ACCEPT

это звучит очень хреново

чтобы хост из лан1 мог отправить пакет хосту в лан2 и получить ответ, у него должна быть запись в таблице маршрутизации или он кинет его в default gateway.

Все.

чтобы хост из лан1 мог отправить пакет хосту в лан2 и получить ответ, у него должна быть запись в таблице маршрутизации или он кинет его в default gateway.

Или gefgw должен содержать запись и тогда отправит редирект на нужный gw. Что менее правильно, но тоже в бОльшей мере работает. Но клиент может и не принять redirect.

В vlan1 сидит БД, надо чтоб тачки из vlan2 ходили по ip к БД - брали и записывали данные.

Если в таком варианте, еще костыль в виде dnat snat. Но реально костыль. Лучше все решить роутингом.

Если в таком варианте, еще костыль в виде dnat snat. Но реально костыль.

Ну это через правила iptables и получится очень ущемлённо, по сравнению с тем,что предложил log4tmp:

iptables -A FORWARD -i eth1 -o eth2 -s 192.18.1.0/24 -d 192.18.2.0/24 -j ACCEPT
iptables -A FORWARD -i eth2 -o eth1 -s 192.18.2.0/24 -d 192.18.1.0/24 -j ACCEPT

Вы не понимаете ? Это просто разрешение прохождения пакетов. Не более того. Предположим что у вас и так пустые цепочки, и полиси ACCEPT тогда эти правила не нужны. К роутингу и nat-у это не имеет никакого отношения.

Это просто разрешение прохождения пакетов.

Заработался и тупанул, каюсь, да, я понимаю, что это просто разрешение прохождения через цепочку форвард для таких-то исходящий/входящих интерфейсов и таких-то исходящих/входящих подсетей.

Правильно понимаю, что роутинг настройка идёт через

ip [ OPTIONS ] OBJECT { COMMAND | help }

Давайте схему сети, что бы нам тут не играть в вангу. Хотя поиграю и предположу что у сети 192.18.1.0/24 defgw не 192.18.1.10 Также у сети 192.18.2.0/24 defgw не 192.18.2.20
Если это так, то вам уже выше расписали, хосты в сети 192.18.1.0/24 должны знать на какой gw отправлять пакеты для сети 192.18.2.0/24 Тоже самое должно быть и в обратном направлении.

Хотя поиграю и предположу что у сети 192.18.1.0/24 defgw не 192.18.1.10 Также у сети 192.18.2.0/24 defgw не 192.18.2.20

Хотите сказать, что надо настраивать непосредственно сам vlan, а не тачки?

vlan в облаке и потому я могу задать ему gw

Хочу сказать, то что сказал «Давайте схему сети»
ЗЫ Ей богу, каникулы или просто весеннее обострение? В соседней теме такой же какир почту поднимает...

чем больше правил обработки тем хуже это скажется на производительности

У тебя там сколько тысяч правил что ты начал замечать просадку? ipset конечно придумали не дураки, но если у тебя правил до сотни(и среди них нет упоротых матчеров), то просадка производительности будет такая, что ты не заметишь. Если конечно не роутишь на тостере...