systemd service - udp broadcast не может достичь другой машины

systemd service - udp broadcast не может достичь другой машины

У меня есть служба, расположенная в /usr/lib/systemd/system. Эта служба запускает приложение, которое я разрабатываю (.net core 2.0). Одно и то же приложение работает на разных машинах (обе centos7). Они используют сокеты udp для поиска друг друга.

Я очень долго тестировал это приложение, прежде чем подготовиться..услугафайл для них и все работало отлично. Они могли транслировать сообщения друг другу.

Когда служба запускает приложение, единственное сообщение, которое может получить экземпляр, это то, которое этот экземпляр транслировал изначально. Та же ситуация на других машинах. Они могут получать свои собственные трансляции, но не чужие.

Так как я новичок в Linux и не знаю, где искать и что именно искать, я наткнулся на бесполезную информацию, и поэтому мне нужна помощь.

Спасибо


содержимое файла .service

[Unit]
Description=Apix

[Service]
WorkingDirectory=/apix
ExecStart=/usr/bin/dotnet /APIX/Apix.dll

[Install]
WantedBy=multi-user.target

Когда я сам запускаю приложение, я вижу, что udp-port используется dotnet. Но когда служба запускает приложение, эта строка исчезает.

netstat -lntup
udp    0   0 0.0.0.0:14235    0.0.0.0:*     11319/dotnet

решение1

Livejournal Дэна Уолша за 2014 годесть описание unconfined_service_t, хотя оно настолько перегружено жаргоном SELinux, что, боюсь, вы вряд ли извлечете из него много пользы при вашем текущем уровне знаний SELinux.

Согласно вашим комментариям, метки SELinux для этого процесса были следующими:

  • при запуске с помощью файла .service:system_u:system_r:unconfined_service_t:s0
  • при ручном запуске:unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Метки SELinux состоят из четырех частей:

  • Пользователь SELinux (с _uсуффиксом)
  • Роль SELinux (с _rсуффиксом)
  • Тип SELinux (с _tсуффиксом)
  • и определение уровня SELinux, которое используется только с полнымМногоуровневая безопасностьПолитика SELinux (военная безопасность и т.п.), не соответствующая политике по умолчаниюцелевыеполитика.

В политике SELinux по умолчанию идентификатор пользователя SELinux отличается от вашего обычного имени пользователя: по сути, SELinux не заботится о том, кому именно принадлежат файлы или процессы, а только о том, являетесь ли вы важным системным процессом или чем-то, запущенным одним из них ( system_u), администратором ( sysadm_u), обычным пользователем ( user_u) или чем-то, что было указано как не имеющее ограничений политикой SELinux ( unconfined_u).

Часть роли можно использовать для указания нескольких ролей «частичного администратора», например, dbadm_rдля администрирования базы данных или logadm_rдля доступа к системным журналам.

Самая важная часть, касающаясяцелевыеПолитика SELinux — это спецификация типа или часть с _tсуффиксом.

unconfined_service_tдолжен быть типом unlimited, поэтому я не уверен, что там не так. Возможно, файлы в /APIX/дереве каталогов все не помечены, и это может быть причиной проблем?

Как и процессы, файлы также должны иметь метку SELinux, которую можно просмотреть с помощью ls -Z. В общем, SELinux выдает default_tдля любых файлов, у которых не указана метка. Столкнувшись с default_t, SELinux «думает»: «Я не знаю, что это такое; это может быть Ultra Top Secret, который потерял свою метку, поэтому давайте сохраним его в особом секрете, пока какой-нибудь администратор не скажет нам правильную метку для него». Короче говоря, default_tэто то, что вам нужно исправить.

Файлы обычно наследуют маркировку каталога, в котором они находятся во время создания, если только не указано правило SELinux, которое говорит об обратном. Но если вы создаете новый каталог верхнего уровня, например /APIX, вам нужно решить, как его маркировать, иначе вы получите default_t, что может вызвать проблемы.

Вы можете попробовать установить semanage permissive -a unconfined_service_t: он разрешает любые службы, использующие unconfined_service_tсвободный доступ, при этом регистрируя любые нарушения политики SELinux, как /var/log/auth/будто SELinux был полностью включен для них. Затем запуск audit2whyсоответствующей части журнала аудита должен дать вам более четкое описание того, почему SELinux блокирует выполнение программой того, что она хочет сделать.

Правильным решением может быть простое присвоение каталогу /APIX/подходящей метки файловой системы.

Связанный контент