URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 96468
[ Назад ]

Исходное сообщение
"iptables и bridge "

Отправлено nikosd , 16-Фев-16 12:31 
Не могу  заставить  слушать сервис только с одного  из хвоста br  интерфейсов.
Есть  бридж  br1
из eth0 И eth1  на br1  привешен  10.0.0.1 ,  Физически eth0 И eth1 это два  разных vlan, но у них общая  адресация (10/8) . на машине  поднята Samba.   Надо чтобы   udp/tcp 137  проходили  на  самбу только с eth1. и пакеты  dport 137 не проникали  из vlan где eth0  во влан где  eth1
Вроде  для этого  есть  вот такая  конструкция
-A FORWARD -p udp -m physdev --physdev-in eth0 -m udp --dport 137 -j DROP
но они проходят (: -  с горя пихал в INPUT  , там тоже  не работает.

Может кто - то скажет что не так или даст строчку  для подобного.  

P.S.для дальнейшего, правильно ли понимаю что  -physdev-is-out  не позволяет указать к какому  бриджу вяжемся


Содержание

Сообщения в этом обсуждении
"iptables и bridge "
Отправлено Andrey Mitrofanov , 16-Фев-16 12:55 
> Есть  бридж  br1
> из eth0 И eth1  на br1
>Надо чтобы   udp/tcp 137  проходили
>  на  самбу только с eth1. и пакеты  dport
> 137 не проникали  из vlan где eth0  во влан
> где  eth1

Предлагаю избавиться от моста -- мешает ведь, да?


"iptables и bridge "
Отправлено nikosd , 16-Фев-16 13:00 
>> Есть  бридж  br1
>> из eth0 И eth1  на br1
>>Надо чтобы   udp/tcp 137  проходили
>>  на  самбу только с eth1. и пакеты  dport
>> 137 не проникали  из vlan где eth0  во влан
>> где  eth1
> Предлагаю избавиться от моста -- мешает ведь, да?

Увы  не пройдет:
нужна общая адресация, множество общих сервисов и заметное  число  (SAMBA как пример)  сервисов  которые должны быть доступны  только для  одного vlan. Пока я  это решил разделив бридж и  машину  с сервисами
-A FORWARD -m physdev --physdev-is-in   -p udp --dport 137 -j DROP
такое  работает, но это не красиво



"iptables и bridge "
Отправлено StreSS.t , 16-Фев-16 12:59 
iptables -A POSTROUTING -s 10.0.0.0/22 -d 10.0.0.0/22 -m physdev --physdev-in tap+ --physdev-out tap+ -j ACCEPT

Вот так точно фильтрует.

А вообще да, както странно br и два VLAN с одной и тойже сетью


"iptables и bridge "
Отправлено nikosd , 16-Фев-16 13:05 
Огромное  спасибо.
Мне  не понятно почему postrouting, но задача  решена.
> iptables -A POSTROUTING -s 10.0.0.0/22 -d 10.0.0.0/22 -m physdev --physdev-in tap+ --physdev-out
> tap+ -j ACCEPT
> Вот так точно фильтрует.
> А вообще да, както странно br и два VLAN с одной и
> тойже сетью

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


"iptables и bridge "
Отправлено PavelR , 17-Фев-16 09:23 
> Ну давайте  скажем что это не два влан, а два  
> корпуса в одном из которых сидят граждане не пользующиеся совсем полным
>  доверием.

с какой неизвестной у них общая адресация? серых сетей не хватило?


"iptables и bridge "
Отправлено nikosd , 17-Фев-16 09:29 
>> Ну давайте  скажем что это не два влан, а два
>> корпуса в одном из которых сидят граждане не пользующиеся совсем полным
>>  доверием.
> с какой неизвестной у них общая адресация? серых сетей не хватило?

Задачу решили, за что автору  ответа  спасибо ( а я виновен - плохо читал ман)
Вам хочется пофлеймить ?
коротко - так надо, то есть видимость на L2, условие задачи.  мнение  про известность переменных оставьте  себе.


"iptables и bridge "
Отправлено Pahanivo , 17-Фев-16 10:16 
бридж соединяет L2, VLAN - наоборот разделяет L2. Т.е. одновременно решаются взаимоисключающие задачи? Я все правильно понял?

"iptables и bridge "
Отправлено nikosd , 17-Фев-16 10:26 
> бридж соединяет L2, VLAN - наоборот разделяет L2. Т.е. одновременно решаются взаимоисключающие
> задачи? Я все правильно понял?

Ваше понимание  мне  без разницы. Я даже, для успокоения  не буду переписавать на коммутаторах vlan.  Это именно влан, так как один кусок  прокинут по  чужой сети  в отдельной  QQ, а второй  вланится для нормальной обработки Qos.  Тема к размышлению:  множество очень старого и сильно специального оборудования которое не понимает класслесс маршрутизацию.


"iptables и bridge "
Отправлено Pahanivo , 17-Фев-16 16:50 
> Ваше понимание  мне  без разницы. Я даже, для успокоения  
> не буду переписавать на коммутаторах vlan.  Это именно влан, так
> как один кусок  прокинут по  чужой сети  в
> отдельной  QQ, а второй  вланится для нормальной обработки Qos.

какой-то венеграт из терминов
>  Тема к размышлению:  множество очень старого и сильно специального
> оборудования которое не понимает класслесс маршрутизацию.

а ты не пробовал для маршрутизации использовать маршрутизаторы, а не коммутаторы и софтварные бриджи ... ну так, чисто по приколу ))


"iptables и bridge "
Отправлено nikosd , 17-Фев-16 17:19 
>> Ваше понимание  мне  без разницы. Я даже, для успокоения
>> не буду переписавать на коммутаторах vlan.  Это именно влан, так
>> как один кусок  прокинут по  чужой сети  в
>> отдельной  QQ, а второй  вланится для нормальной обработки Qos.
> какой-то венеграт из терминов
>>  Тема к размышлению:  множество очень старого и сильно специального
>> оборудования которое не понимает класслесс маршрутизацию.
> а ты не пробовал для маршрутизации использовать маршрутизаторы, а не коммутаторы и
> софтварные бриджи ... ну так, чисто по приколу ))

Вопрос  номер  раз:  а вЫ не пробовали  читать ?  
если так интересна тема: eth0 "физически местная сеть", по которой интересующая меня часть ходит во VLAN, по той простой причине, что в ней надо обеспечить QoS (нормально это делается только с метками 802.1q), eth1 -  объект с которым связь через сеть другого оператора, предоставляющего нам vlan  с поддержкой второго  тега (то есть мои  вланы  к тому  объекту это 8021ad).
Наличествует требование L2 видимости  между  обоими  сегментами, так как
-есть  5  специальных железок в сети ( датчики оборудования) которые  не понимают CIDR  маршрутизации, то есть  у них нет  понятия  сетевой маски,  а вот шлюз есть. (RFC 791), эти устройства  должны быть доступны  без переконфигурирования, которое делается dip переключателями, из обоих сетей (eth1 и eth2) а устройства вполне носимы и могут за день пару раз сменить офис туда и обратно.
-крайне желательно общий DCHP и  неизменность адреса  для сотрудников  которые  с ноутом  могут приехать на другой объект.
-крайне желательно ограничить доступ  к паре  сервисов  для удаленного офиса ( совсем и  напрочь) и не требовать пароля от сотрудников из домашнего офиса.
я знаю как это можно решить с портом  в мониторе в каждом офисе  и парой  же  роутеров, но решение  с бриджом более  экономное.


"iptables и bridge "
Отправлено Pahanivo , 17-Фев-16 21:13 
> -есть  5  специальных железок в сети ( датчики оборудования) которые
>  не понимают CIDR  маршрутизации, то есть  у них
> нет  понятия  сетевой маски,  а вот шлюз есть.

ну раз есть шлюз они таки умеют отличать куда гнать трафик - на шлюз или на хост внутри сети

> (RFC 791), эти устройства  должны быть доступны  без переконфигурирования,
> которое делается dip переключателями, из обоих сетей (eth1 и eth2) а
> устройства вполне носимы и могут за день пару раз сменить офис
> туда и обратно.

модель устройств?
> -крайне желательно общий DCHP и  неизменность адреса  для сотрудников  
> которые  с ноутом  могут приехать на другой объект.
> -крайне желательно ограничить доступ  к паре  сервисов  для удаленного
> офиса ( совсем и  напрочь) и не требовать пароля от
> сотрудников из домашнего офиса.

осталось придумать как "напрочь" делить сотрудников на своих и чужих если они могут перемещаться между каналами (офисами) и не требовать при этом авторизации (у вас локалка вообще без всяких авторизаций?! не паханое поле для первого попавшего криптера) - и менять скажем мак пуская по бороде дхцп и еже с ним.
> я знаю как это можно решить с портом  в мониторе в
> каждом офисе  и парой  же  роутеров, но решение
>  с бриджом более  экономное.

причем тут мониторы? )))


"iptables и bridge "
Отправлено nikosd , 18-Фев-16 00:14 
>[оверквотинг удален]
>> сотрудников из домашнего офиса.
> осталось придумать как "напрочь" делить сотрудников на своих и чужих если они
> могут перемещаться между каналами (офисами) и не требовать при этом авторизации
> (у вас локалка вообще без всяких авторизаций?! не паханое поле для
> первого попавшего криптера) - и менять скажем мак пуская по бороде
> дхцп и еже с ним.
>> я знаю как это можно решить с портом  в мониторе в
>> каждом офисе  и парой  же  роутеров, но решение
>>  с бриджом более  экономное.
> причем тут мониторы? )))

Есть такая задача, бабочек ловить. Мне тут почиталось Вас на форуме, на иное ( ну кроме кривого совета по убийству Mysql ,причем явно основанного на идее essuport, которую тот показал полностью на hostobzor, вЫ не способны - цель  потешить эго).
Сеть построена именно так, авторизация по порту, так надо, о рисках есть докладная владельцу с записью "ознакомлен".
RFC дано, то есть железки от Экрика и сыны именно такие (анализаторы потоков)  ( а еще такие железки - модемы от RAD старые которые именно так думают о своем управлении).
Да сеть именно такая - всем кто прошел авторизацию по порту в главном офисе можно то, что нельзя остальным.  
Есть желание поспорить что эти железки в бою  и не могут обновлены  -  500$ на кон  за экскурсию, или с меня 500$, если я не смогу ее организовать, Место - Москва, требование к экскурсантам гражданство РФ или Белоруссии, судимости погашены или их нет, не было вообще судимостей по ст 272-274.  О том как выставить гарантии  договоримся  - сетевики вообще  узкий круг.

А если не знаете что такое monitor session, то не ловите  бабочек, это тоже требует некой тренировки и, главное, мозгов.  
P.S.  либо мы начинаем договариваться о гарантиях оплаты экскурса (и только о них), либо вЫ - пустофлеймер, то есть отвечать на вопросы  такого  мне  влом, а кнопку жалоба с  комментом "провокатор пустобрех" никто не отменял.


"iptables и bridge "
Отправлено Pahanivo , 18-Фев-16 06:50 
мой хрустальный шар рисует образы полузгнившей госконторы с притензиями на закрытость ...
и тучи рукожопов которые пытаются извлеч профит ))
а еще шар говорит что вам пора принять фенозипам ))

"iptables и bridge "
Отправлено Pahanivo , 17-Фев-16 10:21 
> с какой неизвестной у них общая адресация? серых сетей не хватило?

У меня давно есть подозрение, что "молодые спешыалисты" получают базовые знания по сетям по каким-то обрывкам хау-ту ... Или может у них какая тетрадь секретная, которая передается только из рук в руки членам братства ... в которой изложена альтернативная теория построения сетей.


"iptables и bridge "
Отправлено StreSS.t , 17-Фев-16 10:25 
Есть такая штука:
"Так истерически сложилось"
Например могло быть так:
Был один корпус. Потом появился второй корпус и его тупо добавили в сеть, но т.к. Vlan уже занят сделали другой. А сети у них оказались одинаковые. И делали это все винадмины.

И теперь пришел человек и ему нужно все это перелопатить за 1 секунду чтобы пользователи ничего не заметили. А там еще навернятка нашарено всякого гамна по самые уши.

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


"iptables и bridge "
Отправлено nikosd , 17-Фев-16 10:55 
>> с какой неизвестной у них общая адресация? серых сетей не хватило?
> У меня давно есть подозрение, что "молодые спешыалисты" получают базовые знания по
> сетям по каким-то обрывкам хау-ту ... Или может у них какая
> тетрадь секретная, которая передается только из рук в руки членам братства
> ... в которой изложена альтернативная теория построения сетей.

Флеймер:)
Так  надо, то есть  сделать без этого не тратя  кучу  денег работодателя  не получится. Да  и мне  заметно за  40, сетями занимаюсь уже лет 20. И мне  надоели старые  гуру( большей частью 23- 27 лет), которые говорят на требования процессов бизнеса "это нельзя сделать", хотя должны объяснить риски кривонетипового построения сети.


"iptables и bridge "
Отправлено Pahanivo , 17-Фев-16 16:56 
O_o