Soquete UDP no estado UNCONN ao usar o ss do iproute2

Question

Durante a edição de algumas regras de firewall em uma máquina que tem um cliente OpenVPN em execução, eu estava tentando determinar sua porta remota, como normalmente faço, usando ss .

# ss -anup | grep openvpn
UNCONN6528   0    0.0.0.0:52012        0.0.0.0:*     users:(("openvpn",pid=333,fd=3))

Ele ficou vazio.

A partir da configuração, vejo que o cliente deve estar conectado a 10.0.0.5:389 over UDP. Eu verifiquei isso em /proc :

# cat /proc/net/nf_conntrack | grep udp | grep 389
ipv4     2 udp      17 175 src=10.0.7.8 dst=10.0.0.5 sport=52012 dport=389 src=10.0.0.5 dst=10.0.7.8 sport=389 dport=52012 [ASSURED] mark=0 zone=0 use=2

Ambos os comandos foram executados em rápida sucessão depois de fazer uma conexão de saída e verificar se está funcionando, curl ipinfo.io tendo retornado o resultado esperado.

Eu tentei uma conexão UDP normal com o netcat ( nc -l -u 12345 no servidor e nc -u 10.0.0.5 12345 no cliente) para ver a saída de ss no cliente:

# ss -anup | grep nc
ESTAB      0      0      10.0.7.8:52051              10.0.0.5:12345               users:(("nc",pid=2002,fd=3))

Por que a saída ss para o OpenVPN no estado UNCONN e não o estado esperado ESTAB , como no caso do netcat simples?

Ambiente:

# uname -a
Linux tank 4.16.3-1-ARCH #1 SMP PREEMPT Thu Apr 19 09:17:56 UTC 2018 x86_64 GNU/Linux

# pacman -Qo /usr/bin/ss
/usr/bin/ss is owned by iproute2 4.16.0-1

    

Answer 1

TL; DR: você pode usar soquetes UDP no modo conectado ou permanecer desconectado, o que é uma opção de implementação dependendo, entre outros fatores, da simplicidade ou escalabilidade. Isso não alterará o conteúdo dos pacotes no fio ou conectará qualquer escolha feita.

netcat usa bind(2) na porta escolhida, usa somente uma vez recvfrom(2) com a opção MSG_PEEK para nem consumir os dados , recupera a fonte e, em seguida, usa connect(2) para essa fonte, alterando o estado do soquete para ESTAB e agora pode continuar com read(2) e write(2) chamadas.

Outras aplicações (por exemplo: socat UDP-RECVFROM:7777,fork - em vez de socat UDP-LISTEN:7777 - e obviamente openvpn) simplesmente nunca connect(2) para a fonte e assim permanecer no estado UNCONN. Eles só usarão recvfrom(2) e emitirão dados usando sendto(2) .

Essa diferença de uso é parcialmente explicada em recv(2) e < href="https://manpages.debian.org/stretch/manpages-dev/send.2.en.html"> send(2) :

The send() call may be used only when the socket is in a connected state (so that the intended recipient is known). The only difference between send() and write(2) is the presence of flags. With a zero flags argument, send() is equivalent to write(2).