PfSense для средней сети и настройка правил.

rubic

Подскажите пожалуйста.

dvserg, я Вас понял.
Верно, что при указании Destination = !адрес_интерфейса нет возможности коннекта на этот адрес, но сохраняется возможность подключаться к адресам других интерфейсов.

В pfSense 2.1.x правило, где явно указан gateway, не пропустит такого подключения, а вот без gateway - пожалуйта. "Weak End System Model" со всеми вытекающими.
Для сведения, в pfSense есть специальная скрытая таблица (алиас со списком IP/mask) <negate_networks>, где прописаны все сети, подключенные к системе. Если в System: Advanced: Firewall and NAT снят флажок "Disable Negate rules" (по умолчанию снят), то перед каждым правилом, где явно указан gateway (policy based routing - PBR), создается скрытое правило разрешающее доступ в эти сети (<negate_networks>).
В pfSense 2.1.x в отличие от 2.0.x таблица <negate_networks>не заполняется и, таким образом, эти правила не работают. Доступа в подключенные сети (и на адреса других интерфейсов pfSense) через правило PBR нет. Скорее всего это просто баг, т.к. в современной версии руководства раздел про Negate Rules присутствует (могут и исправить).

Я лично стараюсь избегать штуковин, которые за сценой что-то делают "для моего же блага". Поэтому флажок System: Advanced: Firewall and NAT -> Disable Negate rules у меня установлен и с правилом подобным вашему я в домике)</negate_networks></negate_networks></negate_networks>

pigbrother

@rubic

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

Правильно ли я понимаю, что некорректная обработка Disable Negate rules в 2.1.х (с задействованным PBR) вынуждает добавлять на LAN разрешающие правила для доступа к сетям, подключеныых через, например, OVPN?

rubic

@pigbrother:

@rubic

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

Правильно ли я понимаю, что некорректная обработка Disable Negate rules в 2.1.х (с задействованным PBR) вынуждает добавлять на LAN разрешающие правила для доступа к сетям, подключеныых через, например, OVPN?

Ну да, просто ставите это правило выше PBR и все

pigbrother

@rubic:

@pigbrother:

@rubic

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

Правильно ли я понимаю, что некорректная обработка Disable Negate rules в 2.1.х (с задействованным PBR) вынуждает добавлять на LAN разрешающие правила для доступа к сетям, подключенных через, например, OVPN?

Ну да, просто ставите это правило выше PBR и все

Следует ли создавать аналогичное правило на OVPN-клиенте 2.1.х для доступа в сеть за сервером?
Клиент без MultiWan\PBR - это пока. Или стоит его добавить заранее - на перспективу?

werter

@ pigbrother

А что мешает проверить ? Дело одной минуты.

pigbrother

@werter:

@ pigbrother

А что мешает проверить ? Дело одной минуты.

Клиент и сервер сечас работают в режиме PSK. Я от них далеко, переводить на PKI планирую позже вместе с апгрейдом сервера с 2.0.х до 2.1.3.
Не хочется, чтобы сработала поговорка - "удаленная настройка маршрутизатора - к дальней дороге".

werter

@ pigbrother

Используйте тот же teamviewer на любой машине и за сервером и за клиентом. Подключайтесь и работайте.

Если имеется белая статика\динамика на клиенте и сервере :

откройте (временно) в мир веб-интерфейсы на клиенте и сервере (на нестандартных портах + https);
настройте (временно) и на клиенте и на сервере тот же PPTP VPN.

И работайте в свое удовольствие.

rubic

@pigbrother:

Клиент и сервер сечас работают в режиме PSK. Я от них далеко, переводить на PKI планирую позже вместе с апгрейдом сервера с 2.0.х до 2.1.3.

Разработчики планируют допилить 2.2 в течение месяца-полутора даже ценой фич, которые были в планах. Обещают с этого момента идти в ногу с релизами FreeBSD - 2.2 будет на 10-ке, многопоточный PF и все такое вот.

werter

@ rubic

Да ? Что-то не верится - https://redmine.pfsense.org/versions/10

Минимум к новому году , а то и в первом квартале 2015.

P.s. Даже ни одной беты не было, только альфы.

pigbrother

@werter:

@ pigbrother

Используйте тот же teamviewer на любой машине и за сервером и за клиентом. Подключайтесь и работайте.

Если имеется белая статика\динамика на клиенте и сервере :

откройте (временно) в мир веб-интерфейсы на клиенте и сервере (на нестандартных портах + https);

настройте (временно) и на клиенте и на сервере тот же PPTP VPN.

И работайте в свое удовольствие.

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

werter

…Вы меня уже совсем ниже плинтуса опустить хотите

Ни в коем случае ;) Я про такое даже не думал - просто предложил варианты.

pigbrother

@rubic:

@pigbrother:

Клиент и сервер сечас работают в режиме PSK. Я от них далеко, переводить на PKI планирую позже вместе с апгрейдом сервера с 2.0.х до 2.1.3.

Разработчики планируют допилить 2.2 в течение месяца-полутора даже ценой фич, которые были в планах. Обещают с этого момента идти в ногу с релизами FreeBSD - 2.2 будет на 10-ке, многопоточный PF и все такое вот.

А не повысятся ли с переходом на 10-ку системные требования pfSense?
Для самой OC декларируются те же
486 or better PC, 64 MB or more of RAM, and at least 1.1 GB of hard disk space.

А в реальности? Да еще если установка будет по умолчанию на ZFS?

rubic

@werter:

@ rubic

Да ? Что-то не верится - https://redmine.pfsense.org/versions/10

Минимум к новому году , а то и в первом квартале 2015.

P.s. Даже ни одной беты не было, только альфы.

Так говорят)

https://forum.pfsense.org/index.php?topic=73517.msg406539#msg406539
https://forum.pfsense.org/index.php?topic=73281.msg414107#msg414107
https://forum.pfsense.org/index.php?topic=76612.msg419935#msg419935

rubic

@rubic:

В pfSense 2.1.x в отличие от 2.0.x таблица <negate_networks>не заполняется и, таким образом, эти правила не работают. Доступа в подключенные сети (и на адреса других интерфейсов pfSense) через правило PBR нет. Скорее всего это просто баг, т.к. в современной версии руководства раздел про Negate Rules присутствует (могут и исправить).</negate_networks>

Похоже все-таки не баг, а фича: https://github.com/pfsense/pfsense/commit/b4227df690fb7a989ead9b3928ebaaaa34b495eb - только сети OpenVPN клиентов попадают в <negate_networks>@pigbrother:

Правильно ли я понимаю, что некорректная обработка Disable Negate rules в 2.1.х (с задействованным PBR) вынуждает добавлять на LAN разрешающие правила для доступа к сетям, подключеныых через, например, OVPN?

Ну, как видим, нет - не нужны такие правила для сетей подключенных через OpenVPN. Нужно только иметь ввиду, что сети OpenVPN клиентов попадают в таблицу <negate_networks>лишь тогда, когда они перечисленны через запятую в поле "Remote networks" OpenVPN сервера, а не заданы директивами "route…" в Advanced configuration.
https://forum.pfsense.org/index.php?topic=66776.msg377169#msg377169</negate_networks></negate_networks>

pigbrother

@rubic

то сети OpenVPN клиентов попадают в таблицу лишь тогда, когда они перечисленны через >запятую в поле "Remote networks" OpenVPN сервера,
1.Тогда получается, что использовать многократно рекомендуемый режим сервера Remote Access не выйдет - в его настройках нет поля Remote networks, а использовать Peer tо Peer SSL/TLS?
2. Как быть с <negate_networks>на клиентах, получающих, например, push "route…." из Client Specific Override сервера? Заполнять IPv4 Remote Network/s на клиенте?</negate_networks>

rubic

@pigbrother:

1.Тогда получается, что использовать многократно рекомендуемый режим сервера Remote Access не выйдет - в его настройках нет поля Remote networks, а использовать Peer tо Peer SSL/TLS?

Да. Ведь Remote Access - это по определению для одиночных клиентов, за которыми нет сетей. Можно конечно добиться, чтобы и с сетями работало, но если клиент позволяет подключиться в режиме Peer tо Peer SSL/TLS, то зачем?

2. Как быть с <negate_networks>на клиентах, получающих, например, push "route…." из Client Specific Override сервера? Заполнять IPv4 Remote Network/s на клиенте?</negate_networks>

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

pigbrother

По мне так проще руками сделать аналог negate rule чем надеяться на этот скрытый механизм, который еще и меняется в самый неудобный момент.

Да, изменения произошли внезапно, но хуже, что при обновлении настройки не переносятся из Advanced configuration в Remote networks.

Прочитал :) комментарии к настройке поля Remote networks. Они честно отличаются:

Для 2.0.х

This is a network that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables. Expressed as a CIDR range. If this is a site-to-site VPN, enter here the remote LAN here…

Для 2.1.2:
These are the IPv4 networkS that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables. Expressed as a comma-separated list of one or more CIDR ranges. If this is a site-to-site VPN, enter the remote LAN/s here….

Если можно - подробнее про самостоятельное создание аналога negate rule.

По поводу negate_networks> на клиентах. Проверил на 2.1.2
В tmp/rules.debug
table <vpn_networks>и table <negate_networks>Создаются\заполняются только при создании сервера, но не клиента OVPN.</negate_networks></vpn_networks>

rubic

@pigbrother:

Прочитал :) комментарии к настройке поля Remote networks. Они честно отличаются:

Для 2.0.х

This is a network that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables. Expressed as a CIDR range. If this is a site-to-site VPN, enter here the remote LAN here…

Для 2.1.2:
These are the IPv4 networkS that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables. Expressed as a comma-separated list of one or more CIDR ranges. If this is a site-to-site VPN, enter the remote LAN/s here….

Таким образом, теперь нет необходимости прописывать "route…" в Advanced configuration, все сети можно прописать в IPv4 Remote Network/s. То же самое с "push route" - все локальные для сервера сети можно прописать в IPv4 Local Network/s.

Если можно - подробнее про самостоятельное создание аналога negate rule.

Обратите внимание на следующее: любое policy based routing (PBR) правило направляет трафик в обход системной таблицы маршрутизации, т.е. на этот трафик системные маршруты не действуют, даже если они есть (pf routing: https://forum.pfsense.org/index.php?topic=73670.0). Поэтому, чтобы трафик между сетями подчинялся системным маршрутам, необходимо перед PBR правилом поставить другое - из нужной сети в нужную сеть с gateway = default. Это именно то, что и делают скрытые negate rules - перед каждым PBR правилом разрешают трафик из всех подключенных сетей во все подключенные сети. Очевидно, разработчики пришли к выводу, что это медвежья услуга - лучше, чтобы оператор сам контролировал кого куда пускать.

По поводу negate_networks> на клиентах. Проверил на 2.1.2
В tmp/rules.debug
table <vpn_networks>и table <negate_networks>Создаются\заполняются только при создании сервера, но не клиента OVPN.</negate_networks></vpn_networks>

А если на клиенте в IPv4 Remote Network/s прописать что-нибудь?

WY6EPT

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

а так же как уже выше описали при использовании атрибута Gateway в правиле сети можно исключить попадание клиента в любую сеть кроме внешней.

так же можно заготовить правило для копирования и просто переносить копию на вновь появившийся интерфейс. для запрета доступа к локальному интерфейсу шлюза.
допустим прописать его таким образом
reject
интерфейс клиента
протокол any
сурс эни
дест интерфейс_адресс

а в портах прописать алиас портов которые хочется прикрыть 22 80 443 и тд
днс в таком случае будет ходить

pigbrother

Поэтому, чтобы трафик между сетями подчинялся системным маршрутам, необходимо перед PBR правилом поставить другое - из нужной сети в нужную сеть с gateway = default

То есть то самое правило вида:
IPv4 * LAN net * remote_network/24 * * none
Так?

А если на клиенте в IPv4 Remote Network/s прописать что-нибудь?

Создал fake-клиента с такими настройками:

dev ovpnc1
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.126.128
tls-client
client
lport 0
management /var/etc/openvpn/client1.sock unix
remote 1.2.3.4 1194
ifconfig 10.0.22.2 10.0.22.1
route 10.0.0.10 255.255.255.0
ca /var/etc/openvpn/client1.ca 
cert /var/etc/openvpn/client1.cert 
key /var/etc/openvpn/client1.key 
tls-auth /var/etc/openvpn/client1.tls-auth 1

и в tmp/rules.debug

записи появились:

table <vpn_networks>{ 10.0.0.10/24 10.0.22.0/24 }
table <negate_networks>{ 10.0.0.10/24 10.0.22.0/24 }

Какой правильный вывод из этого следут сделать? Обязательно заполнять Remote Network/s и на клиенте?</negate_networks></vpn_networks>