BUG! bogon vs. filter.inc (RFC6598)
-
2.2-RELEASE (i386) и ранее: есть серьезная ошибка в файле /etc/inc/filter.inc, не позволяющая клиентам из сети вашего же провайдера подключаться к вашим серверами за pfSense даже при снятом флажке Interfaces - WAN/DMZ - Block bogon networks!
Ситуация возникает, если ваш провайдер (как Ростелеком, например) использует сеть:
100.64.0.0/10 100.64.0.0–100.127.255.255 Used for communications between a Service Provider and its subscribers when using a Carrier-grade NAT, as specified by RFC 6598. (из https://forum.pfsense.org/index.php?topic=67194.0)
Проверка на наличие бага через ssh shell: pfctl -s rules | grep "100.64" выдает что-то типа
block drop in log quick on rl0 inet from 100.64.0.0/10 to any label "Block private networks from WAN block 100.64/10"
Ключевое слово здесь "private" - но данная сеть не относится к приватным по RFC 1918! Это "серая" сеть для ISP по RFC 6598, и пакет из этой сети может придти к вам на WAN интерфейс из сети провайдера и причем он будет абсолютно легальным смаршрутизированным без выхода в Интернет пакетом от клиента (DSL пользователь, например, в случае Ростелекома). Адрес этой сети заботливо придет к вам от files.pfsense.org в таблицу "bogons" (Diagnostics - Tables). Причем обновление таблицы "bogons" отключить из web-интерфейса pfSense нельзя. Для разрешения пакетов в Interfaces cнимаем флажок "Block bogon networks", делаем перезагрузку pf фильтра Status - Filter Reload, проверяем снова в ssh shell: pfctl -s rules | grep "100.64" - правило блокировки никуда не делось! Через pfctl удалять правило из текущего состояния смысла никакого нет, после перезагрузки оно появится снова. Смотрим cat /etc/inc/filter.inc | grep "100.64" и видим такую строчку:
block in $privnetlog quick on ${$oc['descr']} from 100.64.0.0/10 to any tracker {$increment_tracker($tracker)} label "{$fix_rule_label("Block private networks from {$oc['descr']} block 100.64/10")}"
- вот этой строчки здесь вообще не должно быть, без нее включение/выключение блокировки "Block bogon networks" из web-интерфейса будет работать как положено по смыслу.
Временное решение - сделать резервную копию (cp filter.inc filter.0.inc), закомментировать в ssh shell с помощью vi эту строчку в filter.inc
vi filter.inc
/ 100.64
i<escape>:wq
и сделать перезагрузку pf фильтра. После перезагрузки шлюза pfSense это исправление должно остаться (до обновления firmware по-крайней мере).
P.S.: Честно говоря, это конкретная подстава со стороны разработчиков.
P.P.S.: Чтоб не извращаться с vi, кто-нибудь знает как поставить mc в pfSense 2.2? (в 2.1 известно, загрузкой с инета)</escape> -
P.P.S.: Чтоб не извращаться с vi, кто-нибудь знает как поставить mc в pfSense 2.2? (в 2.1 известно, загрузкой с инета)
А чем плох встроенный редактор:
Diagnostics: Edit file
-
Diagnostics: Edit file
Круто! :) Не знал… Спасибо!
-
total commander + sftp plugin
-
-
странно, в свежем FAR в бывшем ftp плагине (теперь NetBox называется) есть поддержка SCP, но не смог он подключиться к pfSense 2.2…
-
странно, в свежем FAR в бывшем ftp плагине (теперь NetBox называется) есть поддержка SCP, но не смог он подключиться к pfSense 2.2…
SSH в pfSense включен?
-
SSH в pfSense включен?
Да, конечно. Захожу по ssh иногда. По SFTP из FAR NetBox тоже вылетает (говорит что-то про большой объем данных, идущих от pfSense).
-
Промежуточный результат обсуждения с разработчиками (ветка https://forum.pfsense.org/index.php?topic=88215.0):
сказали, что сеть 100.64.0.0/10 будет исключена из автоматически обновляемого файла /etc/bogons (Should be removed from there - https://redmine.pfsense.org/issues/4379)