```{index} docker
```


# Общая информация


## Создание новых файлов зон

Делаем по аналогии с существующими в каталоге роли (`roles/setup_firewalld`).

**"Зоны"** `firewalld` в нашем случае соответствуют **источникам** трафика,
сами источники --- IP адреса хостов и сети --- задаём с помощью `ipsets` (тоже
в файлах настроек `firewalld` в каталоге роли).

**ВАЖНО:** каждый IP адрес должен попадать только в **одну** зону. Если
составить правила (зоны) так, чтобы один адрес попадал сразу под два правила
(две зоны / два источника) --- срабатывать будет только одно из двух правил.


## Разрешение на выполнение / killswitch

Роль / плейбуки проверяют, разрешено ли им выполнение на данном хосте.

Переменная `inv_firewalld_allow_role` установлена в значение `no` по умолчанию
для всех хостов. Соответственно, плейбуки будут выполняться только на хостах,
для которых значение данной переменной специально установлено в `yes`.



## Недоработки / особенности, обратить внимание

```{attention}
* Если добавить новую зону в настройки, но не добавить соответствующий файл в
  `files/zones` или `templates/zones`, плейбук не выдаст ошибку, будет успешно
выполнен. Разумеется, новая зона не появится на хостах (файла не было и нет).

* Для полной очистки директории `/etc/firewalld` на хостах (до загрузки новой
  конфигурации) можно добавить `-e "firewalld_clear_etc_directory=True"` к
вызову плейбука, либо поменять соответствующую переменную в самом плейбуке.
Сейчас поведение по умолчанию --- не очищать директорию, только изменять
существующие и добавлять новые файлы. М. б. это изменится в будущем.
```


## FirewallD и Docker

Насколько вижу, сосуществуют ок (но не идеально / не без проблем!). Демон
докера во время старта создаёт все нужные ему таблицы / правила фаерволла ---
как при остановленном, так и при запущенном FirewallD. Правила докера и
FirewallD не конфликтуют, работают параллельно (используют таблицы и chains с
разными именами).

Если **остановить** FirewallD --- насколько вижу --- из `nft ruleset` исчезают
и правила, созданные докером. Перезапуск службы докера заново создаёт нужные
правила. Вывод: **не нужно останавливать FirewallD без крайней
необходимости**. Если остановил --- перезапусти docker.

Docker (при запуске/перезапуске) присваивает зону `trusted` (т.е. можно всё)
своим интерфейсам `dockerX` и `docker_gwbridge` (ограничения затем настраивает
отдельными правилами `iptables/nftables`.


Как проверить наличие правил докера --- есть здесь:
{ref}`nft_docker_chains`


## На крайний случай

Подготовлены плейбуки:

- `playbook/maintenance/firewalld/allow_all_traffic_polite.yml`
- `playbook/maintenance/firewalld/allow_all_traffic_FORCED.yml`
- `playbook/maintenance/firewalld/disable_firewalld_polite.yml`
- `playbook/maintenance/firewalld/disable_firewalld_FORCED.yml`

`allow_all_traffic` --- разрешает весь трафик (или большинство), установив для
интерфейса `ens192` зону `trusted` (можно всё). Настройка только runtime,
после `firewall-cmd --reload` или перезагрузки хоста снова будет активна
рабочая конфигурация FirewallD.

`disable_firewalld` --- отключает и останавливает службу FirewallD.

Вариант `polite` "уважает" разрешение `inv_firewalld_allow_role`,
вариант `FORCED` применяется к любому хосту.