Разделение сети

[zingel]

ну засунули бы в rc.d этот скрипт и не мучались бы, что касается private то я всетаки думаю что нужно разбить на подсети

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Nick_mad]

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

Ну харашо разобью на подсети два здания по 3 этажа в каждой фирме около 50 компов. Впадло все вручную переписавыть.
Потом что с настройками фаервола мне для обох подсетей писать правила?
ну и почта и сквид с прописаными правлилами кому куда можна а кому нильзя и когда. И опять все это переписывать.

Ну как то с мостом вроде проще показалось. Ну канешно это субективное мнение. ГУРУ естественно с ним могут не согласится

[zingel]

нет, не верно, хоть 5 тысяч миллиардов раз гуру, как Вам удобнее так и делайте.

[terminus]

теперь вплотную подошли до разделения сетей, тоесть фирм нежелающих видеть друг друга Мне чесно говоря интересно узнать о параметре sticky privat. Он что только в 7 используется? Может мне обновится до семерки и не мучать фаервол???

Блин - я не заметил. По-ходу в 6.3 уже есть этот функционал. Не надо ipfw...

http://www.freebsd.org/cgi/man.cgi?quer ... ormat=html

sticky interface
Mark an interface as a ``sticky'' interface. Dynamically learned
address entries are treated at static once entered into the
cache. Sticky entries are never aged out of the cache or
replaced, even if the address is seen on a different interface.

-sticky interface
Clear the ``sticky'' attribute on a member interface.

private interface
Mark an interface as a ``private'' interface. A private inter-
face does not forward any traffic to any other port that is also
a private interface.

-private interface
Clear the ``private'' attribute on a member interface.

Вот это должно будет отработать:

Код: Выделить всё

#!/bin/sh
ifconfig bridge0 create
ifconfig bridge0 addm rl1 addm rl2 up
ifconfig bridge0 sticky rl1
ifconfig bridge0 private rl1
ifconfig bridge0 sticky rl2
ifconfig bridge0 private rl2
ifconfig bridge0 inet 10.10.10.250 netmask 255.255.255.0
ifconfig rl1 up
ifconfig rl2 up

[Nick_mad]

как Вам удобнее так и делайте.

Ну я думаю что Вы со мной согласитесь что нужно делать правильно, а не как удобно. Мои познания в FreeBSD не настолько глубоки что бы адекватно в сложившейся ситуации принимать решения. Поэтому я попросил на форуме помощи. Был предложен вриант с внятным описанием, решающий проблему и не требующий лишних телодвижений по дополнительной настройке ПК конечных пользователей.
Возможно Вы знаете недостатки этого способа, или его неефективность, или, какие-нибудь, подводные камни, основываясь на собственном опыте, но Вы не затруднили себя их изложить. Но предложили другой способ решения проблемы не указав на его преимущества. Мне искренне хотелось бы узнать о недостатках первого и преимуществах второго. Так как я стремлюся сделать именно правильно, а не как удобно.

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

[zingel]

ясно, давайте тогда смотреть что у Вас на текущий момент есть:

[Nick_mad]

1. сеть 10.10.10.0/24
2. ее нада разделить на 2 физических сегмента.
3. так как это раньше была одна сеть (ну и пока есть) то и сервак один
4. один выход в нет
5. На серваке exim, squid, firewall, portfwd
вот вроде бы и все. нада шоб 2 физических сегмента не видели друг друга

добавлено

Сейчас есть мост он работает. Спасибо terminus

[zingel]

http://209.85.129.132/search?q=cache:RC ... clnk&gl=ru

тут описаны способы разбивания на подсети

[Nick_mad]

Из наблюдений.

Вроде после создания моста процес nat.d стал отедать 10% WCPU, тоесть возросла нагрузка на процесор. Вроде бы раньше такого не наблюдалось

[terminus]

А на каком интерфейсе у вас natd работает?
Если не секрет, покажите вывод ipfw show - или весь или хотя бы какие правила делают нат.

[bekhterev]

Нельзя делать такие вещи bridg'ом! Он как раз служит для объединения сетей на 2 уровне!!! Учите матчасть. Если хотите разделить - либо vlsm, либо vlan. vlsm подразумевает смену ip адресов, точнее адрес подсети, со всеми вытекающими. Елинственное, что могу посоветовать, так это если сети разделены закрыть их ваерволом друг от друга. А еще лучше изоляцией маршрутов (что сложнее).

[zingel]

какой vlsm, зачем? Если уж делать то вланы, ему просто нужно разбить сначала хоть

[terminus]

Нельзя делать такие вещи bridg'ом! Он как раз служит для объединения сетей на 2 уровне!!! Учите матчасть.

Вы прочитайте вводную:
Дано - у человека есть два здания; в каждом здании работает своя организация; В каждом здании локальная сеть; к FreeBSD серверу приходят два шнурка от каждой из сетей; сети физически разделены; в каждой организации по 50 компов со статическими настройками TCP/IP.
Задача - разделить их чтобы они не могли ходить друг к другу, но при этом, по позможности сохранить настройки TCP/IP на клиентских компах (чтобы руками перебивать не пришлось, и настройки сервисов менять не надо было).

Я конечно понимаю, что решение этой задачи на мосте который избирательно пропускает трафик между своими интерфейсами (Private interfaces) это "грязный хак", но оно отлично ложиться под условия задачи. Конечно, если человеку не лень/много времени то можно посоветовать ввести еще одну подсеть для второй организации, перебить настройки на клиентах (или сразу ввести DHCP), перенастроить фаервол, натд и сквид, запретить на фаерволе маршрутизацию между клиентскими интерфейсами и все такое прочее - не вопрос...

[bekhterev]

Нельзя делать такие вещи bridg'ом! Он как раз служит для объединения сетей на 2 уровне!!! Учите матчасть.

Вы прочитайте вводную:
Дано - у человека есть два здания; в каждом здании работает своя организация; В каждом здании локальная сеть; к FreeBSD серверу приходят два шнурка от каждой из сетей; сети физически разделены; в каждой организации по 50 компов со статическими настройками TCP/IP.
Задача - разделить их чтобы они не могли ходить друг к другу, но при этом, по позможности сохранить настройки TCP/IP на клиентских компах (чтобы руками перебивать не пришлось, и настройки сервисов менять не надо было).

Я конечно понимаю, что решение этой задачи на мосте который избирательно пропускает трафик между своими интерфейсами (Private interfaces) это "грязный хак", но оно отлично ложиться под условия задачи. Конечно, если человеку не лень/много времени то можно посоветовать ввести еще одну подсеть для второй организации, перебить настройки на клиентах (или сразу ввести DHCP), перенастроить фаервол, натд и сквид, запретить на фаерволе маршрутизацию между клиентскими интерфейсами и все такое прочее - не вопрос...

Тут в голову пришло гениальное решение!
Если ему нат поднять и с интерфейса другой сети кидать на интерфейс первой, таким образом сети не будут видеть друг друга

[zingel]

это не гениальное решение, а костыль, поделите на подсети и изолируйте маршруты силами вланов.

[bekhterev]

Это понятно, так и предлагалось, но в данном члучае уж лучше нат чем бридж, согласны?

[Nick_mad]

А на каком интерфейсе у вас natd работает?
Если не секрет, покажите вывод ipfw show - или весь или хотя бы какие правила делают нат.

Код: Выделить всё

##### Запускаем NAT ####
${fw} add divert natd all from ${innet} to any out via ${outif}
${fw} add divert natd all from any to ${outip} in via ${outif}
#

Хотя только что смотрел то 3-6%

[zingel]

в сети до бекбона с множеством неизвестных нат естественно хуже

[terminus]

Возможно, что указание клиентского интерфейса лишнее (избыточно).
Это:

Код: Выделить всё

${fw} add divert natd all from ${innet} to any out via ${outif}

в принципе можно было бы заменить на это:

Код: Выделить всё

${fw} add divert natd all from any to any out via ${outif}

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

Если же излишний overhead на обработке from bridbe0 не очень напрягает, то забыть и пусть живет, не?

[terminus]

Это понятно, так и предлагалось, но в данном члучае уж лучше нат чем бридж, согласны?

Мне если честно и самому интересно, что вы предлагаете. Если есть спортивный интерес - распишите пожалуйста всю топологию и шаги перехода.

[andrey262]

есть несколько предложений. в данном предложеном мной случае надо:
включить:

Код: Выделить всё

gateway_enable="YES"

создать loopback с ip шлюза (ну к примеру 10.1.1.1) сеть класса С 10.1.1.0/24
снять адрес с интерфейсов, смотрящих в лок сеть.
В данном случае сетевухи превращаются в свитч.
Далее мишем правило:

Код: Выделить всё

ipfw add skipto 500 from any via <card0> to any <not card1>
ipfw add skipto 500 from any via <card1> to any <not card0>
ipfw add skipto 8000 from any to any
ipfw add 500 divert natd from any to any via <ext_if>
ipfw add pass from any to any

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

[Nick_mad]

отчет о проделанной работе

Код: Выделить всё

#!/bin/sh
ifconfig bridge0 create
ifconfig bridge0 addm rl0 addm rl1 addm rl2 up
ifconfig bridge0 sticky rl0
ifconfig bridge0 private rl0
ifconfig bridge0 sticky rl1
ifconfig bridge0 private rl1
ifconfig bridge0 sticky rl2
ifconfig bridge0 private rl2
ifconfig bridge0 inet 10.10.10.250 netmask 255.255.255.0
ifconfig rl0 up
ifconfig rl1 up
ifconfig rl2 up

немного пришлось переиграть. внешнюю сеть перекинуть на другой интерфейс и пользуясь случаем подключить еще и третью сеть с теми же условиями что и 2 первые. За что выражается огромная благодарность за предложенное решение и помощь в его реализации terminus.
Все работает отлично, все условия поставленные в задании выполнены. Сети не видят друг друга, сервисы перенастраивать не пришлось ПК конечных пользователей тоже. Тоесть работы на выезде 20-30 мин с танцами и прочими делами. Еще хотелось бы узнать как поднять на интерфейсе скорость в 10baseTX, строка

Код: Выделить всё

ifconfig rl0 media 10baseTX up

не помогла у меня там сеть физически далеко и скорость больше 10 не подымается.

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

Тема не закрыта

[bekhterev]

Как же Вы можете считать остальные решения извратом, если не знакомы с теорией сетей. то что вы сделали в циске называется bridge-group и интерфейс bridge - BVI нужны они совершенно для других целей. Кстати, пакеты 2 уровня все таки смогут пробегать в данном случает. Я как раз описал решение с лупбеком, как рекомендуют все производители оборудования. а вообще сети и сервисы делить надо.

[terminus]

Кстати, пакеты 2 уровня все таки смогут пробегать в данном случает.

http://www.freebsd.org/cgi/man.cgi?quer ... ormat=html

private interface
Mark an interface as a ``private'' interface. A private inter-
face does not forward any traffic to any other port that is also
a private interface.

http://www.freebsd.org/doc/en_US.ISO885 ... dging.html

31.5.7.3 Private Interfaces

A private interface does not forward any traffic to any other port that is also a private interface. The traffic is blocked unconditionally so no Ethernet frames will be forwarded, including ARP. If traffic needs to be selectively blocked then a firewall should be used instead.

[terminus]

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

Тема не закрыта

zingel все правильно писал - "по-уму" так на самом деле не делают. Правильно делать так чтобы каждый клиент жил в своей IP сети (а как это реализовано, будь то физическое разделение или через vlan - это уже детали). соответственнов в вашем случае для реализации такой схеме надо менять настройки IP на клиентах.

Минусы сделаного нами решения на бридже:
- нестандартная конфигурация.
- необходимость помнить кому из клиентов какие IP назначены чтобы не дать два одинаковых IP машинам на разных портах бриджа.
- включение sticky interface приводит к необходимости обнулять кеш ARP записей, если в каком-нибудь клиентском компе поменяется MAC или IP.
- гипотетическая проблема захвата чужого IP, если кто-нибудь изловчиться и в момент рестарта сервера дернет себе IP из "соседней" сети.
- оверхед из-за программной реализации бриджа.

В общем это не эстетично, зато дешево, надежно и практично А главное по-быстрому.

---

Еще хотелось бы узнать как поднять на интерфейсе скорость в 10baseTX, строка

Код: Выделить всё

ifconfig rl0 media 10baseTX up

не помогла у меня там сеть физически далеко и скорость больше 10 не подымается.

http://www.freebsd.org/cgi/man.cgi?quer ... ormat=html

The rl driver supports the following media types:

autoselect Enable autoselection of the media type and options.
This is only supported if the PHY chip attached to
the RealTek controller supports NWAY autonegotia-
tion. The user can manually override the autose-
lected mode by adding media options to the
/etc/rc.conf file.

10baseT/UTP Set 10Mbps operation. The mediaopt option can also
be used to select either full-duplex or half-duplex
modes.

100baseTX Set 100Mbps (Fast Ethernet) operation. The
mediaopt option can also be used to select either
full-duplex or half-duplex modes.

The rl driver supports the following media options:

full-duplex Force full duplex operation

half-duplex Force half duplex operation.

Note that the 100baseTX media type is only available if supported by the
adapter. For more information on configuring this device, see
ifconfig(8).

Код: Выделить всё

# ifconfig rl0 media 10baseT/UTP mediaopt full-duplex