o wireguard não escuta na porta depois de iniciado

Presumirei que isso seja feito no Linux, já que não foi informado o contrário e por causa do contexto do contêiner.

A descrição de lsofdiz:

DESCRIÇÃO

Lsof revisão 4.91 lista em seu arquivo de saída padrão informações sobre arquivos abertos por processos para os seguintes dialetos UNIX:

• Apple Darwin 9 e Mac OS X 10.[567]
• FreeBSD 8.[234], 9.0 e 1[012].0 para sistemas baseados em AMD64
• Linux 2.1.72 e superior para sistemas baseados em x86
• Solaris 9, 10 e 11

No Linux, o WireGuard não é um processo padrão, mas um driver de rede manipulado pelo kernel. Mesmo que no final isso possa criar um thread de kernel aparecendo na lista de processos, esse "processo" seria especial e não forneceria nenhuma informação disponível sobre seus descritores de arquivo abertos (se tal conceito fizer algum sentido para um thread de kernel de qualquer maneira).

Assim lsof, não é possível encontrar essas informações e sempre retornará um resultado vazio.

No entanto, um comando como netstat -nul | grep -w 7456ou ss -nul sport = :7456ainda o exibiria, onde foi criado (veja mais adiante), porque está apenas consultando APIs de rede do kernel/proc/net/udp{,6} ( resp . com isso da API de rede.

Dito isto, isso só é válido se o comando wg-quick up wg0foi executado no contêiner específico em que a interface é usada depois. Se foi executado no host, e depois disso a criação de um container o "roubou", todas as apostas estão canceladas. Isso porque o WireGuard foi projetado para funcionar em namespaces de rede (ou seja, contêineres). É completamente possível e documentado criar a interface WireGuard em um namespace de rede (por exemplo, o namespace inicial do host) e movê-lo para outro namespace de rede:

Pronto para contêineres

O WireGuard envia e recebe pacotes criptografados usando o namespace de rede no qual a interface WireGuard foi originalmente criada . Isso significa que você pode criar a interface WireGuard em seu namespace de rede principal, que tem acesso à Internet, e depois movê-la para um namespace de rede pertencente a um contêiner do Docker como a única interface desse contêiner. Isso garante que a única maneira possível desse contêiner acessar a rede seja por meio de um túnel WireGuard criptografado e seguro.

Isso significa que se a interface for movida, a porta de escuta permanecerá no namespace de rede anterior (provavelmente do host inicial) e ficará invisível no namespace de rede onde a interface chega. Nesse caso, a porta de escuta 7456/UDP não estaria visível no contêiner, mas estaria no host (ou onde quer que tenha sido criada inicialmente). Observe também que o WireGuard escutará (ainda apenas no namespace de rede original) somente se a interface estiver administrativamente ativa ( ip link set wg0 up). Desligá-lo remove temporariamente a porta de escuta.