изоляция веб-сервера в локальной сети

Просто используй другую сеть на ether5, затем заблокируй связь между сервером и локальной сетью в цепочке перенаправления firewall. Сначала проверь, что ether5 не является подчинённым — в стандартной конфигурации ether2 выступает мастером для ether3-5.

Я пробовал это, но не получилось, потому что даже если сети разные, маршруты известны RB из таблицы маршрутизации. Я также пытался создать правило в фаерволе, блокирующее весь трафик с сети 1 на сеть 2, но не сработало — ICMP как обычно проходил между двумя сетями.

Будьте осторожны, чтобы не тестировать это, пингуя интерфейс «DMZ» Mikrotik из LAN и не делать вывод, что ICMP разрешен. Даже если у вас есть клиент с адресом 192.168.2.44, который пытается пинговать серверную сеть 192.168.3.1 (интерфейс Mikrotik в серверной сети), этот трафик не попадает в цепочку forward, а идет в цепочку input.

Похоже, что перед правилом блокировки у вас есть другое правило, которое разрешает трафик. Возможно, это просто простое правило «разрешить ICMP» — тогда пинги между сетями проходят, а вот остальное нет (никакого обмена файлами, http и прочего). Пробовали заходить на какие-нибудь сервисы через роутер? (отдалённый рабочий стол — простой тест). В любом случае внимательно посмотрите на цепочку forward и выясните, какое правило пропускает пинги (а может, и все сервисы) через файрвол. Я бы поставил на ICMP или на какое-то странно настроенное правило с перекрученой логикой.

Сделайте вот так для фильтров переадресации вашего файрвола: (номер индекса я оставил такой же, как в ваших текущих правилах, чтобы вам было проще их переупорядочить)

0 ;;; Отбросить недействительные пакеты в цепочке forward chain=forward action=drop connection-state=invalid  
4 ;;; Переадресация – все установленные и связанные состояния – принять chain=forward action=accept connection-state=established,related  
3 ;;; Переадресация – новое состояние из DMZ на www – принять chain=forward action=accept out-interface=ether1  
1 X ;;; Переадресация – принять новое состояние из локальной сети в DMZ chain=forward action=accept src-address-list=RedesLocais out-interface=DMZ-INTERFACE-NAME (с этого момента любой пакет ОБЯЗАН находиться в новом состоянии, так что проверять это в остальных правилах не нужно)  
2 ;;; Переадресация – порты с dst-nat – принять chain=forward action=accept connection-nat-state=dstnat protocol=tcp in-interface=ether1 dst-port=80,8081,3389,37777,22,5060  
5 ;;; Переадресация – SSH порт в DMZ из локальных сетей – принять chain=forward action=accept protocol=tcp src-address-list=RedesLocais out-interface=DMZ-INTERFACE-NAME dst-port=22 (обратите внимание, это правило не нужно, если правило 1 X ;;; активировано, но я предполагаю, что вы тестируете)  
6 ;;; Переадресация – отбросить всё из DMZ в локальную сеть chain=forward action=drop src-address=192.168.16.252 dst-address=10.2.2.0/24 log=no log-prefix=“”  
7 ;;; Переадресация – новое состояние из локальной сети – принять chain=forward action=accept connection-state=new src-address-list=RedesLocais log=no log-prefix=“” (правила 6 и 7 не обязательны)  
8 ;;; Переадресация – отбросить всё остальное chain=forward action=drop

Потому что последнее правило отбрасывает любой пакет, который до него добирается. Если ты нигде в более раннем правиле не разрешаешь пакеты из DMZ в LAN, то в итоге они достигнут финального правила, где попадут в чёрную дыру «отбросить все пакеты». Представь цепочку как падение в яму. Каждое правило — это ветка дерева, растущая с края ямы, за которую пакет может зацепиться, если он соответствует условиям. Если ветки нет — пакет падает вниз и разбивается.

Кстати, правило 7 не нужно, потому что правило 3 было изменено так, что принимает любой пакет, который выходит через интерфейс WAN, независимо от того, откуда он пришёл. Правило 7 никогда ничего не «застанет», потому что всё уже прошло через правило 3. Так что проверять его лишний раз — зря тратить ресурсы процессора.

Цепочке srcnat нужна только одна правило: действие=masquerade, интерфейс выхода=ether1. Еще одной возможной причиной может быть то, что у вас адреса DMZ находятся в списке локальных адресов.

Я протестировал правила, которые ты предложил, и они действительно сработали. Теперь я не могу пинговать с dmz в lan, а SSH-соединение работает, даже без правила, разрешающего TCP-порт 22. Но я думаю не принимать все новые пакеты из lan в dmz, а только на те порты, которые мне реально нужны. Вот и всё, большое спасибо за помощь. PS... Я не знаю, как тебя оценить и повысить твою репутацию.