LINUX.ORG.RU
Форум — Admin  

Изоляция/фильтрация трафика всей сети. С одинаковым Default GW для всех клиентов.

 , , ,


1

2

Существует проблема изоляции клиентов друг от друга:
1. Необходимо иметь возможность с КОНКРЕТНОГО VLAN для КОНКРЕТНОГО IP разрешать (по умолчанию всё запрещено) роутинг в КОНКРЕТНЫЙ VLAN на КОНКРЕТНЫЙ IP на КОНКРЕТНЫЙ порт (использоваться, в основном только TCP будет).
2. При этом все клиенты (машины в сети) должны иметь ОДИНАКОВЫЙ IP дефолт гетевея прописанным. (!!!!!!!!!!!!!!!)

Извиняюсь за капс, но на лоре весьма много людей с позицией «бред писал, топик не читал».

A - клиенты, P - их сервера, S - сервер-шлюз (фильтрующий трафик).

Технически это должно выглядеть так:
Например, нужно иметь возможность с A1 (192.168.1.1) получить доступ к P6 (192.168.1.6) на TCP 22. Тогда:
1. А1 отсылает arp-запрос IP-адреса 192.168.1.1 в VLAN1, который приходит на виртуальный интерфейс vlan0.1 у S8.
2. S8 отвечает на запрос любого IP, ставя свой MAC (или, таки удалённого компа!?).
3. S8 проверяет правило в стиле: от 192.168.1.1 с vlan0.1 к 192.168.1.6 на vlan0.6 протокол TCP порт 22.
4. Правило верно, тогда пакет уходит с vlan0.6 на P6, а в ipbtales делается запись established для данной сессии, чтобы пакеты обратно пропускались.

Проблема именно в том, что из-за необходимости иметь одинаковый IP на всех компах (т.е. для клиентов взаимодействие с другими клиентами должно быть настолько же (кроме широковещалки) прозрачно, как и в обычной сети, но с чёткими ограничениями через фильтрующий сервер S8). Из-за этого условия нельзя воспользоваться тупой нарезкой сети по 4 IP (два отнимаются, т.к. нижний - номером сети будет, верхний - броадкасn-адресом, согласно спецификации IP). В случае с нарезкой на такие сегменты всё просто: поскольку это тупо куча разных сетей (по одной на клиента, фактически), то можно использовать тупой роутинг + iptables форвардинг с проверкой условий. Но по моим условиям (у всех должен быть один IP gefault gw) так сделать нельзя.

Я пришел к выводу, что мою задачу можно реализовать двумя путями:
1. Для того, чтобы сервер выдавал свой MAC при ARM-запросе IP от клиента присваиваем ему все IP всех клиентов.
Далее в iptables пишем, что netfilter заменяет (в стадии PREROUTING) адрес клиента 192.168.1.X на 192.168.2.X (чтобы сервер сам не стал обрабатывать пакеты, т.к. ему все адреса присвоены).
После чего уже делаем проверку прав и определение исходящего интерфейса в FORWARD.
Далее в POSTROUTING уже обратно заменяем 192.168.2.X на 192.168.1.X

Проблемы:
Всё на костылях.
Один IP можно назначить только одному интерфейсу. А тут нужно назначить на каждый VLAN кучу IP, за исключением IP клиента. Хотя это делается, однако никакой реакции от всех интерфейсов, кроме одного на конкретный IP не будет. Даже если мы разрешим (есть такая опция) принимать данные с любых IP, то исходящие пакеты будут только с одного (причём не ясно какого) интерфейса.


2. Использовать ARP PROXY, чтобы отвечать своим MAC на любой ARP-запрос.
Но это лишь преодолевает костыль с подменой IP на 192.168.2.X, но никак не проблема дубликатов IP на интерфейсов.
Ведь (!!! Поправьте, если я не прав) iptables и route не будет работать (и нет настроек ядра, чтобы это изменить), если IP шлюза, указанный в пакете, не будет совпадать с тем, который реально есть у интерфейса, даже если ethernet-кадр пришел.


3. Использовать ebtables. ebtable позволяет работать с L2, там есть поддержка протокола. Но для нормальной (насколько я знаю) работы с tcp (особенно в плане established для разрешения ответов с принимающего конца).
Но разве iptables может работать, когда на интерфейсах нет ip (вопрос скорее риторический)? Или ebtables научился нормально с tcp работать (особенно меня запоминание открытых соединений для разрешения ответов с другой стороны интересует)?

На ум приходят только такие настройки для ebtables (подразумевается, что все vlan'ы объединены в бридж, который рубит весь неразрешенный трафик (последняя строка)):
-p IPv4 -i vlan0.1 -o vlan0.6 --ip-src 192.168.1.1 --ip-dst 192.168.1.6 --ip-proto tcp --ip-dport 22 -j ACCEPT
-p IPv4 -i vlan0.6 -o vlan0.1 --ip-src 192.168.1.6 --ip-dst 192.168.1.1 --ip-proto tcp --ip-sport 22 -j ACCEPT
-p IPv4 -j DROP
#Всё, что дошло до сюда уже переходит в следующую часть, где должна происходить L2-маршрутизация. Хотя, думаю, что она произойдёт автоматически, т.к. VLAN'ы объединены в свитч виртуальный должны быть.

В этом случае для того, чтобы пускать машины в инетик, нужно в --ip-dst использовать адрес GW (192.168.1.7) или уже внешние адреса, например:
-p IPv4 -i vlan0.1 -o vlan0.7 --ip-dst 192.168.1.7 -j ACCEPT
или
-p IPv4 -i vlan0.7 -o vlan0.1 ! --ip-dst 192.168.1.0/24 -j ACCEPT
?

Я не совсем понял, как именно клиент работает с default gw. Он тупо на его MAC высылает готовые IP-пакеты, что ли? Т.е. в самих пакетах к шлюзу его IP вообще не фиругирует?

Огромное спасибо всем, кто будет помогать мне в решении такой задачки ^____^ .

Схема следующая:
.............Свитч
.......... -------------
A1 ------|VLAN1....|
..........|...........|
A2 ------|VLAN2....|
..........|...........|
A3 ------|VLAN3....|
A4 ------|VLAN4....|
A5 ------|VLAN5....|
..........|....VLAN8|--------- S8 (сервер-фильтр)
P6 ------|VLAN6....|
P7 ------|VLAN7....|
--------------
Порошу простить за точки, считайте, что это пробелы. Движок все пробелы больше одного делает одним пробелом. Вероятно, ширина тема действительно куда важнее, чем такая мелочь. Скажем спасибо maxcom и прочим любителям микроэкранов.

Используйте схему netfilter и ebtables для понимания их работы: http://4.bp.blogspot.com/_N3xuQCvc1v4/TQlz5a1YXSI/AAAAAAAAASc/f0aNn5Z1q3I/s16...

← PXE сервер и раздача интернета
Банальный проброс портов →
  1 2 3
Ответ на: комментарий от zolden

проверил у нас на сети на цисках и на свичах huawei - всё работает, то есть, скорее
всего, все более менее свежие железки более менее крупных вендоров умеют так

Ну может быть. Тогда вопрос, а что с мелкими и что с разными ОС. И не завалялось ли где Windows 95 какой-нибудь...

AS ★★★★★
()
Ответ на: комментарий от xscrew

Остальные переживания поддерживает/не поддерживает/а что если - это уже другая тема.

Как раз нет. Вендор-специфичное - это значит, что не работает, если по факту. А вот если уже народ потянулся остальной, это интереснее.

AS ★★★★★
()
Ответ на: комментарий от pr0mille

В мире куча производителей оборудования

RFC датирован 2000 годом.
То есть думаю уже лет 5 он должен быть стандартом, а то, что вы про это не знали - не ваша вина, не переживайте так.
LOR и гугл вас не бросят и всегда вам помогут

zolden ★★★★★
()
Ответ на: комментарий от xscrew

В мире куча производителей оборудования и на juniper & cisco мир клином не сошелся. Где гарантия,что все умеют эту фичу ? Где гарантия,что у клиента такое будет уметь? что если клиент сменить устройство на то которое не умеет, Вам сеть перенастраивать?

Изначально разговор был про то, возможно ли /31 на интерфейс, если да - то как это работает. Очевидно что можно и что это работает. Все.

Остальные переживания поддерживает/не поддерживает/а что если - >это уже другая тема.

было сказано к слову о «gut praktisch»

AS дельно выразился, что /31 скользкий вопрос, Вы знаете все многообрази протоколов и их особенности и готовы гарантировать,что все будет работать в таком случае? Или нам ожидать неделю роутинга на LORе, после того как все начнут себе /31 где не попадя лепить ?

pr0mille ★
()
Ответ на: комментарий от pr0mille

Вы знаете все многообрази протоколов и их особенности и готовы гарантировать,что все будет работать в таком случае?

Какое у вас многообразие протоколов, работающих на стыках между оборудованием?

все начнут себе /31 где не попадя лепить ?

У вас практика такая - сразу лепить? Не проверить, не подумать - а сразу лепить?

xscrew ★★
()
Ответ на: комментарий от no-dashi

Блин, как я сам до этого не додумался. Решение было таким очевидным. Спасибо.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от xscrew

Какое у вас многообразие протоколов, работающих на стыках между оборудованием?

Прошу рассказать, как в таком случае будет работать RIPv1

У вас практика такая - сразу лепить? Не проверить, не подумать - а сразу лепить?

жутко толсто.

pr0mille ★
()
Ответ на: комментарий от at

Очень интересная мысль. Однако, с чего серверу отвечать клиенту, когда гейт (это IP сервера, так?) на lo, а вланам вообще IP не присвоен (разве последняя строчка избавляется от необходимости иметь IP (L3) на интерфейсе? разве route может так лихо переходить с L3 на L2?)?

Можете поподробнее описать полёт Вашей мысли?

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от xscrew

По факту везде где попробовали - работает.

На винде, фре и линуксе работает? Или Вы только на цисках, хуавеях и джуниперах тестили?

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от pr0mille

Прошу рассказать, как в таком случае будет работать RIPv1

[fattroll_mode] Очевидно же, что оборудование имеет IPSec и гоняет broadcast трафик через него поверх реальной сети. [/fattroll_mode]

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

На винде, фре и линуксе работает?

это вам на другие форумы надо, точно говорю
Повторюсь повторюсь - на линуксе всё работает

zolden ★★★★★
()
Ответ на: комментарий от Pinkbyte

кстати, да. Широковещалка на таком линке ведь в принципе невозможна?

Ну вот местные тесты вроде показали, что, в военное время, оно возможно.

AS ★★★★★
()
Ответ на: комментарий от Pinkbyte

кстати, да. Широковещалка на таком линке ведь в принципе невозможна?

На IP уровне (L3) - нет (или, как я сказал ранее - капсулировать (например, в IPSec).
На Ethernet (L2) - не проблема (надо смотреть, как приложение работает с сетью: через L3 вызов к ведру или сразу через L2).

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

На винде, фре и линуксе работает?

На счет винды не знаю, на линуксе сработало, фри под рукой нет, но и там я уверен будет можно.

xscrew ★★
()
Ответ на: комментарий от ktulhu666

Можете поподробнее описать полёт Вашей мысли?

Да та же самая мысль что и у меня, только я расписал подробней.

Однако, с чего серверу отвечать клиенту, когда гейт (это IP сервера, так?) на lo, а вланам вообще IP не присвоен

Повторю - IP это атрибут хоста, а не интерфейса. К интерфейсам IP привязывается просто «потому что так заведено», и IP «на интерфейсе» в сочетании с маской подсети позволяет сделать «на одну строчку настроек меньше». Тебя же не удивляет, что из внутренней сети можно пинговать IP «внешнего» интерфейса маршрутизатора?

no-dashi ★★★★★
()
Ответ на: комментарий от AS

В смысле широковещалка возможна? Хотя, теоретически, таки, возможна. У нас же 2 IP (причём один из них точно наш). Значит любая широковещалка - это всегда на другой хост отправка. Только вот проблема с указанием имени сети не решена.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

[fattroll_mode] Очевидно же, что оборудование имеет IPSec и гоняет broadcast трафик через него поверх реальной сети. [/fattroll_mode]

Это [fool_mode] был. RIPv1 уже отмер давным давно, да и в добавок использует multicast, емнип

xscrew ★★
()
Ответ на: комментарий от xscrew

Вендор-специфичное

RFC 3021 - Using 31-Bit Prefixes on IPv4 Point-to-Point Links

Мы же, вроде, договорились, что ethernet не имеет отношения к Point-to-Point ? И я не увидел в этом RFC слово ethernet. Так что, если RFC, то, наверное, с другим номером.

AS ★★★★★
()
Ответ на: комментарий от xscrew

С RIPv1 можно изучить маршрут /30, в определенном случае. это к слову.

и где было сказано именно об анонсе, распространии маршрутов. Наводящий вопрос, что будет в dst ip ?

pr0mille ★
()
Ответ на: комментарий от ktulhu666

В смысле широковещалка возможна?

Тьфу, слово «широковещалка» не заметил. Не знаю. :-)

AS ★★★★★
()
Ответ на: комментарий от ktulhu666

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

Я писал зачем и где можно применять /31. Я не думаю, что кто-то будет использовать windows в качестве маршрутизатора.

xscrew ★★
()
Ответ на: комментарий от xscrew

Это [fool_mode] был. RIPv1 уже отмер давным давно, да и в добавок использует multicast, емнип

садись, два

То что его не юзают, это не значит,что его запретили и выпили со всего оборудования.

pr0mille ★
()
Ответ на: комментарий от no-dashi

Я знаю, что IP - это атрибут стека ядра и можно есть вертеть, как захочешь (точнее, как настроены другие компы вокруг твоего, иначе могут просто игнорировать). Я работал и с бондингом и с бриджем, не надо меня идиотом считать. Вашу идею я полностью понял. А вот его нет. Мне не понятно, как оно будет работать, когда IP есть только на lo, а на vlan-интерфейсах нет IP, причём они не соединены. Даже если разрешить принимать пакеты на интерфейс, у которого не тот (а в данном случае его вообще нет) IP, что имеющем его интерфейсе (lo), то ответы то будут идти через маршрут по-умолчанию для этого интерфейса (lo). Он попытался обойти это, сделав маршруты, указывающие другой интерфейс для исходящих пакетов. Но route работает на L3 (насколько я знаю). И не может на интерфейс без IP что-либо послать. Или я не прав?

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от Pinkbyte

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

pr0mille ★
()
Ответ на: комментарий от pr0mille

садись, два

Я и не вставал, отвечал сидя.

То что его не юзают, это не значит,что его запретили и выпили со всего оборудования.

То что его не юзают

Мне не интересно это дальше обсуждать, свою позицию я высказал, а именно работает и как работает. В любом случае в начале думается, что будет использовать, а потом уже делается. Если вы хотите ripv1 и с /31 вы этого не можете - вы не используете /31. Вы хотите ospf и хотите /31 - вы используете /31.

Какие еще вопросы?

xscrew ★★
()
Ответ на: комментарий от AS

Мы же, вроде, договорились, что ethernet не имеет отношения к Point-to-Point ?

Так то да, Ethernet это не p2p. Но в случае прямого линка - по всей логике это p2p. И эта логика не только у меня, а еще и у производителей оборудования. И это работает.

xscrew ★★
()
Ответ на: комментарий от xscrew

Так то да, Ethernet это не p2p. Но в случае прямого линка - по всей логике это p2p.

Никакой логики. Там процесс распространения пакетов по-другому происходит. Кстати, цитата из 3021: «This option provides the same address space savings as using a 31-bit subnet mask, but may only be used in links using PPP encapsulation [RFC1332].»

AS ★★★★★
()
Ответ на: комментарий от AS

Никакой логики. Там процесс распространения пакетов по-другому происходит.

Смысл везде одинаков - инкапсулировать в кадры канального уровня и вытолкнуть в интерфейс. И в том и в этом случае на стыках - все одинаково.

Но постарайтесь меня услышать - я говорю о возможности использовать, а не вовсе призываю использовать, это все по желанию :)

xscrew ★★
()
Ответ на: комментарий от ktulhu666

Мне не понятно, как оно будет работать, когда IP есть только на lo, а на vlan-интерфейсах нет IP, причём они не соединены

Это не важно. Точнее, это не имеет значения. Для работы IP, нужно решить проблему «через какой интерфейс и шлюз отправлять» (проблему L3). Её решает route. Если под L3 лежит ethernet, то нужно решить вторую проблему - кому отправлять в сегменте (что и делает ARP).

Или я не прав?

Именно. Ты неправ. Последовательность отправки пакета какая?

1. Определить маршрут -> на выходе имеем интерфейс и опционально маршрутизатор, если маршрут не найден - retun NO_ROUTE;

2. Если интерфейс точка-точка - сунуть пакет в интерфейс; return NO_ERROR

3. Если маршрутизатор указан, то определить его L2 через указанный интерфейс (ARP who-is IP.ADDR.OF.GATEWAY), иначе определить L2 адресата через указанный интерфейс (ARP who-is IP.ADDR.OF.DESTINATION)

4. Если найден L2 - кинуть на него фрейм, если не найден - return HOST_IS_DOWN;

Последовательность обработки ARP тоже несложная:

1. Принят ARP-запрос

2. Запомнить интерфейс, с которого пришел запрос

3. Взять из запроса IP

4. Это мой IP?

5. Если нет - return;

6. Взять L2-адрес интерфейса с которого пришел пакет

7. Отправить этот адрес отправителю ARP-запроса через тот же интерфейс, через который запрос пришел

Ты видишь здесь хоть где-нибудь «выбор интерфейса по IP»? Я - нет :-) Оно понятно что в случае если используются всякие мультилинки ситуация может осложниться, но принцип от этого не изменится.

no-dashi ★★★★★
()
Ответ на: комментарий от xscrew

Смысл везде одинаков - инкапсулировать в кадры канального уровня и
вытолкнуть в интерфейс. И в том и в этом случае на стыках - все одинаково.

Это слишком общий подход. В случае p2p этого достаточно, так как это труба с одним входом и одним выходом, а в случае ethernet надо задать правильный адрес получателя ещё (в частности, mac), так что просто вытолкнуть в интерфейс нельзя. И вот тут могут разные непонятные спецэффекты получиться.

я говорю о возможности использовать, а не вовсе призываю использовать,

Ну у меня вот возникло впечатление, что есть уверенность, что оно так допустимо везде для ethernet. :-)
Если оно так на самом деле, хотелось бы понять, чем оно регламентируется, потому как, вообще, полезно. RFC 3021 для этого, по всем признакам, не годится. А, ещё, интересен тот момент, что в IOS предупреждение пропало при настройке интерфейса... Может, и правда, что-то появилось.

AS ★★★★★
()
Ответ на: комментарий от AS

И вот тут могут разные непонятные спецэффекты получиться.

Если в один сегмент засунуть две пары хостов с адресами с масками /31, то спецыффекты будут те ещё, это как бы почти гарантируется :-)

no-dashi ★★★★★
()
Ответ на: комментарий от xscrew

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

Чудесное rfc, которое приводится в качестве аргумента, оговаривает p-t-p линки, а от того,что Ethernet интрефейс используется для всязи только с одним соседом, ни как не делает его p-t-p, сама технология такая и /31 особой магией не обладает. И даже в Вашем примере, тоже имеет место быть бродкаст (arp). А если еще в этом случае посмотреть детальную информацию по сконфигурированному интерфейсу,а не только на sh run или ping, можно заметить интересные моменты.

pr0mille ★
()
Ответ на: комментарий от AS

MAC получается через ARP. ARPу вообще не нужен IP, насколько я знаю, только ведро должно нормально обрабатывать отсутствие в кэше пары MAC-IP и посылать ARP-запрос. http://flylib.com/books/en/2.221.1.27/1/ - Документация с картинками ^___^

Смысл в том, что мы отсылаем свой mac, свой ip, удалённый ip на 00-00-00-00-00-00 (броадкаст для L2, чтобы свитч всем разослал) из карточки. ВСЕ хосты это получает, нужный отвечает в виде свой (наш) mac (ТОЛЬКО это нам и нужно то было он него, но остальные данные нужны, чтобы не перепутать с другими хостами при параллельных запросах), свой (его) ip, удалённый ip (наш ip), наш MAC.

Поэтому ARP вообще на всё пофигу. Он может работать с ATM, Frame Relay, Token Ring и Ethernet. Это вообще чисто программная настройка. Нет никаких проблем отослать в сеть пакет с запросом и получить соответствующий пакет в ответ, если вообще можно получить наш и удалённый IP с L3 уровня стека (а у нас эти два и есть). Поэтому всё, (теоретически, и, как тут говорят, и на практике), возможно.

Другой вопрос, что броадкаст-адреса не будет.
Однако (но сомневаюсь, что это реализовано), ведро вполне себе может просто тупо отсылать броадкаст-пакеты на удалённый IP (причём с его MAC, а с броадкастовым даже, чтобы не грузить свитч. Да можно и на броадкастовый MAC, если пофиг на нагрузку свитча). Т.к. приёмником у нас может быть только один хост, то очевидно, кому слать. Другой вопрос, что для этого должен быть костыль в ведре.

Реквестирую проверку.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от pr0mille

т.к. поведение многих моментов в этом случае непонятное.

Каких? Как непонятен процесс отправки пакета от ip1 к ip2 в случае /31 сети.

можно заметить интересные моменты

Какие?

xscrew ★★
()
Ответ на: комментарий от xscrew

Разговор же о прямых стыках между оборудованием.

Можете засунуть в свитч (даже неуправляемый) это оборудование, протестить, работает ли броадкаст? И ещё (если возможно) протестить и с компом с линуксом.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от xscrew

Каких? Как непонятен процесс отправки пакета от ip1 к ip2 в случае /31 сети.

ответ на вопрос про RIPv1 так и не был дан

Какие?

Посмотреть самому ?

pr0mille ★
()
Ответ на: комментарий от xscrew

Основной момент - это возможность ядра послать в жопу приложение, когда оно вызовет открытие особого (броадкаствого) сокета. Если костыль в ядре есть, чтобы завернуть всё на один-единственный удалённый IP, то всё будет ок.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

работает ли броадкаст?

Что значит? если мак адресс ff:ff:ff:ff:ff:ff - то свитч раскидает во все порты, он на L3 не смотрит.

И ещё (если возможно) протестить и с компом с линуксом.

Все тоже самое будет.

Сдается Вы не очень понимаете, как все работает, раз такие вопросы.

xscrew ★★
()
Ответ на: комментарий от xscrew

Разговор же о прямых стыках между оборудованием.

Любой «прямой стык» имеет свойство распрямлячиваться рано или поздно. Проверено :-/

no-dashi ★★★★★
()
Ответ на: комментарий от xscrew

Я честно говоря его не понял.

что будет в dst ip, для пакета который сформировал RIPv1 и отправил в Ethernet интерфейс с единственным ip, и маской /31

pr0mille ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3
← PXE сервер и раздача интернета
Admin
Банальный проброс портов →