FireawallD и маршрутизация между сетями только по разрешенным портам

[yamah]

Добрый день.

Есть две сети.
10.10.24.0/24 - сервера
192.168.24.0/24 - клиенты (ПК, смартфоны)
Есть между ними шлюз с адресом 10.10.24.1 и 192.168.24.1, адаптером eth0 и eth1 в соответствующих сетях. Можно считать, что он прописан, как шлюз по-умолчанию.
В firewall были созданы зоны server и clients, для которых были назначены source и interface соответствующих сетей. Для зоны servers было произведено сужение доступных адресов путем указания конкретных конечных адресов

В сети 10.10.24.0/24 есть сервера:
10.10.24.2 - DNS
10.10.24.5 - NTP
10.10.24.12 - Proxy
И много других.

Задача. Разрешить маршрутизацию из сети 192.168.24.0/24 до указанных хостов и указанных (!) портов
10.10.24.2 - 53
10.10.24.5 - 123
10.10.24.12 - 3128
запретив доступ по остальным портам на уровне шлюза.
Проброс портов мне не нужен.

Попытке врубить маскарадинг для зоны servers, клиенты могут получить доступ ко всем портам хостов, разрешенных в зоне.
Если я добавляю в зоне clients правила rich-rules с указанием хостов назначения и указываю действие маскарадинг, то клиенты могут получить доступ ко всем портам на источнике назначения.

На ум пришла мысль сделать так.
1. Включить маскарадинг для зоны server.
2. Рич-рулами дроппить все запросы в эту зону.
3. Разрешить нужные порты на нужные хосты.

Это правильное решение, или есть тиной путь?

[Bizdelnick]

Проброс портов мне не нужен.

врубить маскарадинг

Взаимоисключающие параграфы, однако. Не нужен Вам маскарадинг.

[yamah]

Взаимоисключающие параграфы, однако. Не нужен Вам маскарадинг.

Может я не правильно формулирую.
В моем понимание проброс портов это: при обращении к хосту 192.168.24.1 на порт 123, скажем, файервол втихую отправит запрос на хост 10.10.24.5 на порт 123, а потом возвращает ответ от своего адреса. То есть клиент ничего не знает о хосте 10.10.24.5 и думает, что ему отвечает 192.168.24.1.
Мне же нужно, чтобы клиент отправил запрос на адрес 10.10.24.5 (маршрут к которому идет через шлюз 192.168.24.1) на порт 123, и ответ он получил так же от 10.10.24.5

[Bizdelnick]

Это я, похоже, неправильно формулирую. Маршрутизация и маскарадинг — разные вещи. Маскарадинг Вам не нужен.

[yamah]

Это я, похоже, неправильно формулирую. Маршрутизация и маскарадинг — разные вещи. Маскарадинг Вам не нужен.

Тогда я не понимаю.

Делаю на шлюзе:

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

firewall-cmd --zone=servers --add-asquarading --permanent
firewall-cmd --reload

На клиенте

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

traceroute 10.10.24.5
traceroute to 10.10.24.5 (10.10.24.5), 30 hops max, 60 bytes packets
1  _gateway (192.168.24.1) 0.350 ms 0.320 ms 0.295 ms
2 10.10.24.5 (10.10.24.5) 3/509 ms 3.503 ms 3.489 ms

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

Делаю на шлюзе:

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

firewall-cmd --zone=servers --remove-asquarading --permanent
firewall-cmd --reload

На клиенте

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

traceroute 10.10.24.5
traceroute to 10.10.24.5 (10.10.24.5), 30 hops max, 60 bytes packets
1  _gateway (192.168.24.1) 0.392 ms 0.373 ms 0.358 ms
2 _gateway (192.168.24.1) 0.327 ms 0.303 ms 0.285 ms

И, понятное дело, доступа до сервер нет никакого.

При попытке прописать:

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

# firewall-cmd --permanent --zone=samba --add-rich-rule='rule family=ipv4 source address=192.168.24.0/24 destination address=10.10.24.5 port port=123 protocol=udp masquerade'

Получаю отлуп

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

Error: INVALID_RULE: more than one element. There cannot be both 'masquerade' and 'port port="123" protocol="udp"' in one rule.

Что я делаю не так?

[Bizdelnick]

Вам нужно разрешить форвардинг (--add-forward для обеих зон, если я правильно понимаю).

[chitatel]

А дистрибутив-то какой?

/etc/hosts.* настроить на серваке?

[yamah]

Вам нужно разрешить форвардинг (--add-forward для обеих зон, если я правильно понимаю).

Спасибо. Попробую.

А дистрибутив-то какой?

Дистрибутив, будем считать, СentOS 7.3

/etc/hosts.* настроить на серваке?

э-э... А как мне настройки /etc/hosts.* помогут в маршрутизации трафик между сетями?

[chitatel]

В маршрутизации никак.

Доступ к портам/сервисам можно тут разрешить/запретить.

[yamah]

В маршрутизации никак.

Доступ к портам/сервисам можно тут разрешить/запретить.

Моя цель именно маршрутизация, но не всего трафика, а только разрешенного.

Фактически мне нужен аналог этого правила

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

iptables -A FORWARD -s 192.268.24.0/24 -d  10.10.24.5 -p UDP -m multiport --dports 123 -j ACCEPT
iptables -A FORWARD -s 10.10.24.5 -d 192.268.24.0/24 -p UDP  --sport 123 -m state --state ESTABLISHED -j ACCEPT

[chitatel]

Понятно.

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

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

И я не знаю, есть ли на CentOS /etc/hosts.*

Updated

На всякий случай напишу сюда:

Есть примочка к iptables - ipset. В set'ы можно прописывать сети, сегменты сетей\диапазоны адресов, отдельные хосты. Соответственно, отсекать ненужное.

У меня в iptables на сервачке есть правила типа:

-A INPUT -i eth1 -p udp -m set --match-set dnsnet src -m udp --dport 53 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

Хосты из dnsnet достучатся до сервиса, а остальным ДРОП.

[yamah]

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

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

Это вопрос безопасности.
Лишний трафик вообще не должен выходить за пределы сети. Именно поэтому на аппаратных маршрутизаторах определяется не только доступ к узлу, но и доступные порты. Особенно, когда сети управляются разными командами людей.
Гарантий, что на укзанном хосте не будет поднят скажем псевдо-smb сервер, для воровства учетных данных, нет.

Есть примочка к iptables - ipset. В set'ы можно прописывать сети, сегменты сетей\диапазоны адресов, отдельные хосты. Соответственно, отсекать ненужное.

У меня в iptables на сервачке есть правила типа:

-A INPUT -i eth1 -p udp -m set --match-set dnsnet src -m udp --dport 53 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

Хосты из dnsnet достучатся до сервиса, а остальным ДРОП.

С IPTables проблем нет. У меня куча готовых решений есть для настройки правил маршрутизации и доступа. ОТ Bash-скриптов до программ (былокода) на c++ с хранением параметров в СУБД.

[Bizdelnick]

Кстати, вообще форвардинг (/proc/sys/net/ipv4/ip_forward) включён? Как я понял из документации, firewalld сам его включает вместе с маскарадингом. Возможно, надо включить в sysctl.conf на постоянку.

[yamah]

Кстати, вообще форвардинг (/proc/sys/net/ipv4/ip_forward) включён? Как я понял из документации, firewalld сам его включает вместе с маскарадингом. Возможно, надо включить в sysctl.conf на постоянку.

Настроил, чтобы он был включен по умолчанию.