У меня ситуация такая: плоская сеть одна. Она вся подключена к роутеру тремя линками. Задача состоит в том, чтобы пустить интернет траффик от компьютеров которые находяться в пределах одного линка так, чтоб он не проходил через этот роут(там мониторинг и за раздачу интернета можно отхватить). Есть одна машина с 3 сетевыми интерфейсами,3 ип адреса, разные маки. Каждый сетевой интерфейс подключен к сети перед этим линком. На клиентских машинах прописан роут по умолчанию на адрес этой машини в пределах той сети что до линка. Все бы было хорошо, если бы оно нормально работало при заданной конфигурации в одной плоской сети. При одном включенном интерфейсе все работает нормально. Включаю все сразу начинают периодически пропадать на пару минут пинги по очереди на каждый из интерфейсов. Господа, подскожите в какую сторону копать?
>[оверквотинг удален]
> компьютеров которые находяться в пределах одного линка так, чтоб он не
> проходил через этот роут(там мониторинг и за раздачу интернета можно
> отхватить). Есть одна машина с 3 сетевыми интерфейсами,3 ип адреса, разные
> маки. Каждый сетевой интерфейс подключен к сети перед этим линком. На
> клиентских машинах прописан роут по умолчанию на адрес этой машини в
> пределах той сети что до линка. Все бы было хорошо, если
> бы оно нормально работало при заданной конфигурации в одной плоской сети.
> При одном включенном интерфейсе все работает нормально. Включаю все сразу начинают
> периодически пропадать на пару минут пинги по очереди на каждый из
> интерфейсов. Господа, подскожите в какую сторону копать?если у вас компьютеры из одной подсети, то через роутер ничего не идет.
>[оверквотинг удален]
> компьютеров которые находяться в пределах одного линка так, чтоб он не
> проходил через этот роут(там мониторинг и за раздачу интернета можно
> отхватить). Есть одна машина с 3 сетевыми интерфейсами,3 ип адреса, разные
> маки. Каждый сетевой интерфейс подключен к сети перед этим линком. На
> клиентских машинах прописан роут по умолчанию на адрес этой машини в
> пределах той сети что до линка. Все бы было хорошо, если
> бы оно нормально работало при заданной конфигурации в одной плоской сети.
> При одном включенном интерфейсе все работает нормально. Включаю все сразу начинают
> периодически пропадать на пару минут пинги по очереди на каждый из
> интерфейсов. Господа, подскожите в какую сторону копать?Не совсем понятна ситуация.
А копать в сторону "как устроен Ethernet" :)
... ну и о маршрутизации и адресации в IP сетях
Я вообще ничего не понял. Что ты имеешь в виду под "плоской сетью", "линком" и "роутом"?
Порой фантазия сетестроителей превосходит самые смелые кошмары :)> У меня ситуация такая: плоская сеть одна. Она вся подключена к роутеру
> тремя линками.Я мог бы придумать такую конструкцию сети, в которой одна плоская сеть заводиться на роутер двумя, термя-n-ным количеством путей. Разные каналы, резервные, дублирующие с автоматическим переключением, сеть высокой надежности и так далее... напридумать можно много схем...
Но я искренне надеюсь что сеть о которой вы говорите подключена к роутеру непосредственно, физическими шнурками, и тогда представленное описание рождает в голове странные, не сказать страшные картины...Например в хаб втыкаются компьютеры из локальной сети, а потом вы воткнули в хаб три патчкорда, и завели эти патчкорды на роутер, у которого есть три интерфейса для локалки.
Или например картина маслом: у роутера есть три интерфейса для локалки, на каждый из этих интерфейсов приходит по одному шнурку от трех разных хабов, в каждом из этих хабов сидят свои компьютеры, но сетка на всех этих трех хабах - одна и та же. Треть адресов из этой единой сети приходятся на один хаб, треть на другой, треть на третий... Соответственно компьютеры из разных хабов друг-друга непосредственно не видят, а ходят друг к другу через роутер.
Меня даже передернуло когда я попытался представить это...
На самом деле, конечно, похожая картина может иметь место, но только в случае если подсети там только выглядят как одна сеть, а на самом деле -это подсети большой сети.
То есть когда мы большую подсеть разбиваем на несколько сегментов, и хотя глядя на адрес - мы можем видеть якобы одну большую сеть - на самом деле это РАЗНЫЕ сети. И сеть получается не плоской. Три нормальных подсети работающих через роутер.Или например такой вариант: роутер о котором идет речь -это на самом деле мыльница от длинка или зухеля. У такой мыльницы - есть около 4-х -5-ти портов для локалки. Эти порты по сути собой представляют свич.
И обмен пакетами между линками приходящими от трех разных хабов происходит в этом свиче.
В этом случае сеть действительно может быть плоской. И если мыльница достаточно интеллектуальная - то даже возможно логировать трафик.> Задача состоит в том, чтобы пустить интернет траффик от
> компьютеров которые находяться в пределах одного линка так,Пропустить КУДА? Между этими же самыми компьютерами? Ну так в плоской сети он и не проходит через роутер.
Или пропустить трафик от компьютеров из этого линка к компьютерам другого линка?
То есть у вас по сути три разных физических сети связь между которыми осуществляется через роутер? Эти сети имеют разную адресацию или единую?Тут опять же возникает вопрос: а откуда эти компьютеры получают тот интернет трафик который они собираются раздавать другим линкам? Через роутер? ну так он все равно запишет что потребление трафика возросло во сто крат...
>чтоб он не
> проходил через этот роут(там мониторинг и за раздачу интернета можно
> отхватить).
>Есть одна машина с 3 сетевыми интерфейсами,3 ип адреса, разные
> маки. Каждый сетевой интерфейс подключен к сети перед этим линком.Фраза "подключен к сети перед этим линком" - дает почву для таких бурных фантазий, что их даже интернет не стерпит...
Как это на самом деле физически выглядит?
> На клиентских машинах прописан роут по умолчанию на адрес этой машини в
> пределах той сети что до линка.
> Все бы было хорошо, если
> бы оно нормально работало при заданной конфигурации в одной плоской сети.Вы совершенно точно уверены, будто понимаете значение термина "плоская сеть"?
> При одном включенном интерфейсе все работает нормально.
Ну да.. одна сеть - один интерфейс. Иначе не бывает. Нет, бывает конечно, но сисадмины у которых случаются такие чудеса обычно не задерживаются даже до аванса не говоря уже о получке :)
> Включаю все сразу начинают
> периодически пропадать на пару минут пинги по очереди на каждый из
> интерфейсов. Господа, подскожите в какую сторону копать?Сменить работу? Ну зачем вам столько мучений? Дальше ведь будет только хуже..
Ослилил :)))) Заметил, что оупэннете часто советуют сменить работу. :)))) Фича местная ))
Ух! Фига-се, опус! Круто, но сердито...
>[оверквотинг удален]
>> бы оно нормально работало при заданной конфигурации в одной плоской сети.
> Вы совершенно точно уверены, будто понимаете значение термина "плоская сеть"?
>> При одном включенном интерфейсе все работает нормально.
> Ну да.. одна сеть - один интерфейс. Иначе не бывает. Нет, бывает
> конечно, но сисадмины у которых случаются такие чудеса обычно не задерживаются
> даже до аванса не говоря уже о получке :)
>> Включаю все сразу начинают
>> периодически пропадать на пару минут пинги по очереди на каждый из
>> интерфейсов. Господа, подскожите в какую сторону копать?
> Сменить работу? Ну зачем вам столько мучений? Дальше ведь будет только хуже..Я смотрю моя тема просто взбудоражила умы форумчан)). Извиняюсь что столь запутано обьяснил. Я понимаю что такое роутер и свич. Сейчас попробую перефразировать то что я написал.
Есть роутер, который на конкретных трех портах работает в режиме свича. И обьединяет 3 части плоской сети. () 10.10.1.0 mask 255.255.255.0> Или например картина маслом: у роутера есть три интерфейса для локалки, на каждый из тих
> интерфейсов приходит по одному шнурку от трех разных хабов, в каждом из этих хабов сидят > свои компьютеры, но сетка на всех этих трех хабах - одна и та же. Треть адресов из этой > единой сети приходятся на один хаб, треть на другой, треть на третий... Соответственно
> компьютеры из разных хабов друг-друга непосредственно не видят, а ходят друг к другу
> через роутер.Друг друга видят сеть не побита на вланы. Только видят через этот роутер, что в моем случае черевато.
Этот свич(роутер) штука умная и может анализировать поведение в сети, может делать срез траффика проходящего через него по вероятностному принципу, ну вобщем всячески смотречть что куда ходит. Моя задача стоит в том чтоб выпустить компьютеры из этих частей плоской сети в интернет в обход этого свича(роутера) через дефаулт роут которым являеться мой компьютер. чтоб не ставить 3 компьютера в каждой части подсети я протянул кабеля от одного компа и повесил на нем три адаптера, каждый из которых работает на свою часть подсети, таким образом что пакеты не проходят через тот умный свич.
На роутере кроме этих трех портов имеються несколько сетей там нет такой проблемы так как там одному физическому кабелю подходящему к роутеру соответствует одна плоская сеть.
На этих же 3 сетевых интерфейсах работающих в одной сети возникают какие то непонятные залипания. И пинг какой то странный как для компьютеров которые на одном свиче находяться фактически.(свич который просто обьединяет компьютеры плоской сети дальше этого умного свича(роутера))
> Пропустить КУДА? Между этими же самыми компьютерами? Ну так в плоской сети
> он и не проходит через роутер.
>К моему компьютеру с 3 интерфейсами на 4 интефейс по отдельному от этой страшной сети канало подходит интернет.
Я нигде не работаю системынм администратором. Просто вот захотелось повозиться с радиус системами биллингами и маршрутизациями, да и заработать на пиво, а тут врдруг понял что за это можно получить по голове(
>[оверквотинг удален]
>>> периодически пропадать на пару минут пинги по очереди на каждый из
>>> интерфейсов. Господа, подскожите в какую сторону копать?
>> Сменить работу? Ну зачем вам столько мучений? Дальше ведь будет только хуже..
> Я смотрю моя тема просто взбудоражила умы форумчан)). Извиняюсь что столь запутано
> обьяснил. Я понимаю что такое роутер и свич. Сейчас попробую перефразировать
> то что я написал.
> Есть роутер, который на конкретных трех портах работает в режиме свича. И
> обьединяет 3 части плоской сети. () 10.10.1.0 mask 255.255.255.0
> К моему компьютеру с 3 интерфейсами на 4 интефейс по отдельному от
> этой страшной сети канало подходит интернет.Если сеть одна - то перед вашим компьютером нужно поставить еще один свичь, воткнуть все три сегмента в свичь, а шнурок из свича воткнуть в один интерфейс вашего компа.
Таким образом в вашем компьютере должно быть две сетевых карты а не 4.
У вас это по всей вероятности выглядит так:сегмент --------ваш комп\
сегмент --------ваш комп ---выходящий шнурок----законныйроутерсети
сегмент --------ваш комп/Надо сделать так:
сегмент ---\
сегмент ----свич---ваш комп---выходящий шнурок----законныйроутерсети
сегмент ---/
>[оверквотинг удален]
> Таким образом в вашем компьютере должно быть две сетевых карты а не
> 4.
> У вас это по всей вероятности выглядит так:
> сегмент --------ваш комп\
> сегмент --------ваш комп ---выходящий шнурок----законныйроутерсети
> сегмент --------ваш комп/
> Надо сделать так:
> сегмент ---\
> сегмент ----свич---ваш комп---выходящий шнурок----законныйроутерсети
> сегмент ---/Еще раз, роутер работает на данных портах как свич.
Тогда получиться кольцоНа данный момент плохо но работает вот так
|---------------------------выходящий шнурок-----------(к свич х)
|
просто кусок сегмента(10.10.1.0/24)--------\
\
eth1 eth4(inet)
| |
|-просто кусок сегмента(10.10.1.0/24)-----------eth3-мой ком свич(x)(законныйроутерсети)
| eth2 (на трех конкретных портах работает как свич!
| | но может круто мониторить траффик)
| просто кусок сегмента (10.10.1.0/24)-----/
| |
| |---------------------------выходящий шнурок-------(к свич х)
|----------------------------------выходящий шнурок---------(к свич х)
Причем я не уверен что пакеты таки не пролетают через свич(роутер) по каким то причинам, как проанализировать еще не придумал
ps: оч много палочек, но я надеюсь теперь понятно что я пытаюсь построить
Хм...Да, если свич будет тупой - получится кольцо.
Ну тогда надо взять в качестве свича свичик покрупнее, с поддержкой вланов (достаточно чтобы он умел группировать порты), и сконфигурировать его так, чтобы сегменты через ваш свич не персекались.влан1 (порт сегмента1 - порт вашего компа)
влан2 (порт сегмента2 - порт вашего компа)
влан3 (порт сегмента3 - порт вашего компа)
передачи данных между сегментами в таком случае не произойдет. Между собой компьютеры сегментов будут общаться как и прежде через свичроутера.Альтернативное решение - портам eth1 eth2 eth3 выделить три разных айпишника из трех подсетей. То есть разбить общую /24 на сегменты. Ваш комп будет считать что это разные сети, и будет работать нормально. Но это решение несколько хуже, потому что разбить сеть возможно только на определенные куски, и часть адресов при этом будет "сьедена". Например при маске /26 у вас получится 4 сегмента по 62 хоста в каждом, что приведет к тому что часть реальных хостов может не попасть в ваше адресное пространство.
Так что свичик с port based vlan все таки лучше.
>[оверквотинг удален]
> сегментов будут общаться как и прежде через свичроутера.
> Альтернативное решение - портам eth1 eth2 eth3 выделить три разных айпишника из
> трех подсетей. То есть разбить общую /24 на сегменты. Ваш комп
> будет считать что это разные сети, и будет работать нормально. Но
> это решение несколько хуже, потому что разбить сеть возможно только на
> определенные куски, и часть адресов при этом будет "сьедена". Например при
> маске /26 у вас получится 4 сегмента по 62 хоста в
> каждом, что приведет к тому что часть реальных хостов может не
> попасть в ваше адресное пространство.
> Так что свичик с port based vlan все таки лучше.Хорошая идея насчет умного свича, следующий пост как я понял подсказал мне что можно этот же умный свич сделать прямо у меня на компьютере. Вот только в brctl я ничего не увидел пока про блокировку пересылки пакетов между портами ведь тогда точно выйдет кольцо. Может стоит еще раз перечитать STP.
Это у вас вот такая сеть что-ли получается?http://xmages.net/storage/10/1/0/7/d/upload/64a322c1.png
ROUTER - зло
NGW - вы, т.е. добро ))
BR - свитчиЕсли так, то чтобы трафик LAN и WAN не ходил через хитроумный роутер делайте из своего пк свитч с помощью пакета bridge-utils, в котром лежит утилита brctl, указывайте ваш новый шлюз на клиентах и вперёд, к iptables :-)
На хитрый роутер будет попадать трафик только в том случае, если на любой из бриджей попадает фрэйм с широковещательным или пока неизвестным ему адресом назначения, в остальных случаях фрэймы будут перенаправляться конкретно адресату и только ему, другие участники бриджа не будут их видеть, даже если их сетевые карты в режиме promisc. :)
пс
и не забудьте включить поддержку STP на вашем бридже с помощью всё той же brctl.
>[оверквотинг удален]
> котром лежит утилита brctl, указывайте ваш новый шлюз на клиентах и
> вперёд, к iptables :-)
> На хитрый роутер будет попадать трафик только в том случае, если на
> любой из бриджей попадает фрэйм с широковещательным или пока неизвестным ему
> адресом назначения, в остальных случаях фрэймы будут перенаправляться конкретно адресату
> и только ему, другие участники бриджа не будут их видеть, даже
> если их сетевые карты в режиме promisc. :)
> пс
> и не забудьте включить поддержку STP на вашем бридже с помощью всё
> той же brctl.Да Вы правильно поняли ситуацию. Спасибо за ответ, скорее всего это полностью то что мне нужно))
Почитал вот здесь http://linux.opennet.ru/base/net/linux_bridge.txt.html Тоесть Вы утверждаете что STP не даст закольцевать сеть на моем мосте? И еще одно. Каждый из моих интерфейсов в текущей конфигурации может выходить во внешнюю сеть через этот зло роутер, на каждом порту этого зло роутера таблица привязок ип и мак адреса. Можно ли себе представить выход во внешнюю сеть через вот это
ifconfig mybridge 10.10.1.5 netmask 255.255.255.0, и тогда как я понял на всех 3 портах зло роутера нужно будет попросить прописать один и тот же мак на ип 10.10.1.5 ??
> Каждый из моих интерфейсов в текущей конфигурации может выходить
> во внешнюю сеть через этот зло роутер, на каждом порту этого
> зло роутера таблица привязок ип и мак адреса. Можно ли себе
> представить выход во внешнюю сеть через вот это
> ifconfig mybridge 10.10.1.5 netmask 255.255.255.0, и тогда как я понял на всех
> 3 портах зло роутера нужно будет попросить прописать один и тот
> же мак на ип 10.10.1.5 ??Если будете выходить в инет строго с одной сетевухи, то да.
В настройках маршрутизации можно указать, через какой интерфейс идет defaultroute.А для фильтрования пакетов на уровне свича есть утилита с пошлым названием ebtables
http://ru.wikipedia.org/wiki/Ebtables
Тот же iptables, только для уровня L2 - мак адресов.
>[оверквотинг удален]
>> представить выход во внешнюю сеть через вот это
>> ifconfig mybridge 10.10.1.5 netmask 255.255.255.0, и тогда как я понял на всех
>> 3 портах зло роутера нужно будет попросить прописать один и тот
>> же мак на ип 10.10.1.5 ??
> Если будете выходить в инет строго с одной сетевухи, то да.
> В настройках маршрутизации можно указать, через какой интерфейс идет defaultroute.
> А для фильтрования пакетов на уровне свича есть утилита с пошлым названием
> ebtables
> http://ru.wikipedia.org/wiki/Ebtables
> Тот же iptables, только для уровня L2 - мак адресов.Спасибо
>[оверквотинг удален]
>>> ifconfig mybridge 10.10.1.5 netmask 255.255.255.0, и тогда как я понял на всех
>>> 3 портах зло роутера нужно будет попросить прописать один и тот
>>> же мак на ип 10.10.1.5 ??
>> Если будете выходить в инет строго с одной сетевухи, то да.
>> В настройках маршрутизации можно указать, через какой интерфейс идет defaultroute.
>> А для фильтрования пакетов на уровне свича есть утилита с пошлым названием
>> ebtables
>> http://ru.wikipedia.org/wiki/Ebtables
>> Тот же iptables, только для уровня L2 - мак адресов.
> СпасибоРезультаты тестирования этой ночью неутешительны. Связал 3 интерфейса в бридж как написано здесь http://linux.opennet.ru/base/net/linux_bridge.txt.html.
# ifconfig eth0 0.0.0.0
# ifconfig eth1 0.0.0.0
# brctl addbr br0
# brctl addif br0 eth0
# brctl addif br0 eth1
# ifconfig br0 10.10.1.5 netmask 255.255.255.0
# brctl stp br0 onВключил STP. В результате заткнулись куски подсети подведенные к умному свичу(роутеру) и через него в сеть они ходить не смогли, зато пробовали через меня зачем то, и тоже не смогли. Выключил STP. Сама сеть заработала. Я даже смог пинговать через бридж
ping -I br0 10.10.1.15.
Но 10.10.1.15 мой бридж пропинговать не смог( Вобщем плохо. Как представляет сеть на канальном уровне представляю слабо. В чем была проблема не знаю. Да, колец не было в обоих случаях. утилита iftop показывала нагрузку до мбита на мост.
> Включил STP.Неужели это проще покупки нормального свича?
>зато пробовали через меня зачем то, и тоже не смогли.Так это они правильно пробовали, вы же ещё шлюз не настроили, на первом этапе задача наладить стабильную работу локальной сети на канальном уровне, затем уже начнём раздавать интернеты )
Выключать STP вам нельзя потому, что у вас получается избыточная топология. Это повлечёт за собой сбои в работе таблиц коммутации свитчей и широковещательные штормы. Нужно настроить STP. Если вы хотите, чтобы весь LAN трафик ходил через вас, то настройте STP так, чтоб ваш бридж стал корневым, тогда он будет указывать остальным, какие порты блокировать, чтобы избежать проблем. Чисто теоретически если вы будете рут бриджем, то ваш бридж должен отдать указания блокировать два из трёх линков идущих к роутеру, тем самым избыточность будет устранена и сеть должна будет работать корректно.
При включении в сети с STP происходят выборы корневого бриджа. Так вот чтоб победить на выборах, советую вам установить параметр STP на вашем бридже:
brctl setbridgeprio br0 0
Это даст вам оооочень большое преимущество на выборах :) Фактически это аналогия наших реальных выборов :-)))))))
И подождите с минуту, пока у STP пройдут все тайминги, рут раздаст всем указания и все устройства войдут в свои режимы.
Затем отпишите как оно. ))) Вообще я не разбираюсь, мне самому интересно, чё будет )))))
И выложите сюда brctl showstp br0Свидетельством нормальной работы, должна быть возможность беспроблемно пинговать всё и вся. ))
Да нету в этой сети никого кто слушал бы рассылки STP :)
Человек включил STP на ЕДИНСТВЕННОМ устройстве. :)
> Да нету в этой сети никого кто слушал бы рассылки STP :)
> Человек включил STP на ЕДИНСТВЕННОМ устройстве. :)так STP не нуждается в слушателях в этом смысле; достаточно только, чтобы не было петлей или петли были замкнутыми хостом с поддержкой STP, то есть, от всех участников сети поддержки STP не требуется
А можно по подробнее, не представляю себе этого. В моём представлении если коммутатор знает формат BPDU значит он поддерживает STP, если нет, то соответственно даже его не поймёт. Поправьте, если ошибаюсь.
>[оверквотинг удален]
> brctl setbridgeprio br0 0
> Это даст вам оооочень большое преимущество на выборах :) Фактически это аналогия
> наших реальных выборов :-)))))))
> И подождите с минуту, пока у STP пройдут все тайминги, рут раздаст
> всем указания и все устройства войдут в свои режимы.
> Затем отпишите как оно. ))) Вообще я не разбираюсь, мне самому интересно,
> чё будет )))))
> И выложите сюда brctl showstp br0
> Свидетельством нормальной работы, должна быть возможность беспроблемно пинговать всё
> и вся. ))минутку. я уточнил у нашего администратора. что все свичи в этой сети тупые, те не поддерживают стп. да и зачем он мне в конце концов? я могу заблокировать пересылку пакетов между портами с помощью ебтаблес. конечная цель - наличие единого ип в разных частях сегмента, чтоб траффик адресованый мне не ходил через свич(роутер) который обьединяет части сегмента на своих портах. чтото вроде multihome прикладного уровня. можете обьяснить или дать ссылку на материал где обьяснено что значит присвоить ип адрес бриджу, а не как это делаеться. просто я никак не пойму чего я достигну когда оно таи заработает в данной конфигурации. еще, зачем мне пропускать прочий сетевой тркффик через себя? ведь то о чем вы говорите приведет именно к этому??
сорри за оффтоп, но идите купите книжку по сетям и почитайте в свободное время - не выносите людям мозг уже...
> минутку. я уточнил у нашего администратора. что все свичи в этой сети тупые, те не поддерживают стп.Минутку, я тут подумал... Нету современных свичей, настолько тупых, чтоб не поддерживали STP. Они будут просто неработоспособны в современных коммутируемых сетях. Это тупо.
>> минутку. я уточнил у нашего администратора. что все свичи в этой сети тупые, те не поддерживают стп.
> Минутку, я тут подумал... Нету современных свичей, настолько тупых, чтоб не поддерживали
> STP. Они будут просто неработоспособны в современных коммутируемых сетях. Это тупо.Мде?
http://market.yandex.ru/model.xml?modelid=923126&hid=91088&s...
http://market.yandex.ru/model.xml?hid=91088&modelid=923120&s...
Очень хорошие свичи.
В свое время в домосети держались куда лучше, чем D-Link.
Кстати - никогда не покупайте свичи/сетевухи/... D-Link.И не надо тут "ну это же неуправляемые свичи".
Это тоже современные свичи
Современные неуправляеме офисные свичи)
И тут речь как раз про сеть на таких свичах.
> минутку. я уточнил у нашего администратора. что все свичи в этой сети
> тупые, те не поддерживают стп.Вот.
Никого не слушайте, кто тут вам что-то будет говорить про настройку свичей.
Свичи неуправляемые => они ничего не понимают.
А вы двигались в правильном направлении.# ifconfig eth0 0.0.0.0
# ifconfig eth1 0.0.0.0
# brctl addbr br0
# brctl addif br0 eth0
# brctl addif br0 eth1
# ifconfig br0 10.10.1.5 netmask 255.255.255.0
# brctl stp br0 onТолько вы написали про 3 сетевухи, а команды сделали для двух.
Суть в чем - объединяете 3(!) сетевухи в логический свич.
У вас будет одно логическое устройство br0.
Ему назначаете айпишник.
Это логическое устройство доступно со всех интерфейсов, которые вы засунете в логический свич.
Про STP забудьте.
Итого получается что-то типа этого:ifconfig eth0 0.0.0.0 up
ifconfig eth1 0.0.0.0 up
ifconfig eth2 0.0.0.0 up
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
brctl addif br0 eth2
ifconfig br0 10.10.1.5 netmask 255.255.255.0А потом вам придется прописать правила ebtables для всех хостов.
Какому мак адресу разрешено дотукиваться до вас, и через какой интерфейс.
Суть в том, чтобы закрыть все (чтоб ваш комп не работал, как свитч).
И оставить только то, что нужно (чтоб ходил трафик между вами и ими).
И уже от того, как вы настроите ebtables и будет зависеть - нормально будет работать ваша сеть, или ловить кольца.
Так что, с ebtables вам нужно будет 7 раз отмерить, а потом 3 раза отрезать.
Остальное - фигня.
Я понял, что он же один в сети с поддержкой STP!Ладно, STP отменяется, чтобы спастись от дублирования ответов, ежесекундного переписывания номеров портов на коммутаторах, нужно тогда я думаю... думаю... Нужно запрещать приём ethernet-броадкастов на двух из трёх интерфейсах смотрящих в LAN у новоиспечённого сервера! Иначе проблем не избежать. И не нужно прописывать правила для всех хостов. Вот!
> Я понял, что он же один в сети с поддержкой STP!
> Ладно, STP отменяется, чтобы спастись от дублирования ответов, ежесекундного переписывания
> номеров портов на коммутаторах, нужно тогда я думаю... думаю... Нужно запрещать
> приём ethernet-броадкастов на двух из трёх интерфейсах смотрящих в LAN у
> новоиспечённого сервера! Иначе проблем не избежать. И не нужно прописывать правила
> для всех хостов. Вот!а что за коммутатор / маршрутизатор?
>> Я понял, что он же один в сети с поддержкой STP!
>> Ладно, STP отменяется, чтобы спастись от дублирования ответов, ежесекундного переписывания
>> номеров портов на коммутаторах, нужно тогда я думаю... думаю... Нужно запрещать
>> приём ethernet-броадкастов на двух из трёх интерфейсах смотрящих в LAN у
>> новоиспечённого сервера! Иначе проблем не избежать. И не нужно прописывать правила
>> для всех хостов. Вот!
> а что за коммутатор / маршрутизатор?Handmade. Bugs inside
>>> Я понял, что он же один в сети с поддержкой STP!
>>> Ладно, STP отменяется, чтобы спастись от дублирования ответов, ежесекундного переписывания
>>> номеров портов на коммутаторах, нужно тогда я думаю... думаю... Нужно запрещать
>>> приём ethernet-броадкастов на двух из трёх интерфейсах смотрящих в LAN у
>>> новоиспечённого сервера! Иначе проблем не избежать. И не нужно прописывать правила
>>> для всех хостов. Вот!
>> а что за коммутатор / маршрутизатор?
> handmadeда ладно. что бы такой как описано еще постараться надо, маршрутизатор с коммутатором в одной машине ручной работы.
>>>> Я понял, что он же один в сети с поддержкой STP!
>>>> Ладно, STP отменяется, чтобы спастись от дублирования ответов, ежесекундного переписывания
>>>> номеров портов на коммутаторах, нужно тогда я думаю... думаю... Нужно запрещать
>>>> приём ethernet-броадкастов на двух из трёх интерфейсах смотрящих в LAN у
>>>> новоиспечённого сервера! Иначе проблем не избежать. И не нужно прописывать правила
>>>> для всех хостов. Вот!
>>> а что за коммутатор / маршрутизатор?
>> handmade
> да ладно. что бы такой как описано еще постараться надо, маршрутизатор с
> коммутатором в одной машине ручной работы.ОС Debian Lenny 5.05
Железо:
Intel Celeron D 2.0
По части сети:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
01:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
01:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
01:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (LOM) Ethernet Controller (rev 81)2 интерфейса сейчас занимаються перекидыванием пакетов ip. 2 пытаюсь настроить как бридж так чтоб не ложилась сеть и люди могли пинговать бридж и бридж мог пинговать людей, пока только последнее.
>[оверквотинг удален]
> 10)
> 01:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev
> 10)
> 01:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev
> 10)
> 01:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (LOM) Ethernet Controller
> (rev 81)
> 2 интерфейса сейчас занимаються перекидыванием пакетов ip. 2 пытаюсь настроить как бридж
> так чтоб не ложилась сеть и люди могли пинговать бридж и
> бридж мог пинговать людей, пока только последнее.а зачем надо было набивать в машину карты, чтобы три из них как бридж (коммутатор) работали?
>[оверквотинг удален]
>> 10)
>> 01:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev
>> 10)
>> 01:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (LOM) Ethernet Controller
>> (rev 81)
>> 2 интерфейса сейчас занимаються перекидыванием пакетов ip. 2 пытаюсь настроить как бридж
>> так чтоб не ложилась сеть и люди могли пинговать бридж и
>> бридж мог пинговать людей, пока только последнее.
> а зачем надо было набивать в машину карты, чтобы три из них
> как бридж (коммутатор) работали?Там сверху написана конечная цель. Изначально все работало немного по-другому, потом оно много раз переделывалось и в итоге получилось вот это. Линукс система очень гибкая штука и поэтому я решил обойтись без какого то спец оборудования, мне кажеться что я обойдусь и этим.
>[оверквотинг удален]
>>> (rev 81)
>>> 2 интерфейса сейчас занимаються перекидыванием пакетов ip. 2 пытаюсь настроить как бридж
>>> так чтоб не ложилась сеть и люди могли пинговать бридж и
>>> бридж мог пинговать людей, пока только последнее.
>> а зачем надо было набивать в машину карты, чтобы три из них
>> как бридж (коммутатор) работали?
> Там сверху написана конечная цель. Изначально все работало немного по-другому, потом оно
> много раз переделывалось и в итоге получилось вот это. Линукс система
> очень гибкая штука и поэтому я решил обойтись без какого то
> спец оборудования, мне кажеться что я обойдусь и этим.Эта вот штука- http://dlink.ru/ru/products/1/763.html стоит 650 рублей
Похоже ваше время стоит намного дешевле.===
Коммутатор снабжен 8 портами 10/100 Мбит/с, один из которых является uplink-портом (8-й порт). Остальные семь портов являются изолированными. Т.е. в данном коммутаторе функция VLAN реализована в аппаратном виде: коммутатор поддерживает семь групп VLAN, каждая из которых включает один из изолированных портов коммутатора и восьмой порт. В результате информация от пользователей, подключенных к первым семи портам коммутатора, будет передаваться только на uplink-порт, ведущий к магистрали сети провайдера и далее в Интернет.
===Некоторые люди собирают такие устройства сами http://mcmcc.bat.ru/vlan/
"Честный" малопортовый свич с поддержкой порт-басед вланов (DIR-100) стоит около 900 рублей.
>[оверквотинг удален]
> Коммутатор снабжен 8 портами 10/100 Мбит/с, один из которых является uplink-портом (8-й
> порт). Остальные семь портов являются изолированными. Т.е. в данном коммутаторе функция
> VLAN реализована в аппаратном виде: коммутатор поддерживает семь групп VLAN, каждая
> из которых включает один из изолированных портов коммутатора и восьмой порт.
> В результате информация от пользователей, подключенных к первым семи портам коммутатора,
> будет передаваться только на uplink-порт, ведущий к магистрали сети провайдера и
> далее в Интернет.
> ===
> Некоторые люди собирают такие устройства сами http://mcmcc.bat.ru/vlan/
> "Честный" малопортовый свич с поддержкой порт-басед вланов (DIR-100) стоит около 900 рублей.1. Мое время стоит моих знаний.
2. Изменение текущей конфигурации сети будет стоять моих нервов.
>[оверквотинг удален]
>> VLAN реализована в аппаратном виде: коммутатор поддерживает семь групп VLAN, каждая
>> из которых включает один из изолированных портов коммутатора и восьмой порт.
>> В результате информация от пользователей, подключенных к первым семи портам коммутатора,
>> будет передаваться только на uplink-порт, ведущий к магистрали сети провайдера и
>> далее в Интернет.
>> ===
>> Некоторые люди собирают такие устройства сами http://mcmcc.bat.ru/vlan/
>> "Честный" малопортовый свич с поддержкой порт-басед вланов (DIR-100) стоит около 900 рублей.
> 1. Мое время стоит моих знаний.
> 2. Изменение текущей конфигурации сети будет стоять моих нервов.Ценность знаний - вещь относительная. Намного важнее научится правильно строить сети.
"Изменение текущей конфигурации" сети в случае использования аппаратного свича будет заключаться во втыкании трех линков в эту коробочку (вместо втыкания их в три сетевые карты компа), втыкании линка с компа (единственного!) в аплинк порт этой коробочки. ВСЕ!
Это решение:
1. Простое.
2. Прозрачное.
3. Эффективное.
Сеть строящаяся на иных принципах - заведомо неуправляема, с огромным количеством сложно-обнаружимых глюков и неочевидно решаемых проблемм.Что значит "простое" решение? Это означает, что эффект достигается минимальным количеством телодвижений. Например для решения вашей задачи, можно в качестве упражнения научиться писать самостоятельно операционные системы на ассемблере. и сказать "мое время- мои знания". Но это не будет иметь никакого отношения к решению задачи.
Что означает что решение "прозрачно"? Минимум компонент с минимумом необходимых связей. Решение должно быть ясно представимым. Вы должны понимать как работает схема. А например вам посоветовали включить STP - и вы включили.. и огребли проблемы. А дело в том, что ни вы, ни тот кто вам это посоветовал - как работает STP не понимает и в каких случаях его можно применять а в каких нет - не знают. То есть решение непрозрачно. С бриджем на сетевушках- примерно такая же проблема. Ограничение трансляции пакетов в файрволе не решит проблемы в комплексе. Не нужно делать на уровне фаайрвола то, что можно сделать на уровне технологии. Потому что настройка файрвола- это всегда ручная работа, и часто "творческая" что приводит к потенциальным проблемам. Если есть решение решающее ту же задачу на уровне технологии - следует выбрать его.
Что значит "эффективно"? Экономия времени, нервов и денег. Вам было сразу предложено решение наиболее эффективно решающее задачу.решающее задачу окончательно, далающее это без гемороя, без глюков.
Но дело конечно ваше :)
Я с удовольствием схожу за второй пачкой попкорна :)
>[оверквотинг удален]
> "Изменение текущей конфигурации" сети в случае использования аппаратного свича будет заключаться
> во втыкании трех линков в эту коробочку (вместо втыкания их в
> три сетевые карты компа), втыкании линка с компа (единственного!) в аплинк
> порт этой коробочки. ВСЕ!
> Это решение:
> 1. Простое.
> 2. Прозрачное.
> 3. Эффективное.
> Сеть строящаяся на иных принципах - заведомо неуправляема, с огромным количеством сложно-обнаружимых
> глюков и неочевидно решаемых проблемм.Я не претендую на место того кто строит нашу сеть, и пусть проблемы которые в ней возникают не по моей вине решает он.
Если вы имеете ввиду линки главного свича(роутера) то я не втыкаю их себе в комп, у меня бы были проблемы если бы я это сделал. Вот человек нарисовал http://xmages.net/storage/10/1/0/7/d/upload/64a322c1.png что кудя я втыкаю. Еще раз, я хочу дать людям интернет и остаться незамеченным в условиях конкретной сети.
Я еще верю в то что это реализуемо ценой малой крови и у меня все для этого есть. Идти на реконструкцию сети и брать на себя за это ответственность я не буду.
>[оверквотинг удален]
> Я не претендую на место того кто строит нашу сеть, и пусть
> проблемы которые в ней возникают не по моей вине решает он.
> Если вы имеете ввиду линки главного свича(роутера) то я не втыкаю их
> себе в комп, у меня бы были проблемы если бы
> я это сделал. Вот человек нарисовал http://xmages.net/storage/10/1/0/7/d/upload/64a322c1.png
> что кудя я втыкаю. Еще раз, я хочу дать людям интернет
> и остаться незамеченным в условиях конкретной сети.
> Я еще верю в то что это реализуемо ценой малой крови и
> у меня все для этого есть. Идти на реконструкцию сети и
> брать на себя за это ответственность я не буду.Вы говорите вообще что-то странное...
У вас в комп воткнуто три линка. Нужно выткнуть их из компа и воткнуть в коробочку с порт-басед вланами. Эта коробочка разрулит вашу проблему с бриджем на сетевых и перенастройкой файрвола. Они не понадобятся вообще. И один патчкорд свяжет ваш комп с этой коробочкой. Где тут реконструкция сети? Вы вообще о чем?
То есть если раньше три линка были воткнуты в ваш комп непосредственно, то я предлагаю между этими линками и вашим компьютером поставить коробочку с жестко заданными вланами или с настраиваемыми. Эта коробочка решит проблему агрегации трех линков в ваш один интерфейс. И гарантирует что пакеты между этими линками в коробочке не пересекаются.
Или вас пугает слово порт-басед вланы? Эти вланы существуют только внутри коробочки. пакеты выходящие из коробочки не тегированы вланом. Они служат исключительно для агрегации портов свича в группы и задания правил обмена пакетов между портами.
влан1 (порт сегмента1 - порт вашего компа)
влан2 (порт сегмента2 - порт вашего компа)
влан3 (порт сегмента3 - порт вашего компа)например в свич воткнуто 4 линка- три от сегментов и 1 от компа.. тогда например:
порт1 - от компа
порт2 - от сегмента 1
порт3 - от сегмента 2
порт4 - от сегмента 3в свиче делаются порт-басед вланы:
влан1 (порт2 - порт 1)
влан2 (порт3 - порт 1)
влан3 (порт4 - порт 1)Цена решения с жестко заданными вланами - 650 рублей.
Цена решения с возможность понастраивать самостоятельно - 900.
>Я не претендую на место того кто строит нашу сеть, и пусть проблемы которые в ней возникают не по моей вине решает он.Но вы же влезли в эту область. Либо вы будете делать все правильно, либо нет. Выбор за вами. Либо простые,прозрачные и эффективные решения, либо.. "как всегда"...
Странно слышать настолько пафосные рассуждения о стоимости времени и прозрачности решений от человека, который не знает как прямо перенаправить фрэймы с одного интерфейса на другой без отдельной железки с виланами и рекомендует в качестве решения покупать железо, да ещё и такого отвратительного качества.Более того, как виланы или перенаправление трафика вообще, решат проблему нескольких путей к хосту в топологии сети? Кстати расскажи для чего нужен STP? Очень интересно как ты себе это представляешь. ))) STP вообще, скорее всего, не нужен, есть же делинки за 600р. :)))))
С тем вариантом что ты предлагаешь, в той топологии что на рисунке, без STP и фильтрации, о которой говорил BSDшник, любой ARP-запрос начнёт широковещательный шторм. Выучи матчасть и man ebtables.
А тебе cloun +1 за правильное желание разобраться как функционируют сети начиная с канального уровня. Систему ты выбрал правильную, делай своё, учись и не давай промывать себе мозги всяким experienced админам.
>[оверквотинг удален]
> Более того, как виланы или перенаправление трафика вообще, решат проблему нескольких путей
> к хосту в топологии сети? Кстати расскажи для чего нужен STP?
> Очень интересно как ты себе это представляешь. ))) STP вообще, скорее
> всего, не нужен, есть же делинки за 600р. :)))))
> С тем вариантом что ты предлагаешь, в той топологии что на рисунке,
> без STP и фильтрации, о которой говорил BSDшник, любой ARP-запрос начнёт
> широковещательный шторм. Выучи матчасть и man ebtables.
> А тебе cloun +1 за правильное желание разобраться как функционируют сети начиная
> с канального уровня. Систему ты выбрал правильную, делай своё, учись и
> не давай промывать себе мозги всяким experienced админам.Дети идут в сад. Широковещательного шторма там не будет. Максимум что будет - часть трафика возможно засветится на роутере.
Когда-нибудь тебе твой пафос и глупость аукнутся, дурашка. :)
> Когда-нибудь тебе твой пафос и глупость аукнутся, дурашка. :)Точно дите :))
>[оверквотинг удален]
>> к хосту в топологии сети? Кстати расскажи для чего нужен STP?
>> Очень интересно как ты себе это представляешь. ))) STP вообще, скорее
>> всего, не нужен, есть же делинки за 600р. :)))))
>> С тем вариантом что ты предлагаешь, в той топологии что на рисунке,
>> без STP и фильтрации, о которой говорил BSDшник, любой ARP-запрос начнёт
>> широковещательный шторм. Выучи матчасть и man ebtables.
>> А тебе cloun +1 за правильное желание разобраться как функционируют сети начиная
>> с канального уровня. Систему ты выбрал правильную, делай своё, учись и
>> не давай промывать себе мозги всяким experienced админам.
> Дети идут в сад.Друзья, ну что же вы..
С коробочкой идея интересная. Широковещательным арп запрос который отправит мой же единственный интерфейс размножиться на обьединяющем всех свиче(злом роутере) и закончиться на НЕ АПЛИНК портах этого влан свича, или нет? как он отреагирует на широковещательный пакет пришедший на НЕ АПЛИНК порт с адресом отправителя который на АПЛИНК порте и может гулять по всем НЕ АПЛИНК портам?? Square вы как знаток влан технологии должны знать ответ на этот вопрос. вариант: "хм, нада проверить" не катит.
>[оверквотинг удален]
>>> без STP и фильтрации, о которой говорил BSDшник, любой ARP-запрос начнёт
>>> широковещательный шторм. Выучи матчасть и man ebtables.
>>> А тебе cloun +1 за правильное желание разобраться как функционируют сети начиная
>>> с канального уровня. Систему ты выбрал правильную, делай своё, учись и
>>> не давай промывать себе мозги всяким experienced админам.
>> Дети идут в сад.
> Друзья, ну что же вы..
> С коробочкой идея интересная. Широковещательным арп запрос который отправит мой же единственный
> интерфейс размножиться на обьединяющем всех свиче(злом роутере) и закончиться на НЕ
> АПЛИНК портах этого влан свича, или нет?Да. Произойдет следующее:
Пакет с интерфейса компьютера будет размножен на коробочке с валнами на три не злых свича.
Незлые свичи размножат его по портам. при этом тот свич что обслуживает нужный адрес- отдаст нужный айпишник. Но будет еще два пакета пришедшие через злой роутер. при этом таблица нужного незлого свича будет снова переписана. и в сумме - в ответ на один арп-запрос придет три пакета. Последний пришедший пакет будет определять маршрут. А вот в какой последовательности они придут - зависит от генератора случайных чисел свичей и текущей загрузки каналов. Поэтому есть вероятность что часть трафика засветится на злом роутере.> как он отреагирует на
> широковещательный пакет пришедший на НЕ АПЛИНК порт с адресом отправителя который
> на АПЛИНК портеОн перешлет его только на аплинк порт, пакет дойдет до компьютера - и там умрет. В таблицу будет занесена запись (неправильная) которая будет перезаписана сразу же как только придет пакет с аплинк-порта. А он обязательно придет.
>[оверквотинг удален]
> придет три пакета. Последний пришедший пакет будет определять маршрут. А вот
> в какой последовательности они придут - зависит от генератора случайных чисел
> свичей и текущей загрузки каналов. Поэтому есть вероятность что часть трафика
> засветится на злом роутере.
>> как он отреагирует на
>> широковещательный пакет пришедший на НЕ АПЛИНК порт с адресом отправителя который
>> на АПЛИНК порте
> Он перешлет его только на аплинк порт, и там пакет умрет. В
> таблицу будет занесена запись (неправильная) которая будет перезаписана сразу же как
> только придет пакет с аплинк-порта. А он обязательно придет.Хотел уточнить что называеться палевом.
Провайдер раздает инет по pptp. Поэтому ip пакеты с мировыми адресами по сети в открытом виде не гуляют. Отсюда сразу палево откуда они взялись на злом свиче? я же хочу попробовать отказаться от всех обверток ip пакетов, тк с софтом который их заворачивает много возни. от того что человек не может запустить програмку, до того что сами по себе, почему то выключаються, а иногда и отказываються работать tap интерфейсы в винде(openvpn. ну и вообще винда зло). Отказаться и раздавать через дефаулт роут. Если удасться построить сеть в которой пакеты идущие ко мне с мировым адресом не будут попадать на злой свич то идея реализуема.дальше. человек который будет заниматься вычислением того, кто кроме законного провайдера поставляет интернет, будет следить за ненормальным поведением в сети. но скорее всего он не заметит что от моего интерфейса, который, кстати, являеться законным пользователем сети, приходит сразу по 3 арп запроса. странно ведь. но это мне кажеться мелочи ввиду того как вообще построена сеть. а вот мировой траффик это тривиальное палево.
насчет умирания пакета отправленного с аплинк порта и пришедшего на не аплинк порты не могу спорить, но мне кажеться разработчики врядли учли что вланы кроме этого влан свича обединяет с другой стороны еще один свич. хотя может и учли.>>Он перешлет его только на аплинк порт
очень спорно учитывая соурс адрес L2 пакета.
Кстати, ещё 3 варианта:
1. прокси (он переписывает ip адрес источника на ваш)
2. тупо маршрутизация(люди ставят ваш комп defaulroute)+nat(тоже будет переписывать ip адрес на ваш)
3. поднять vpn сервер. Он настривается куда проще, чем бридж и ebtables =) Клиенты будут подключаться к вам, а дальше см. пункт 2.
> Кстати, ещё 3 варианта:
> 1. прокси (он переписывает ip адрес источника на ваш)
> 2. тупо маршрутизация(люди ставят ваш комп defaulroute)+nat(тоже будет переписывать ip
> адрес на ваш)
> 3. поднять vpn сервер. Он настривается куда проще, чем бридж и ebtables
> =) Клиенты будут подключаться к вам, а дальше см. пункт 2.вроде с того что я выше написал должно быть ясно что я через впн сейчас раздаю. или вы так чтоб сказать? впн тоже вычисляеться очень просто. хотябы по большому количеству длительных подключений
> Кстати, ещё 3 варианта:
> 1. прокси (он переписывает ip адрес источника на ваш)
> 2. тупо маршрутизация(люди ставят ваш комп defaulroute)+nat(тоже будет переписывать ip
> адрес на ваш)
> 3. поднять vpn сервер. Он настривается куда проще, чем бридж и ebtables
> =) Клиенты будут подключаться к вам, а дальше см. пункт 2.Кстати тупо маршрутизация)) С туннеля пптп приходит пакет и я его разуваю меняю ему снатом адрес на адрес клиента и выпускаю в сеть. если человек не в моей части сегмента то все, пакет с мировым соурс адресом идет через зло свич. вижу вы не совсем поняли зачем я пытаюсь построить столь нестандартную вещь.
Твой трафик в любом случае засветится на зле. Конспирации не получится. Если вычислитель не слоу, он сразу всё просечёт.Без STP сети с избыточными топологиями вот так убого и работают.
попробуй всё ж без железа, с программной антилупической системой, даже если будет фэйл, то это будет бесплатно :)))))
LAN интерфейсы объединяются в бридж. WAN остаётся вне бриджа.
и для всех, кроме WAN пишем:ebtables -t nat -A POSTROUTING -o eth1 -s ! здесь мак бриджевого интерфейса -d broadcast -j DROP
ebtables -t nat -A POSTROUTING -o eth2 -s ! здесь мак бриджевого интерфейса -d broadcast -j DROP
ebtables -t nat -A POSTROUTING -o eth3 -s ! здесь мак бриджевого интерфейса -d broadcast -j DROPebtables -t nat -A PREROUTING -i eth1 -s здесь мак бриджевого интерфейса -d broadcast -j DROP
ebtables -t nat -A PREROUTING -i eth2 -s здесь мак бриджевого интерфейса -d broadcast -j DROP
ebtables -t nat -A PREROUTING -i eth3 -s здесь мак бриджевого интерфейса -d broadcast -j DROPКод проверенно работает. Его смысл в том, что мы не выпускаем ни чьи, кроме собственных броадкасты, но и не пускаем обратно свои броадкасты, пускаем только ответы на них, которые естественно уже уникасты.
лучше сначала напиши, а потом кабели :))
>[оверквотинг удален]
> ebtables -t nat -A PREROUTING -i eth1 -s здесь мак бриджевого интерфейса
> -d broadcast -j DROP
> ebtables -t nat -A PREROUTING -i eth2 -s здесь мак бриджевого интерфейса
> -d broadcast -j DROP
> ebtables -t nat -A PREROUTING -i eth3 -s здесь мак бриджевого интерфейса
> -d broadcast -j DROP
> Код проверенно работает. Его смысл в том, что мы не выпускаем ни
> чьи, кроме собственных броадкасты, но и не пускаем обратно свои броадкасты,
> пускаем только ответы на них, которые естественно уже уникасты.
> лучше сначала напиши, а потом кабели :))БОльшое спасибо, естественно я сначала перепробую все что можно сделать со своим тазиком, а когда захочеться пойти за топором, пойду куплю еще помучаю железку. Но думаю обойдеться без железки и топора. Я собственно уже почти додумал что нужно написать что то вроде того что вы написали. А есть какие то предостережения по поводу режимов в которых должна работать сетевая карта??
Неа, мои работали в режиме promisc, и всё было пучком.
> Неа, мои работали в режиме promisc, и всё было пучком.Сейчас все лягут спать и я поиздеваюсь малеха над сетью)) Надеюсь сработает;)
Только сразу говорю, из за суматохи в таблицах коммутации свитчей пинги иногда могут проходить не сразу и скорее всего будут со слегка повышенными временами. Такая хрень будет в любом случае и с делинком тоже.
> Только сразу говорю, из за суматохи в таблицах коммутации свитчей пинги иногда
> могут проходить не сразу и скорее всего будут со слегка повышенными
> временами. Такая хрень будет в любом случае и с делинком тоже.Так по вашему будет со всем сетевым траффиком или только с трафииком касающимся меня? Сеть у нас и так тяжело дышит(
Не со всем, только с тем трафиком, который идёт в другой сегмент (выходит за пределы одного коммутатора), внутри сегментов всё будет нормально. Я вообще не думаю, что эти накладки будут невыносимы, но тебе там на месте будет виднее. У меня были случаи, когда пинга приходилось ждать ~5с, думал его вообще нет, но так было редко, потом дальнейший обмен шел без проблем.
> Не со всем, только с тем трафиком, который идёт в другой сегмент
> (выходит за пределы одного коммутатора), внутри сегментов всё будет нормально. Я
> вообще не думаю, что эти накладки будут невыносимы, но тебе там
> на месте будет виднее. У меня были случаи, когда пинга приходилось
> ждать ~5с, думал его вообще нет, но так было редко, потом
> дальнейший обмен шел без проблем.Протестировал. Вы были правы насчет правил. Колец не получилось)) Я пингаю всех, и все пингают меня)) арп ходит отлично. БОльших ожидаемых пингов не наблюдалось.))
был замечен интересный факт. было так: br0 10.10.1.5 mask 255.255.255.0 mac 00:03:2A:E3:CA:B7 и один интерфейс eth3 10.10.1.6 mac 00:03:2A:E3:18:CE я для прикола оставил не в связке с бриджом.
в итоге на арпинг был получен такой вот забавный ответ
arping 10.10.1.5
00:03:2A:E3:CA:B7
00:03:2A:E3:18:CE
00:03:2A:E3:18:CE
00:03:2A:E3:18:CE
.
.
Непонято почему оно так работало конечно.Касательно конечной цели. Я так и не пойму. Бриджу присваиваеться мак который соответствует маку последнего добавленного в него устройства. Я арпингнул этот бридж только с одного куска сегмента там где находиться интерфейс с маком не соответствующим маку бриджа. ответ шел с маком бриджа. не могу понять устройство самого бриджа.
на время включения сетевых интерфейсов в бридж им всем присваиваеться одинаковый мак и то что показываеться в выводе ифконфига фигня(у интерфейсов включенных в бридж маки отличающиеся от мака бриджа) или же пакет пошел по длинному пути и у всех интерфейсов включенных в бридж маки таки разыне?
И вообще какое сходство бриджа с комутатором? он ведь не имеет мак адреса. такая конструкция как бридж перекидывает пакеты канального уровня как комутатор, а на пакеты с дестинейшн маком соответствующим маку этого бриджа реагирует как на пакеты уровня ип адресованные данному хосту?
может плохо искал но подходящих описаний на мой вопрос не нашел.
> был замечен интересный факт. было так: br0 10.10.1.5 mask 255.255.255.0 mac 00:03:2A:E3:CA:B7
> и один интерфейс eth3 10.10.1.6 mac 00:03:2A:E3:18:CE я для прикола оставил
> не в связке с бриджом.
> в итоге на арпинг был получен такой вот забавный ответ
> arping 10.10.1.5
> 00:03:2A:E3:CA:B7
> 00:03:2A:E3:18:CE
> 00:03:2A:E3:18:CE
> 00:03:2A:E3:18:CEБроадкаст фрэймы в твоей топологии могут попадать в одно и то же место несколькими разными путями, что постоянно и делают. Из-за этого свитчи постоянно переписывают свои таблицы коммутации потому, что сначала на них попадает фрэйм с одним сурс-маком с одного порта, потом фрэйм с тем же маком с другого, коммутатор думает " ??? Наверно они поменяли компы местами, исправлю-ка табличку " Поэтому фрэймы периодически попадают на разные интерфейсы доброго ПК. Причем перетасовка происходит только при следующем броадкаст фрэйме, уникасты до этого момента текут по последнему изменённому маршруту в таблицах коммутаторов. В данном случае копии одного и того же запроса по разным путям пришли на разные порты добрго ПК.
Сначала первый фрэйм правильно попал на тот самый бридж который и был нужен, бридж отослал ответ. Затем подлетели фрэймы с другого топологического пути на интерфейс который не в бридже, он распаковал из фрэйма IP-пакет и в IP виде, смаршрутизировал по своей таблице маршрутизации его бриджу, бридж в виде IP пакета на него ответил, ответ получил интерфейс запаковал во фрэйм пришлёпал свой мак, т.к. реально он будет отправителем и отправил в путь-дорогу.
После этого броадкастного приступа ПК записали в свои арп-кэши прямые маки получателей и шлют уже уникасты, которые, как я уже говорил потекут по последнему изменённому маршруту в таблицах коммутации свитчей, так будет до тех пор пока у кого-нить не устареет кэш и он не решит опять отправить броадкаст.
Так как фрэймы ходят разными путями в непредсказуемом порядке, твой инет 100%, рано или поздно, засветится на зле.
> Касательно конечной цели. Я так и не пойму. Бриджу присваиваеться мак который
> соответствует маку последнего добавленного в него устройства.у меня присваивается адрес первого добавленного интерфейса, не суть важно...
> Я арпингнул этот бридж
> только с одного куска сегмента там где находиться интерфейс с маком
> не соответствующим маку бриджа. ответ шел с маком бриджа. не могу
> понять устройство самого бриджа.Если интерфейс находится в бридже, он всегда использует мак и ip бриджа, вместо своего собственного. Нельзя, например, вешать IP-адрес на интерфейс в бридже. Можно давать его только самому бриджу.
> на время включения сетевых интерфейсов в бридж им всем присваиваеться одинаковый мак
> и то что показываеться в выводе ифконфига фигня(у интерфейсов включенных в
> бридж маки отличающиеся от мака бриджа) или же пакет пошел по
> длинному пути и у всех интерфейсов включенных в бридж маки таки
> разыне?Нет просто там в ifconfig показывается их реальный физический мак, а по сути они все используют один софтверный мак вот этого интерфейса бриджа, пока они включены в него, после роспуска, они опять используют свои настоящие маки.
> И вообще какое сходство бриджа с комутатором?
Бридж чисто технически это то же, что и коммутатор, но бриджем, как правило называют узел связывающий два-три интерфейса на канальном уровне, а коммутатором - узел связывающий много интерфейсов на канальном уровне. Это не правило, просто люди которых я знаю так говорят и мне их логика понятна :)) Ну и ещё по логике бриджем можно называть коммутатор соединяющий "сегменты", он вроде как мост между ними. А если он никого не соединяет он просто коммутатор и коммутирует там у себя только своих пользователей :)))))
> он ведь не имеет мак адреса.
Да, реальные неуправляемые свитчи не имеют ни мака, ни ip, но дело в том, что linux-bridge аналог управляемого коммутатора, который может иметь IP, управляться по веб-интерфейсу и прочие такие приятные примочки :) , и как следствие этого ещё и мак, потому что IP без мака не бывает. А если ты просто включишь все интерфейсы в базовый бридж без какой-либо настройки в результате получишь машину функционирующую как неуправляемый коммутатор :))))
> такая конструкция как бридж перекидывает пакеты канального уровня как комутатор, а на пакеты с дестинейшн маком соответствующим маку этого бриджа реагирует, как на пакеты уровня ип адресованные данному хосту?
Абсолютно верно. Передаёт их коду уже сетевого уровня.
Некоторое время наблюдаю за этой веткой, стало интересно до чего договорятся участники обсуждения.
решил таки высказаться по одному ньюансу:>> И вообще какое сходство бриджа с комутатором?
> Бридж чисто технически это то же, что и коммутатор, но бриджем, как
> правило называют узел связывающий два-три интерфейса на канальном уровне, а коммутатором
> - узел связывающий много интерфейсов на канальном уровне. Это не правило,
> просто люди которых я знаю так говорят и мне их логика
> понятна :)) Ну и ещё по логике бриджем можно называть коммутатор
> соединяющий "сегменты", он вроде как мост между ними. А если он
> никого не соединяет он просто коммутатор и коммутирует там у себя
> только своих пользователей :)))))"сегмент" - это вы тут имеете в виду подсеть IP-сети?
иначе если два свича соединяются через третий - получается не два сегмента соединены, а один сегмент получается. разрывает сегмент только маршрутиратор (если мы говорим об обычных свичах, не используя vlan и т.п.)так что коммутатор - это коммутатор, а мост - это мост.
мост соединяет два куска одного сегмента Ethernet и не разрывает этот сегмент.P.S. что касается собственно задачи, имхо - это выглядит как "возможность поизучать методом тыка". сам стараюсь избегать такие огороды городить, всё значительно проще можно организовывать, а значит меньше мест сбоев в такой сети.
Я знаю, что такое сегмент, и написал я это в кавычках. Мне показалось, что так будет выглядеть наглядней то, что я хочу сказать. Так как мы уже тут называли физические части сегмента сети сегментами. Я просто последовал традиции топика ) Щас я вижу что ошибался. )))) Мой ник сам за себя говорит :)>мост соединяет два куска одного сегмента Ethernet и не разрывает этот сегмент.
А коммутатор так никогда не делает. :)) Ваше утверждение вообще-то не противоречит тому, что я писал, если не учитывать неправильное слово "сегмент".
> Я знаю, что такое сегмент, и написал я это в кавычках. Мне
> показалось, что так будет выглядеть наглядней то, что я хочу сказать.
> Так как мы уже тут называли физические части сегмента сети
> сегментами. Я просто последовал традиции топика ) Щас я вижу что
> ошибался. )))) Мой ник сам за себя говорит :)
>>мост соединяет два куска одного сегмента Ethernet и не разрывает этот сегмент.
> А коммутатор так никогда не делает. :)) Ваше утверждение вообще-то не противоречит
> тому, что я писал, если не учитывать неправильное слово "сегмент".да, но мост не пересылает кадры на другую сторону, если МАС назначения находится на стороне источника. а свич поступает несколько иначе.
Немножко, не понял о чём вы... Чем отличается таблица коммутации свитча от таблицы коммутации бриджа? Что в понимании коммутатора и бриджа есть "сторона"?
> Немножко, не понял о чём вы... Чем отличается таблица коммутации свитча от
> таблицы коммутации бриджа? Что в понимании коммутатора и бриджа есть "сторона"?Я лишь хотел высказаться вот об этой выкладке:
"по логике бриджем можно называть коммутатор соединяющий "сегменты", он вроде как мост между ними"
не более :)Т.е. я против утверждения, что коммутатор можно назвать мостом, соединяющим сегменты.
Если под "сегментами" подразумеваются разные физические куски сети - то всё верно по сути.
Просто я часто сталкиваюсь с тем, что под "сегментом" понимают то физические куски одной сети, то разные подсети IP-сети, то ещё Бог знает что... потому, в общем и решил написать таки в этой ветке :) .
мост - это хост имеющий как минимум два интерфейса, смотрящие в разные части одного сегмента. соответсвенно - одна сторона и другая сторона моста.P.S. спорить не о чем :) если вы считаете что я напрасно пытался "уточнять" - значит так и есть :) не буду больше мешать обсуждению. :)
Мир. )) Я с вам спорить тоже вовсе не хотел. Не о чем. ;) Я уже признал свою ошибку. Не стоило называть физический кусок сети сегментом. :)
>[оверквотинг удален]
>> только своих пользователей :)))))
> "сегмент" - это вы тут имеете в виду подсеть IP-сети?
> иначе если два свича соединяются через третий - получается не два сегмента
> соединены, а один сегмент получается. разрывает сегмент только маршрутиратор (если мы
> говорим об обычных свичах, не используя vlan и т.п.)
> так что коммутатор - это коммутатор, а мост - это мост.
> мост соединяет два куска одного сегмента Ethernet и не разрывает этот сегмент.
> P.S. что касается собственно задачи, имхо - это выглядит как "возможность поизучать
> методом тыка". сам стараюсь избегать такие огороды городить, всё значительно проще
> можно организовывать, а значит меньше мест сбоев в такой сети.Я называю сегментом плоскую сеть. Касательно задачи да, тут многому можно научиться. Огород не городить не получиться так как его уже нагородили до меня. Ну вот почему нельзя было разными портам на злом роутере не дать разные подсети, а не делать с него свич? я не знаю, поэтому теперь самому приходиться опускаться до канального уровня и искать выходы если они есть. Благо добрые опытные люди мне в этом помогают))
>> Так как фрэймы ходят разными путями в непредсказуемом порядке, твой инет 100%, рано или поздно, засветится на зле.Я немного не дописал. Потом я тестил уже только с включенным бриджем без сторонних интерфейсов в этой плоской сети.
Когда есть бридж с одним маком то фреймы будут ходить только по одному кротчайшему пути?
> Когда есть бридж с одним маком то фреймы будут ходить только по
> одному кротчайшему пути?Нет. Броадкасты будут ходить по всем возможным путям, ломая таблицы коммутации. Исправить это можно только блокировкой избыточных путей. Так, чтобы из пункта А в пункт B был только один единственный путь.
>>> Так как фрэймы ходят разными путями в непредсказуемом порядке, твой инет 100%, рано или поздно, засветится на зле.
> Я немного не дописал. Потом я тестил уже только с включенным бриджем
> без сторонних интерфейсов в этой плоской сети.
> Когда есть бридж с одним маком то фреймы будут ходить только по
> одному кротчайшему пути?Наверно все равно получиться каша, так как будет приходить второй широковещательный пакет который будет вешать мак моего бриджа на другой порт не злого комутатора, в итоге будет ходить по более длинному пути. если на еб таблес прописать не отвечать на широковещательный запрос на тех портах к которым не относиться мак пользователя, отправившего широковещательный запрос то таблички коммутаторов не будут перезаписываться и все ведь будет правильно? вот только возня с изучением того в каком куске кто сидит, полностью автоматизировать эту задачу не получиться как я понял.
Ну да, но это нереальный геморой будет, лучше так не делать :)
> Ну да, но это нереальный геморой будет, лучше так не делать :)Тогда кроме как поставить свой маршрутизатор в сеть чтоб оно полностью пропускал через себя весь траффик уйти от палева не получиться(((((
В виду того, что конспирации не получится всё равно, более феншуйным был бы вариант просто воткнуться в любой свитч и организовать, например, прозрачный прокси для раздачи интернетов людям. Единственная неудобность в том, что нужно прописаться на каждом клиенте, как шлюз. Я бы это сделал по средствам DHCP-сервера, чтоб управлять сетевыми настройками всех клиентов, да и не надо будет потом бегать чтоб что-то поменять или заставлять тётенек вводить ip и маски ))) Это как раз и будет твой маршрутизатор.А вообще, ещё к вопросу о конспирации. Если вы просто в организационном плане не уполномочены чтобы предоставлять сервисы пользователям сети, то у вас вообще два варианта: Либо бросить это, либо обсудить этот вопрос с начальствующим. :)
> В виду того, что конспирации не получится всё равно, более феншуйным был
> бы вариант просто воткнуться в любой свитч и организовать, например, прозрачный
> прокси для раздачи интернетов людям. Единственная неудобность в том, что нужно
> прописаться на каждом клиенте, как шлюз. Я бы это сделал по
> средствам DHCP-сервера, чтоб управлять сетевыми настройками всех клиентов, да и не
> надо будет потом бегать чтоб что-то поменять или заставлять тётенек вводить
> ip и маски ))) Это как раз и будет маршрутизатор.Не понял
>Единственная неудобность в том, что нужно прописаться на каждом клиенте, как шлюз.Как шлюз? А не как прокси?
Да но тогда можно остаться на текущем опенвпн. Я уже достаточно наладил организационные моменты, написал бат скрипты которые большую часть все же делают, и нанял помошницу, которая когда что то все же не выходит помогает. или на случай тетенек, которыми зачастую являються и ребята, которые типа на компьютерой специальности учаться, и не знают что с бат скриптом сделать(
> Да но тогда можно остаться на текущем опенвпн.Да, тоже хорошее решение.
>Не понял
>>Единственная неудобность в том, что нужно прописаться на каждом клиенте, как шлюз.
>Как шлюз? А не как прокси?Ну в смысле прозрачность прокси заключается в насилии :) Преимущество в том, что его не надо указывать на клиентах, и софт который кривой и не умеет работать с проски даже не будет догадываться, что его трафик всё равно проксируется.
А как насильно перенаправить трафик всех пользователей на свой прокси? Надо либо делать прокси прямо на ПК, на который указывает у всех умолчальный маршрут, т.е на шлюзе, либо с этого шлюза перенаправлять общий трафик на ПК с прокси.
Ну вариант с OpenVPN тоже нормальный.
> Да но тогда можно остаться на текущем опенвпн. Я уже достаточно наладил
> организационные моменты, написал бат скрипты которые большую часть все же делают,
> и нанял помошницу, которая когда что то все же не выходит
> помогает. или на случай тетенек, которыми зачастую являються и ребята, которые
> типа на компьютерой специальности учаться, и не знают что с бат
> скриптом сделать(А не хотите выделить для этого дела еще три роутера?
сегмент1-роутер1- \
сегмент2-роутер2---фэйковая сеть - ваш комп - ваш инет
сегмент3-роутер3- /Тогда все будет работать как следует. Обычная маршрутизация.Очень простая и прозрачная схема. Злосвичь вообще никогда не увидит паленого трафика. И ВПНов не понадобиться.
Организовать это можно по разному. Очевидный вариант - поставить три коробочки-роутера.
или роутеры на утильных системниках.
Более геморойный вариант - поднять три виртуальных машины в которых будут сидеть "роутеры", привязать их "входящие" интерфейсы бриждем к трем реальным сетевушкам вашего компа смотрящим в соответствующие сегменты. Адресов реальным сетевушкам конечно же назначать ненужно. Они будут назначены на виртуалках.
Выходящие интерфейсы виртуалок будут роутится внутри вашего компа обычным образом.
>[оверквотинг удален]
>> помогает. или на случай тетенек, которыми зачастую являються и ребята, которые
>> типа на компьютерой специальности учаться, и не знают что с бат
>> скриптом сделать(
> А не хотите выделить для этого дела еще три роутера?
> сегмент1-роутер1- \
> сегмент2-роутер2---фэйковая сеть - ваш комп - ваш инет
> сегмент3-роутер3- /
> Тогда все будет работать как следует. Обычная маршрутизация.Очень простая и прозрачная
> схема. Злосвичь вообще никогда не увидит паленого трафика. И ВПНов не
> понадобиться.Я попробовал сделать так, несколько ип адресов с одной плоской сети на одном моем роутере, которые визически воткнуты в свичи которые находяться в разных концах плоской сети и не должны бегать ко мне через злой свич. Проблема была в том, что моему роутеру от такой маршрутизации сносило башню просто, и он очень лагал. из 3 интерфейсов сейчас работает один, так ему вроде легче. может проблема была в том что при лаге на одном из свичей перерисовывалась все маршрутизация у меня на роутере и это передергивало все подключения на остальных интерфейчас я толком не понял, думал что то перенастрить в sysctl но это совсем темный лес для меня и вообще думаю что это плохой тон там что то тюнить.
>[оверквотинг удален]
> одном моем роутере, которые визически воткнуты в свичи которые находяться в
> разных концах плоской сети и не должны бегать ко мне через
> злой свич. Проблема была в том, что моему роутеру от такой
> маршрутизации сносило башню просто, и он очень лагал. из 3 интерфейсов
> сейчас работает один, так ему вроде легче. может проблема была в
> том что при лаге на одном из свичей перерисовывалась все маршрутизация
> у меня на роутере и это передергивало все подключения на остальных
> интерфейчас я толком не понял, думал что то перенастрить в sysctl
> но это совсем темный лес для меня и вообще думаю что
> это плохой тон там что то тюнить.Я говорю о трех адресах которые будут находится на РАЗНЫХ машинах. виртуальных или реальных... Если реальных (физических коробочках) - то там вообще все запустится с первого раза.
>[оверквотинг удален]
>> злой свич. Проблема была в том, что моему роутеру от такой
>> маршрутизации сносило башню просто, и он очень лагал. из 3 интерфейсов
>> сейчас работает один, так ему вроде легче. может проблема была в
>> том что при лаге на одном из свичей перерисовывалась все маршрутизация
>> у меня на роутере и это передергивало все подключения на остальных
>> интерфейчас я толком не понял, думал что то перенастрить в sysctl
>> но это совсем темный лес для меня и вообще думаю что
>> это плохой тон там что то тюнить.
> Я говорю о трех адресах которые будут находится на РАЗНЫХ машинах. виртуальных
> или реальных...Поднять 3 впс? или разобраться почему плохо работает маршрутизация на одной машине? Вот в чем вопрос))
>[оверквотинг удален]
>>> сейчас работает один, так ему вроде легче. может проблема была в
>>> том что при лаге на одном из свичей перерисовывалась все маршрутизация
>>> у меня на роутере и это передергивало все подключения на остальных
>>> интерфейчас я толком не понял, думал что то перенастрить в sysctl
>>> но это совсем темный лес для меня и вообще думаю что
>>> это плохой тон там что то тюнить.
>> Я говорю о трех адресах которые будут находится на РАЗНЫХ машинах. виртуальных
>> или реальных...
> Поднять 3 впс? или разобраться почему плохо работает маршрутизация на одной машине?
> Вот в чем вопрос))Схожу за попкорном :)
>[оверквотинг удален]
>>>> том что при лаге на одном из свичей перерисовывалась все маршрутизация
>>>> у меня на роутере и это передергивало все подключения на остальных
>>>> интерфейчас я толком не понял, думал что то перенастрить в sysctl
>>>> но это совсем темный лес для меня и вообще думаю что
>>>> это плохой тон там что то тюнить.
>>> Я говорю о трех адресах которые будут находится на РАЗНЫХ машинах. виртуальных
>>> или реальных...
>> Поднять 3 впс? или разобраться почему плохо работает маршрутизация на одной машине?
>> Вот в чем вопрос))
> Схожу за попкорном :)Не смешно. Я чуть не расплакался после 62,64 поста. Тут вырисовалась драмма в которой человек хотел сделать что то классное и неверотяное, но ввиду того как он понял насколько это невероятная хотя реально реализуемая задача, он понял что все его усилия канули в лету.
>[оверквотинг удален]
>>>>> это плохой тон там что то тюнить.
>>>> Я говорю о трех адресах которые будут находится на РАЗНЫХ машинах. виртуальных
>>>> или реальных...
>>> Поднять 3 впс? или разобраться почему плохо работает маршрутизация на одной машине?
>>> Вот в чем вопрос))
>> Схожу за попкорном :)
> Не смешно. Я чуть не расплакался после 64 поста. Тут вырисовалась драмма
> в которой человек хотел сделать что то классное и неверотяное, но
> ввиду того как он понял насколько это невероятная хотя реально реализуемая
> задача, он понял что все его усилия канули в лету.VPS - громко сказано. На самом деле достаточно запустить там "почти бездисковый" (ну тока чтоб конфиг сохранять, хотя можно хранить его на подмонтируемом nfs) "роутер на одной дискетке.. выделить ему 8 мегов оперативки. 3х8=24 метра+накладные расходы отожрут три виртуалки. Таких роутеров в сети полно. Хоть на линухе хоть на фре. зачем туда полностью систему разворачивать?
И с маршрутизацией там никаких проблем быть не может. Одна сеть - один интерфейс на устройстве.
cloun,
Можно тебе зло отключать от коммутаторов?
> cloun,
> Можно тебе зло отключать от коммутаторов?Через зло все выходят в большую сеть от которой никто отказаться не согласиться. На время тоже потому как людей которые через большие коммутаторы ходят на злой роутер много.
Есть идея заплатить за 3 очень умных коммутатора, на которых запретить выход траффика не 10.0.0.0/8 на порт на котором зло роутер.
>> cloun,
>> Можно тебе зло отключать от коммутаторов?
> Через зло все выходят в большую сеть от которой никто отказаться
> не согласиться. На время тоже потому как людей которые через большие
> коммутаторы ходят на злой роутер много.
> Есть идея заплатить за 3 очень умных коммутатора, на которых запретить выход
> траффика не 10.0.0.0/8 на порт на котором зло роутер.Нет слов...
Если у вас есть возможность заменить неуправляемые свичи сегментов на управляемые с вланами - проблемы вообще нету. Создаете на свичах два влана - один на порты сегмента и порт на злороутер, второй влан- на порты сегмента и на свой комп. И все. И только на одном из таких свичей включаете себя в первый влан. чтоб самому злороутер видеть....
Плюс тупой свичик который агрегирует три линка в ваш один интерфейс ко внутренней сети.
А может можно тогда отключить придурка от твоих свитчей и воткнуть его в себя? :)) Все будут ходить в большую сеть через него, а для всего остального на тебя и через тебя.
