Como detectar arquivos de soquete órfãos do Unix?

Question

Eu criei um túnel SSH reverso que cria um soquete UNIX em um servidor distante (vamos chamá-lo proxy_srv), para que eu possa conectar o proprietário do túnel (chamado target_srv no restante desta questão) em 2 etapas: criando um link do soquete Unix para uma porta TCP com socat e se conectar a essa porta com um cliente SSH (o cliente SSH não parece aceitar a conexão a um soquete Unix, então usei esse truque socat como solução alternativa).

Os comandos envolvidos são (o suficiente para reproduzir, um pouco mais na prática, com arquivos de identidade & co), nessa ordem:

De target_srv:

me@target_srv:% ssh -CNR /tmp/$(hostname):127.0.0.1:22 me@proxy_srv -o ExitOnForwardFailure=yes

Do proxy_srv:

me@proxy_srv:% socat TCP-LISTEN:2222 UNIX-CONNECT:/tmp/target_srv

De qualquer outro computador que possa acessar proxy_srv:

ssh someone@proxy_srv

O objetivo de tudo isso é ter um túnel construído automaticamente a partir de máquinas que usam redes GPRS para um ponto de acesso para que eu possa acessá-las em caso de problemas, considerando o fato de eu não ter acesso físico a eles (muitos quilômetros de distância).

Eu tenho 2 grandes problemas:

• quando alguém exclui o arquivo de soquete do Unix no proxy_srv, o túnel não termina, então não posso recriá-lo (fácil de contornar, apenas usar um usuário dedicado, mas ainda um pouco preocupante comigo)

• mais importante, se por alguma razão algo em target_srv for reiniciado, seja uma reinicialização física ou uma falha do sistema com as coisas subindo automaticamente depois, o arquivo em proxy_srv não será excluído e o túnel não poderá ser reconstruído . Claro, eu poderia simplesmente deletar, e esperar que o problema não seja um conflito com outro computador, mas acho que deve haver uma maneira melhor de, pelo menos, trabalhar em torno disso, por exemplo, detectar arquivos de soquete que não têm mais listeners e deletar automaticamente regularmente (dentro de uma pasta dedicada, claro).

Alguma ideia?

    

Answer 1

Eu entendo que existem muitas máquinas target_srv e, por esse motivo, você não usa -R 2222:127.0.0.1:22 , mas conecta a 2222 port de proxy_srv à máquina de sua escolha ad hoc.

Eu acho que a ferramenta certa é a VPN. Se o proxy_srv fosse o servidor VPN e as máquinas target_srv fossem clientes, você encapsularia o SSH para o endereço IP (VPN) do cliente desejado. Se você fez do seu computador local um cliente também, você pode até chegar a outros clientes semiautomáticos (sem tunelamento SSH). O software VPN seria responsável por estabelecer, manter e renovar a presença de qualquer target_srv na rede virtual.

Suponha que você não possa usar VPN e essa engenhoca baseada em soquete é obrigatória. Eu não sei como detectar órbitas de domínio Unix órfãs, no entanto, há outra maneira de lidar com a situação.

Crie um script auxiliar no proxy_srv, digamos /home/me/bin/ssh-tunnel-helper.sh :

#!/bin/sh

soc1="$1".tmp
soc2="$1"

mv "$soc1" "$soc2" || { rm "$soc1"; exit 2; }
while sleep 40; do
   [ -e "$soc2" ] || exit 1
done

(não se esqueça de torná-lo executável).

Em seguida, em uma invocação de target_srv:

socket="/tmp/$(hostname)-tunnel"
while sleep 5; do
   ssh -CR "$socket".tmp:127.0.0.1:22 -o ExitOnForwardFailure=yes me@proxy_srv \
      /home/me/bin/ssh-tunnel-helper.sh "$socket"
done

Agora

• when someone deletes the unix socket file on proxy_srv

o script ssh-tunnel-helper.sh detecta e sai. O loop while no target_srv renova o túnel.

• if for some reason something on target_srv was restarted, […] the file on proxy_srv is not deleted

O soquete *-tunnel de fato não é excluído, mas sshd cria inicialmente *-tunnel.tmp , que é renomeado mais tarde . O truque é no Unix você pode abrir um arquivo e movê-lo (ou até mesmo apagá-lo). Renomear o soquete não perturba o túnel existente, mas permite que um novo soquete seja criado no futuro.

Se o script auxiliar for interrompido, ele poderá deixar um soquete *-tunnel.tmp obsoleto que impediria que futuros túneis fossem estabelecidos. Espero que esses incidentes sejam raros. Execute rm /tmp/*-tunnel.tmp no proxy_srv para recuperar. Mesmo se você remover o outro socket que estava prestes a ser renomeado neste exato momento, seu script auxiliar irá sair e o túnel será renovado em algum momento.

Nota:

• Você pode usar autossh em vez de ssh em máquinas target_srv para detectar conexões quebradas, etc. Mesmo com autossh você ainda precisa do loop while porque autossh sairá se o script auxiliar sair ( por exemplo, quando alguém exclui o socket no proxy_srv).