Существует проблема изоляции клиентов друг от друга:
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...
Ответ на:
комментарий
от no-dashi
Ответ на:
комментарий
от pr0mille
Ответ на:
комментарий
от ktulhu666
Ответ на:
комментарий
от at
Ответ на:
комментарий
от xscrew
Ответ на:
комментарий
от pr0mille
Ответ на:
комментарий
от xscrew
Ответ на:
комментарий
от pr0mille
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.