IPAddressAllow= и IPAddressDeny=: сетевой фильтр для службы
Задают, с какими адресами службе разрешено или запрещено обмениваться данными. Фильтр действует на уровне контрольной группы средствами ядра и не зависит от правил брандмауэра.
Что делает
Удобство в адресности: правило относится к одной службе, а не ко всей машине. Так можно запретить фоновой задаче выходить в интернет, оставив доступ к локальной сети — и не трогать общий брандмауэр.
Правила складываются: запрет проверяется после разрешения, и более точное совпадение подсети побеждает. Обычный приём — запретить всё и разрешить нужное.
Где ставится. В секции [Service]. Требует поддержки BPF в ядре.
Значения
| Значение | Что происходит |
|---|---|
IPAddressDeny=any | запретить весь обмен. |
IPAddressAllow=localhost | разрешить петлевой интерфейс. |
IPAddressAllow=10.0.0.0/8 | разрешить подсеть. |
IPAddressAllow=link-local multicast | именованные группы адресов. |
Пример
Служба, которой разрешена только локальная сеть.
[Service]
IPAddressDeny=any
IPAddressAllow=localhost 10.0.0.0/8
IPAccounting=yesС включённым учётом объём трафика службы видно в systemctl status — это удобно для разбора неожиданной активности.
Типичные ошибки
На ядре без поддержки BPF параметры молча не действуют: проверяйте, что фильтр реально работает.
Запрет применяется и к разрешению имён: без доступа к серверу имён служба не сможет ничего найти.
Это не замена брандмауэру: правила относятся только к этой службе и не защищают машину.
Связанные ошибки
- Connection refused в журнале службыСоединение отклонено: служба не может подключиться к базе, кешу или другому сервису. Порядок запуска, адрес, брандмауэр.
- status=244/BPF в systemdКод 244/BPF: не удалось применить ограничения через BPF, например RestrictFileSystems=. В man-странице systemd этот код указан неверно.
Рядом стоящие параметры
Источники
- systemd.resource-control(5)
- Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)