У меня есть коробка CentOS 7 с 2 сетевыми картами, выступающими в качестве шлюза; одна сетевая карта подключена к Интернету, а другая сетевая карта подключена к нашей локальной сети.
Первая сетевая карта принадлежит «внешней» зоне firewalld, она маскируется и настроена на пересылку портов 22, 80 и 443 на те устройства внутри внутренней сети, которые управляют SSH и веб-серверами; предположим, что в Интернете поле отображается как «example.com» по адресу «1.2.3.4», а его имя в локальной сети - «gateway.lan» с адресом «192.168.1.1».
Все работает, со значительной оговоркой; поскольку мы хотим иметь возможность подключаться через SSH, используя Интернет-имя ящика (ssh example.com), также из локальной сети (где SSH-ящик называется "server.lan" и имеет адрес 192.168.1.10), единственный способ сделать эту работу, похоже, устанавливает правило во «внутренней» зоне firewalld, перенаправляющее все обращения к порту 22 из «1.2.3.4» обратно на порт 22 блока SSH:
internal (active)
target: default
icmp-block-inversion: no
interfaces: XXXXXX
sources:
services: dns
ports:
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family="ipv4" destination address="1.2.3.4" forward-port port="22" protocol="tcp" to-port="22" to-addr="192.168.1.10"
Само по себе правило не работает, если маскировка не включена для «внутренней» зоны; к сожалению, это также, очевидно, приводит к тому, что внешние IP-адреса, которые забивают этот ящик, пытаясь подобрать пароль root, отображаются как исходящие из «192.168.1.1» (адрес «gateway.lan») в журналах «server.lan», что делает невозможным использование Fail2Ban в поле «server.lan», чтобы препятствовать тысячам попыток доступа в день.
Что я делаю не так? Я думаю, что включение маскировки во «внутреннюю» зону концептуально неверно, но я не мог найти другого способа заставить работать правило firewalld. Я без колебаний продолжаю маскировку, но я хотел бы знать, как можно заставить Fail2Ban работать, находясь за шлюзом ...
Есть ли какой-либо совет по поводу любого другого способа заставить такую конфигурацию работать так, как я ожидаю?
Ах, мы сделали это! И это было относительно легко (ну, если вы знаете как) ...
Мы правильно предположили, что маскировка во «внутренней» зоне не должна быть включена глобально, а должна быть ограничена пакетами, исходящими из локальной сети, которые маршрутизируются на общедоступный IP-адрес.
Это означает, что нельзя включать его без разбора с --добавить маскарад для всей зоны, но с использованием маскарад ВНУТРИ конкретного расширенного правила в следующей форме:
firewall-cmd --zone=internal --permanent --add-rich-rule='rule family=ipv4 source address=192.168.1.0/24 destination address=192.168.1.10 masquerade'
Некоторое время нас вводил в заблуждение тот факт, что мы настаивали на использовании публичного IP «1.2.3.4» в качестве «адреса назначения» вместо внутреннего «192.168.1.10» в правиле; мы не поняли, что при прохождении через «внутреннюю» зону пакеты, нацеленные на порт 22 из «1.2.3.4», уже конвертируются с помощью правила rich в LAN-адрес блока SSH. Более того, этот синтаксис НЕ позволяет указывать порт.
Окончательный статус «внутренней» зоны следующий:
internal (active)
target: default
icmp-block-inversion: no
interfaces: XXXXXX
sources:
services: dns
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family="ipv4" destination address="1.2.3.4" forward-port port="22" protocol="tcp" to-port="22" to-addr="192.168.1.10"
rule family="ipv4" source address="192.168.1.0/24" destination address="192.168.1.10" masquerade
который:
Ура!