МАРШРУТИЗАЦИЯ, FIREWALL, NAT И PORT FORWARDING Продукт: Control Center Версия: [ТРЕБУЕТ УТОЧНЕНИЯ: VERSION] Тип документа: Руководство по сетевой безопасности и маршрутизации Последнее обновление: 09.09.2026 ЧТО МЫ НАСТРОИМ Документ описывает явное включение маршрутизации между сетями, управление firewall, NAT и port forwarding. Эти функции не включаются автоматически при наличии WAN и LAN. КРИТИЧЕСКОЕ ПРАВИЛО По умолчанию сервер Control Center не должен становиться маршрутизатором только из-за multi-NIC. Forwarding, routing и NAT должны быть осознанно включены отдельным Change. ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ Требование | Значение Сеть | Интерфейсы/зоны настроены по документу 07 Доступ | Console/OOB или резервный management path IP plan | Известны source/destination networks и gateways Security policy | Определены разрешенные flows Backup | Актуален перед изменением критической network policy Права | Network/Firewall administration Validation | Должен быть доступен preview/staged apply [ТРЕБУЕТ УТОЧНЕНИЯ] АРХИТЕКТУРА LAN ---- [Control Center Node] ---- WAN | X | X нет forwarding по умолчанию | разрешается только явной policy Если routing включен: Source Zone → Route/Forward Policy → Firewall Policy → Optional NAT → Destination Zone. ПЕРЕД НАЧАЛОМ 1. Зафиксируйте текущие routes и firewall policy. 2. Определите минимально необходимый flow. 3. Не создавайте «allow any any» ради диагностики. 4. Не публикуйте административный Web UI наружу без отдельного защищенного design. 5. Подготовьте тест с обеих сторон policy и автоматический rollback. Для Linux текущая L3-картина: ```bash ip route ip rule ip -br addr ``` Проверка forwarding ОС как диагностический факт, а не инструкция по включению: ```bash sysctl net.ipv4.ip_forward ``` Ожидаемый безопасный baseline, если маршрутизация не нужна: `net.ipv4.ip_forward = 0` либо эквивалентная политика, при условии что Control Center не использует иной поддерживаемый механизм. Не меняйте sysctl вручную в обход Desired State Control Center. РАЗДЕЛ A. ЯВНАЯ МАРШРУТИЗАЦИЯ Шаг 1. Определите маршрут Запишите: - source zone/network: ; - destination network: ; - next hop: или directly connected; - интерфейс/zone; - нужен ли forwarding между интерфейсами; - требуется ли NAT. Шаг 2. Создайте route/forward policy 1. Откройте сетевые маршруты [Уточнить название элемента интерфейса]. 2. Добавьте только необходимую destination network. 3. Укажите next hop/interface. 4. Если требуется межинтерфейсный forwarding, включите его явно только для нужной policy/zone pair [ТРЕБУЕТ УТОЧНЕНИЯ: модель реализации]. 5. Просмотрите diff. 6. Выполните validation. 7. Примените staged Change. Что изменится: Узел получит возможность отправлять или пересылать трафик к указанной сети. Риск: Ошибочный route/default route может направить management traffic неверным путем или открыть транзит между зонами. Проверка: ```bash ip route get ``` На клиенте проверьте только разрешенный flow. Rollback: Удалите созданную route/forward policy обратным Change. При потере management connectivity используйте staged auto-rollback/OOB. РАЗДЕЛ B. FIREWALL Базовый принцип: deny-by-default для неразрешенного входящего/межзонного трафика, затем точечные правила по необходимости. Шаг 3. Создание firewall rule Перед созданием определите: - source zone/CIDR; - destination zone/address; - protocol; - destination port/range; - direction; - action allow/deny; - reason/owner; - срок действия для временного правила, если поддерживается. 1. Откройте firewall policy [Уточнить название элемента интерфейса]. 2. Создайте максимально узкое правило. 3. Проверьте порядок/priority. 4. Используйте preview. 5. Примените staged Change. 6. Проверьте только нужный сервис. Что изменится: Трафик, соответствующий правилу, будет разрешен или запрещен согласно action. Риск: Можно потерять административный доступ либо открыть сервис шире планируемого. Rollback: Временно созданное правило удаляется/отключается обратным Change. Не отключайте firewall целиком. Шаг 4. Изменение management firewall Если правило затрагивает текущую административную сессию: 1. откройте вторую console/OOB сессию; 2. включите staged rollback; 3. добавляйте новое разрешение ДО удаления старого; 4. подтвердите новый путь; 5. только затем удалите старое правило. Это правило особенно важно при смене management subnet. РАЗДЕЛ C. NAT NAT используется только если он нужен сетевому дизайну. Не включайте masquerade для всего LAN автоматически. Шаг 5. Исходящий NAT/SNAT Запишите: - source: ; - egress zone/interface: ; - destination scope, если ограничивается; - translation type/address. 1. Откройте NAT policy [Уточнить название элемента интерфейса]. 2. Создайте правило только для нужной source network. 3. Ограничьте destination, если возможно и требуется. 4. Проверьте related firewall forwarding rule. 5. Preview → Change → verification. Что изменится: Исходящий трафик будет получать преобразованный source address. Риск: Слишком широкое правило превращает сервер в общий gateway и скрывает нежелательный транзит. Проверка: С клиента выполните разрешенный outbound test и убедитесь, что другие сети не получили незапланированный Internet access. Rollback: Удалите NAT rule, затем проверьте, что forwarding policy соответствует исходному состоянию. РАЗДЕЛ D. PORT FORWARDING / DNAT ПРЕДУПРЕЖДЕНИЕ: port forwarding публикует внутренний сервис через другой адрес/зону. Перед публикацией оцените необходимость, authentication, TLS, rate limiting и firewall source restrictions. Шаг 6. Планирование port forward Параметр | Пример-placeholder Внешняя zone/IP | Внешний порт | Протокол | tcp/udp Внутренний адрес | Внутренний порт | Разрешенный source | Шаг 7. Создание DNAT/forward 1. Создайте точечное port-forward правило [Уточнить название элемента интерфейса]. 2. Укажите protocol и один требуемый port/range. 3. Укажите внутренний target. 4. Ограничьте source addresses, если это возможно. 5. Создайте/проверьте соответствующее firewall правило. 6. Preview → staged Change. 7. Выполните внешний тест. Не используйте диапазон 1-65535 как способ «быстро проверить». Ожидаемый результат: Только заданный внешний flow достигает конкретного внутреннего сервиса. Проверка: Используйте клиент в соответствующей внешней сети и штатный клиент протокола. Для TCP, если доступен `nc`: ```bash nc -vz ``` Проверяйте также, что соседний неразрешенный порт закрыт. Rollback: Удалите DNAT/port-forward и связанное разрешающее firewall rule. Повторно проверьте извне. Шаг 8. Проверка отсутствия непреднамеренного router mode После всех изменений убедитесь: - forwarding включен только там, где предусмотрено; - нет catch-all NAT; - нет неожиданного default route; - межзонные политики минимальны; - административный интерфейс не опубликован случайно. В Linux можно проверить маршруты: ```bash ip route ip rule ``` Для фактических firewall/NAT rules используйте только поддерживаемое Control Center представление или документированную диагностическую команду версии. Не предполагается конкретный backend nftables/iptables без подтверждения. ПРОВЕРКА ПОСЛЕ НАСТРОЙКИ - [ ] WAN+LAN сами по себе не дают transit; - [ ] каждый route имеет назначение; - [ ] forwarding ограничен нужными зонами; - [ ] firewall следует least privilege; - [ ] нет allow-any-any без формального обоснования; - [ ] NAT ограничен необходимой сетью; - [ ] port forwarding ограничен protocol/port/source; - [ ] management path сохранен; - [ ] staged rollback доступен; - [ ] Audit содержит изменения; - [ ] внешний negative test выполнен. ТИПОВЫЕ ОШИБКИ Симптом | Причина | Проверка | Решение После firewall change потерян доступ | правило заблокировало management | OOB + policy diff | auto-rollback/вернуть предыдущее правило LAN получил Internet неожиданно | broad NAT/forward | NAT/forward policies | сузить/удалить policy Port forward не работает | DNAT есть, firewall/route отсутствует | flow chain | добавить только недостающее разрешение Сервис открыт всему Internet | source не ограничен | external test/policy | ограничить source/VPN/proxy design Ассиметричный routing | несколько gateways/policy mismatch | ip route get/ip rule | исправить route policy РЕКОМЕНДАЦИИ ДЛЯ PRODUCTION - предпочитайте VPN/reverse proxy/zero-trust gateway прямому открытию admin ports, если это поддерживает инфраструктура; - логируйте deny/allow разумно, избегая log flood; - задавайте owner/reason для firewall rules; - удаляйте временные правила; - тестируйте negative case: что должно быть недоступно; - разделяйте WAN, LAN и Management zones; - не используйте Control Center как router только потому, что это технически возможно. ИТОГ Routing, firewall, NAT и port forwarding являются управляемыми, но явно включаемыми функциями. Без отдельной policy multi-NIC Control Center не должен пересылать трафик между WAN и LAN. Все изменения выполняются с preview, staged validation, проверкой и rollback. ТРЕБУЕТ УТОЧНЕНИЯ ПЕРЕД ПУБЛИКАЦИЕЙ - VERSION; - точная route/forwarding data model; - firewall backend и UI names; - supported protocols/features; - NAT/SNAT/DNAT options; - policy ordering/priority; - logging options; - staged rollback timing; - IPv6 forwarding/firewall/NAT scope.