Espaço de nomes de rede, ssh, X11

Question

Eu conecto (via ssh -Y ... ) de uma máquina (= cliente) a outra máquina (= servidor, na verdade na minha LAN, mas é irrelevante); então eu inicio um novo namespace de rede (abreviado NNS) no servidor, inicio um xterm (do namespace padrão) que é exibido perfeitamente no meu cliente e, por último, de dentro do xterm, eu participo do NNS não padrão ,

ip netns exec NNSName bash

Eu posso verificar se estou no novo NNS,

ip netns identify $$

e eu posso rodar programas complexos como, por exemplo, o OpenVPN dentro do novo NNS.

O problema está aqui: gostaria de iniciar um aplicativo gráfico (mesmo que apenas xeyes , por enquanto) de dentro do novo NNS, mas não posso, sempre me dizem: Unable to open DISPLAY=...

Admito que apenas tentei o óbvio:

DISPLAY=:0.0
DISPLAY=:10.0
DISPLAY=localhost:10.0
DISPLAY=localhost:20.0
DISPLAY=ClientName:10.0
DISPLAY=ClientIPAddress:10.0

sempre com xhost + no cliente, para fins de depuração pura.

Eu não tenho problemas:

1. conectando via ssh -Y .... do cliente para o servidor, executando xeyes no servidor e exibindo-o no cliente;

2. iniciando um novo NNS no servidor, e iniciando aplicações gráficas dentro do NNS para serem exibidas no servidor ( isto é, , neste caso esquecendo o cliente).

É quando eu coloco essas duas coisas juntas (ssh e namespace) que não consigo exibir nos aplicativos clientes em execução no novo NNS do servidor.

Parece que a porta TCP 6010 padrão pertence à sessão ssh com o NNS padrão, enquanto o novo NNS deve obter o seu próprio. Eu certamente posso iniciar um servidor ssh no novo NNS e conectar diretamente do cliente ao novo NNS do servidor, mas eu estava pensando: existe alguma maneira mais fácil de fazer isso, ie para exibir aplicativos gráficos em execução no novo NNS do servidor no servidor X11 do cliente?

    

Answer 1

Eu estava em uma situação semelhante, eis como eu trabalho com isso.

Alguns antecedentes: tive que abranger várias instâncias de selênio do Firefox em namespaces para vinculá-las a diferentes endereços IP. Mas como você sabe, eu estava com o erro:

Error: Can't open display: localhost:10.0

Em vez de trabalhar com sockets unix, como Marius sugeriu, limitei o SSHD X11Forwarding para * em vez de localhost (adicionando "X11UseLocalhost no" à configuração) e redirecionei conexões TCP simples com o socat.

Atenção às conseqüências de segurança ao fazer isso !!!!

Após esta alteração no sshd, o DISPLAY irá mudar automaticamente quando você fizer login a partir deste:

 DISPLAY=localhost:10.0

Para algo como:

 DISPLAY=10.0.0.1:10.0

Depois disso, só preciso redirecionar:

ip netns exec my-NNS socat tcp-listen:6010,reuseaddr,fork tcp:192.168.5.130:6010 &

Então você deve poder trabalhar com xeyes, firefox, x-whatever-you-want ...:

ip netns exec my-NNS xeyes &

E voilà!

    

Answer 2

Na verdade, não parece haver nenhuma maneira padrão de fazer.

Existe uma solução mais óbvia: a partir do namespace da rede, inicie um ssh server e, em seguida, conecte-se a ele de qualquer máquina remota com a opção usual,

ssh -Y [email protected]

então qualquer programa gráfico pode ser iniciado no servidor X11 da máquina remota. Todos os tipos de variações sobre o mesmo tema, como vnc , também funcionam.

Como alternativa , pode-se usar os instrumentos usuais: iptables , netcat , socat . Aqui está uma maneira de fazer isso com socat : o truque é que, enquanto os espaços localhost no servidor e em seu novo namespace de rede foram separados, seus soquetes X11 unix não. Na verdade, a partir do namespace da rede, você pode abrir imediatamente os aplicativos gráficos que serão exibidos no servidor X de sua máquina principal. Assim, forçando o namespace da rede a gravar em um novo soquete unix em sua máquina pai, podemos redirecionar os dados enviados para o novo soquete para o servidor X cliente por meio do encaminhamento ssh X11 usual em a máquina do servidor, sem sequer ligar o novo espaço de rede, dando uma solução mais simples.

Isso é feito da seguinte maneira: no novo namespace de rede,

export DISPLAY=:1

Isso gravará em um novo soquete do Unix, /tmp/.X11-unix/X1 , que ainda não está conectado a nada. No cliente remoto, use o comando

socat exec:'ssh me@remoteserver socat unix-l\:/tmp/.X11-unix/X1 -' unix:/tmp/.X11-unix/X0

(observe o escape do : ). O comando acima envia a entrada do soquete unix/:1 no servidor para o soquete unix/:0 no cliente. Talvez seja necessário relaxar os controles xhost locais (= no cliente) e verificar a propriedade do soquete unix/:1 (= :1 = /tmp/.X11-unix/X1 ). Isso é consideravelmente mais simples que o método anterior: não há necessidade de configurar um servidor ssh no novo namespace da rede, nem mesmo de obter um endereço IP. Ele também ignora todos os problemas de autorização do X11, como usar xhost para permitir que alguns usuários remotos ou o uso de cookies mágicos do MIT com socat (nem sei se isso pode ser feito).

Existem outras maneiras de fazer isso (por exemplo, suprimindo a opção -nolisten tcp no servidor cliente X, então use socat para encaminhar o soquete :1 unix para a porta TCP6000 do cliente, por exemplo), mas mesmo negligenciando que causam sérios problemas de segurança, eles não são padronizados por qualquer extensão de imaginação.