Коротко — идея в целом рабочая и у вас действительно получился «DMZ‑сегмент» с pfSense в нём и пробросом портов на внутренний NextCloud. Но есть несколько нюансов, на которые стоит обратить внимание: порядок правил, дублирование NAT, возможные дыры в изоляции и удобные варианты для «loopback» (доступ к сервису по публичному имени из внутренней сети). Ниже — разбор и рекомендации.
1) Корректность базовой схемы
- Схема (Mikrotik — DMZ(172.16.100.0/24) — pfSense(WAN 172.16.100.2) — LAN(172.16.101.0/24) — NextCloud) логична и рабочая. Port‑forward на MikroTik → pfSense, а на pfSense → NextCloud — нормально работает.
- Есть двойной NAT (pfSense NAT для своей LAN → WAN, и Mikrotik NAT WAN→публичный IP). Двойной NAT не опасен сам по себе, но усложняет диагностику, может мешать некоторым приложениям/фичам (UPnP, некоторые P2P, VPN passthrough/MTU вопросы) и усложняет hairpin/NAT‑reflection.
2) Что проверить/поправить в текущей конфигурации Mikrotik
- Порядок правил в Firewall критичен. Убедитесь, что у вас есть правила accept для connection‑state=established,related в chains input/forward перед drop‑правилами. Иначе легитимный трафик будет блокироваться.
Пример (фильтр forward):
1) accept connection‑state=established,related
2) accept in-interface=bridge (или LAN специфичные правила)
3) drop in‑interface=bridge_dmz out‑interface=bridge
- Правило input: drop in.interface=bridge_dmz — корректно для блокировки доступа к самому роутеру, но проверьте, не блокирует ли оно возвращаемый трафик (на established/related правило должно быть выше).
- Если вы включили masquerade/masq на bridge_dmz (NAT исходящего) — подумайте, действительно ли это нужно (см. дальше).
3) NAT-дублирование — варианты и рекомендации
- Вариант A — оставить NAT только на Mikrotik (простая схема для публикуемого сервиса):
- Отключить outbound NAT (masquerade) в pfSense (или перевести на «manual» и исключить сеть 172.16.101.0/24), а на Mikrotik настроить NAT/masquerade для исходящих из DMZ (или только для адреса pfSense WAN). Тогда Mikrotik будет производить выходную NAT на публичный IP и двойного NAT не будет.
- Альтернатива: сделать так, чтобы Mikrotik просто маршрутизировал 172.16.101.0/24 через 172.16.100.2 (добавить маршрут) и не маскарадинговал эти адреса, тогда pfSense сам будет NATить (или не NATить — в зависимости от нужд). Это требует добавления статического маршрута на Mikrotik: /ip route add dst-address=172.16.101.0/24 gateway=172.16.100.2
- Вариант B — оставить NAT и на Mikrotik, и на pfSense (двойной NAT). Работает, но имейте в виду потенциальные проблемы (VPN, MTU, сложность диагностики). Для простоты управления порты лучше пробрасывать только на одном устройстве (вы уже делаете port 11111→pfSense и дальше →NextCloud — это нормально).
4) NAT loopback (hairpin) и удобные альтернативы
- Проблема: если из вашей основной сети 192.168.1.0/24 вы пытаетесь открыть публичный домен (с направлением на публичный IP / Mikrotik) — трафик может не корректно петлить назад на NextCloud, особенно при двойном NAT.
- Варианты решения:
A) Split‑DNS (рекомендую). Настроить локальный DNS (на Mikrotik, pFsense или отдельный DNS) так, чтобы имя cloud.example.com в вашей локальной сети резолвилось в 172.16.101.2. Это самый простой, быстрый и надёжный способ. В pfsense: Services → DNS Resolver / Host Overrides.
B) NAT reflection (loopback) на pfsense. pfSense умеет NAT reflection, но в вашей схеме пакеты из LAN→публичный IP сначала заходят в Mikrotik, поэтому нужно обеспечивать редирект на Mikrotik или делать соответствующие dst-nat+src-nat на Mikrotik.
C) Hairpin на Mikrotik: пример (если публичный IP = x.x.x.x и сеть LAN клиента 192.168.1.0/24):
- dst-nat: chain=dstnat dst-address=x.x.x.x dst-port=11111 protocol=tcp action=dst-nat to-addresses=172.16.100.2 to-ports=11111
- src-nat (для клиенты→сервер): chain=srcnat src-address=192.168.1.0/24 dst-address=172.16.100.2 action=masquerade
Это заставит Mikrotik подменять источник, чтобы ответ корректно пошёл к клиенту. Но hairpin усложняет логику и лучше заменить split‑DNS.
5) Безопасность — что обязательно/рекомендую
- Минимизировать открытые порты: пробрасывайте только 1 порт (используемый 11111 → 443) — это уже хорошо.
- Ограничьте доступ по IP/Rate limiting:
- На Mikrotik можете добавить limit/connection rate limit rules для порта 11111 (или использовать Firewall filter/ip service).
- На pfSense в правилах WAN for pfsense добавьте source‑address restriction, если возможно (только нужные сети).
- Защита pfSense: доступ к WebGUI/SSH pfSense только из trusted LAN (192.168.1.0/24) и/или только через VPN.
- На NextCloud:
- TLS (хороший сертификат — Let's Encrypt).
- Включить 2FA, brute‑force protection (fail2ban/CSF or NextCloud apps), авт. обновления/регулярные обновления.
- Ограничить административные панели по IP и отключить ненужные сервисы.
- Логи/мониторинг: логируйте и периодически проверяйте попытки доступа. Настройте алерты на множественные неудачные подключения.
- Backup: регулярные бэкапы NextCloud данных и конфигураций.
- Защита от сканирования: можно на Mikrotik ограничить количество новых соединений в секунду на публичном порту и/или применить port knocking/стандартные механизмы.
6) Изоляция DMZ
- Правило forward: drop in.interface=bridge_dmz out.interface=bridge — логично, но будьте точны: нужно оставить доступ к интернету (out.interface=WAN), разрешить established/related. Также явно запретите DMZ→Proxmox management IPs/192.168.1.1 и другие критические сервисы.
- Убедитесь, что Proxmox management (web интерфейс) недоступен из DMZ и из WAN; лучше держать Proxmox на отдельной сети доступной только из админской VLAN через VPN.
7) Производительность и надежность
- RB951 — устройство не очень мощное. Проверяйте загрузку CPU при пиковых соединениях/SSL. TLS на pfSense (если pfSense делает TLS) и NAT на Mikrotik создают нагрузку. При высокой нагрузке подумайте о более производительном устройстве или вынесении TLS на облако/балансировщик.
- Резервирование: если нужно больше надежности, рассмотрите запасной канал/хостинг/облачный шлюз или HA pfSense (более сложная схема).
8) Короткий чек‑лист действий «срочно/рекомендуется»
- [ ] Убедиться, что established/related правила стоят выше drop.
- [ ] Убрать/упорядочить лишний NAT (решите, где NAT должен быть: Mikrotik или pfSense) либо добавить маршрут 172.16.101.0/24 на MikroTik, если хотите, чтобы Mikrotik знал эту сеть.
- [ ] Настроить split‑DNS для внутреннего доступа к домену NextCloud.
- [ ] Ограничить доступ к админ-интерфейсам (Mikrotik, pfSense, Proxmox) только с доверенных сетей/VPN.
- [ ] Настроить rate‑limit / fail2ban / WAF / сильный TLS и 2FA для NextCloud.
- [ ] Логи и мониторинг.
Если нужно — могу:
- Проверить ваши конкретные правила firewall/nat (скопируйте вывод /ip firewall filter print и /ip firewall nat print) и подсказать правки по порядку/условиям.
- Подготовить точные команды для Mikrotik (dst-nat/hairpin, правила accept/established, удаление ненужного masquerade) и/или конфигурацию NAT Reflection или split‑DNS в pfSense.
Хотите, чтобы я проверил ваши текущие правила и предложил конкретные правки по командам?