serviço systemd - a transmissão udp não pode alcançar outra máquina

serviço systemd - a transmissão udp não pode alcançar outra máquina

Eu tenho um serviço localizado em/usr/lib/systemd/system. Este serviço executa o aplicativo que estou desenvolvendo (.net core 2.0). O mesmo aplicativo é executado em máquinas diferentes (centos7 ambos). Eles usam soquetes udp para se encontrarem.

Estou testando este aplicativo há muito tempo antes de me preparar.serviçoarquivo para eles e tudo estava funcionando muito bem. Eles foram capazes de transmitir mensagens um para o outro.

Quando o serviço executa o aplicativo, a única mensagem que a instância pode receber é aquela que a mesma instância estava transmitindo em primeiro lugar. Mesma situação nas outras máquinas. Eles podem obter suas próprias transmissões, mas não as dos outros.

Como sou novo no Linux e não tenho certeza de onde procurar e o que devo pesquisar, me deparei com algumas informações inúteis e é por isso que preciso de ajuda aqui.

Obrigado


conteúdo do arquivo .service

[Unit]
Description=Apix

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

[Install]
WantedBy=multi-user.target

Quando eu mesmo inicio o aplicativo, posso ver que a porta udp está sendo usada pelo dotnet. Mas quando o serviço executa o aplicativo, essa linha desaparece.

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

Responder1

Livejournal de Dan Walsh de 2014tem uma descrição de unconfined_service_t, embora seja tão pesado no jargão do SELinux que temo que você não aproveite muito com seu nível atual de conhecimento do SELinux.

De acordo com seus comentários, os rótulos do SELinux para o processo foram:

  • quando iniciado com um arquivo .service:system_u:system_r:unconfined_service_t:s0
  • quando iniciado manualmente:unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Os rótulos SELinux têm quatro partes:

  • Usuário SELinux (com o _usufixo)
  • Função SELinux (com o _rsufixo)
  • Tipo SELinux (com o _tsufixo)
  • e uma definição de nível SELinux, que só é usada com uma versão completaSegurança multinívelPolítica SELinux (segurança militar e similares), não com o padrãovisadaspolítica.

Na política padrão do SELinux, o identificador de usuário do SELinux é diferente do seu nome de usuário normal: na verdade, o SELinux não se importa com exatamente a quem pertencem quaisquer arquivos ou processos, apenas se você é um processo essencial do sistema ou algo iniciado por um ( system_u) , um administrador ( sysadm_u), um usuário comum ( user_u) ou algo que tenha sido especificado como irrestrito pela política do SELinux ( unconfined_u).

A parte role pode ser usada para especificar diversas funções de "administrador parcial", como dbadm_rpara administração de banco de dados ou logadm_rpara acesso a logs do sistema.

A parte mais importante em relação aovisadasA política SELinux é a especificação do tipo ou a parte com o _tsufixo.

unconfined_service_tdeve ser um tipo irrestrito, então não tenho certeza do que está errado aí. Talvez todos os arquivos na /APIX/árvore de diretórios não estejam rotulados e isso possa estar causando os problemas?

Assim como os processos, os arquivos também devem ter um rótulo SELinux, visível com ls -Z. Em geral, o SELinux fornece um default_tpara qualquer arquivo que não tenha rótulo especificado. Quando confrontado com default_t, o SELinux "pensa": "Não sei o que é isso; pode ser o Ultra Top Secret que perdeu seu rótulo, então vamos mantê-lo extremamente seguro até que algum administrador nos diga o rótulo adequado para ele." Resumindo, default_té algo que você precisa consertar.

Os arquivos normalmente herdarão a rotulagem do diretório em que estão no momento da criação, a menos que haja uma regra SELinux especificada que diga o contrário. Mas se você criar um novo diretório de nível superior como /APIX, precisará decidir como rotulá-lo, ou então acabará com default_t, o que pode causar problemas.

Você pode tentar configurar semanage permissive -a unconfined_service_t: permite qualquer serviço usando unconfined_service_tacesso gratuito, enquanto ainda registra quaisquer violações da política do SELinux como /var/log/auth/se o SELinux estivesse totalmente habilitado para eles. Em seguida, executar audit2whya parte relevante do log de auditoria deve fornecer uma descrição mais clara do motivo pelo qual o SELinux está impedindo o programa de fazer algo que deseja.

A correção correta pode ser simplesmente rotular o /APIX/diretório com um rótulo de sistema de arquivos adequado.

informação relacionada