Eu tenho um servidor que está executando o libvirtd. Acabei de verificar as portas libvirtd e veja a saída abaixo. Eu me perguntei por que o PID da porta 16514 é sempre 1 e por que o tcp6 está lidando com ipv4 com múltiplas conexões.
Alguém pode me avisar.
root@prd-140:~# netstat -anpt |grep 16514
tcp6 0 0 :::16514 :::* LISTEN 1/systemd
tcp6 0 0 10.1.6.140:16514 10.2.127.52:60556 ESTABLISHED 12289/libvirtd
tcp6 0 0 10.1.6.140:16514 10.2.127.52:29463 ESTABLISHED 12289/libvirtd
root@prd-140:~# lsof -i :16514
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd 1 root 59u IPv6 9761899 0t0 TCP *:16514 (LISTEN)
libvirtd 12289 root 5u IPv6 9761899 0t0 TCP *:16514 (LISTEN)
libvirtd 12289 root 30u IPv6 20539283 0t0 TCP prd-140:16514->10.2.127.52:60556 (ESTABLISHED)
libvirtd 12289 root 35u IPv6 20549679 0t0 TCP prd-140:16514->10.2.127.52:29463 (ESTABLISHED)
Responder1
- A primeira parte é sobre a ativação baseada em soquete do systemd.
- A segunda parte é sobre o manuseio de pilha dupla IPv4/IPv6
ativação baseada em soquete do systemd
Um arquivo de configuração de unidade cujo nome termina em ".socket" codifica informações sobre um IPC ou soquete de rede ou um sistema de arquivos FIFO controlado e supervisionado pelo systemd, porativação baseada em soquete.
Para cada unidade de soquete, deve existir uma unidade de serviço correspondente [...]
Observe que o software daemon configurado para ativação de soquete com unidades de soquete precisa ser capaz de aceitar soquetes do systemd, seja por meio da interface de passagem de soquete nativa do systemd (consultesd_listen_fds(3) para obter detalhes sobre o protocolo preciso usado e a ordem em que os descritores de arquivo são passados) ou via tradicionalinetd(8)-passagem de soquete estilo (ou seja, soquetes passados via entrada e saída padrão, usando StandardInput=socket no arquivo de serviço).
Esse recurso é uma melhoria em relação ao que oinetd("superservidor de internet") pode fornecer, mas pode exigir suporte adicional do aplicativo (para a interface de passagem de soquete nativa do systemd).
libvirtd oferece esse suporte:
Integração de sistema monolítico
Quando o daemon libvirtd é gerenciado pelo systemd, vários recursos desejáveis estão disponíveis, principalmente a ativação de soquete.
libvirtd.service
- o arquivo da unidade principal para iniciar o daemon libvirtd no modo de sistema.
libvirtd.socket
- o arquivo de unidade correspondente ao soquete UNIX principal de leitura e gravação/var/run/libvirt/libvirt-sock
.
Aqui parece que as configurações do OP não estão apenas usando o soquete Unix padrão, mas ativadasConexões remotas TLS.
O objetivo é deixarsistemagerenciar o soquete sem ter que executarlibvirtdaté que uma solicitação neste soquete seja recebida.sistemaentão iniciará olibvirtdserviço que herda o soquete.
IPv6 usa modo de pilha dupla IPv4/IPv6
O segundo recurso é como funciona a pilha dupla IPv4/IPv6: use a API IPv6 e obtenha IPv4 gratuitamente. Isso pode ser desabilitado com a IPV6_ONLY
opção de soquete, mas o padrão é pilha dupla, conforme recomendado em RFC 3493: Extensões básicas de interface de soquete para IPv6:
5.3 Opção IPV6_V6ONLY para soquetes AF_INET6
Esta opção de soquete restringe os soquetes AF_INET6 apenas às comunicações IPv6. Conforme declarado na seção <3.7 Compatibilidade com nós IPv4>, os soquetes AF_INET6 podem ser usados para comunicações IPv4 e IPv6.
Por padrão, esta opção está desativada.
o que significa que, por padrão, o IPv6 pode lidar com IPv4 em um sistema que segue RFCs e com um aplicativo que não desativa ativamente esse recurso.
netstat
opta por exibir um IPv4 simples, mas por exemplo o endereço local visto no endereço estabelecidotomadasé na verdade umEndereço IPv6 mapeado para IPv4: ::ffff:10.1.6.140
(ou ::ffff:0a01:068c
) como seria ss -anpt
exibido no Linux. O endereço noaramepermanece, é claro, um endereço IPv4 normal.