ssh para dom0 e domU ao mesmo tempo elimina a conexão do dom0

Question

Quando a rede para domU é conectada via configuração de bridge, ter uma conexão ssh aberta para dom0 e domU ao mesmo tempo, aleatoriamente derruba a conexão dom0 (conexão redefinida pelo peer) e não me permite voltar.

A autorização é feita por meio de chaves ssh. Alguma dica sobre como resolver isso?

EDIT: mais alguns detalhes sobre o ambiente

dom0

# cat /proc/version
Linux version 2.6.18-128.1.10.el5xen ([email protected]) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Thu May 7 11:07:18 EDT 2009

domU

# cat /proc/version
Linux version 2.6.9-78.0.22.ELxenU ([email protected]) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-10)) #1 SMP Thu Apr 30 19:39:33 EDT 2009

Xen versão 3.1.2-128.1.10.el5

Detalhes importantes que eu esqueci de mencionar: isso acontece somente quando o dom0 tem um IP externo associado a ele.

Solução atual: nenhum IP externo no dom0, acesso ao dom0 via domU - > caminho dom0. Isso pode ser relativamente seguro quando se tem um domU separado que não faz nada além de fornecer essa rota. Ainda posso me conectar ao dom0 remotamente e reinicializar outras máquinas quando necessário.

EDIT2: informações adicionais sobre endereços MAC no dom0

dom0

# ifconfig|grep HWaddr
bond0     Link encap:Ethernet  HWaddr 00:04:23:DC:28:60  
bond0.100 Link encap:Ethernet  HWaddr 00:04:23:DC:28:60  
eth0      Link encap:Ethernet  HWaddr 00:04:23:DC:28:60  
eth1      Link encap:Ethernet  HWaddr 00:04:23:DC:28:60  
tap0      Link encap:Ethernet  HWaddr 7E:CE:49:45:3F:2E  
vif4.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
vif4.1    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
vif22.0   Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
xenbr0    Link encap:Ethernet  HWaddr 00:04:23:DC:28:60  
xenbr1    Link encap:Ethernet  HWaddr 00:04:23:DC:28:60

Parece que há realmente algum problema com os endereços MAC do dup.

    

Answer 1

Com base nas informações fornecidas até o momento, sugiro que o problema esteja na duplicação do endereço MAC e que as desconexões sejam do switch pelo qual a porta ethernet está passando.

Dito isso, haverá alguma duplicação de endereço MAC. Acabei de verificar em um dos meus servidores Xen em que tenho trabalhado e recebo o seguinte quando executo ifconfig | grep HWaddr

eth0      Link encap:Ethernet  HWaddr 00:E0:81:2D:66:AC  
eth1      Link encap:Ethernet  HWaddr 00:E0:81:2D:66:AD  
peth0     Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
peth1     Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
vif0.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
vif0.1    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
vif31.0   Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
vif31.1   Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
virbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
xenbr0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
xenbr1    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  

Isso está em um servidor RHEL5 Xen 3.0.3, portanto, suponho que as diferenças de interface sejam baseadas em alterações entre 3.0.3 e 3.1.2. Além disso, você pode ver que minhas interfaces eth0 e eth1 são endereços MAC diferentes, enquanto as duas são idênticas. As entradas pethX e vifX.X são todas interfaces virtuais para o Xen, portanto o endereço MAC FE: FF: FF: FF: FF: FF está perfeitamente correto.

O xenbr0 é a ponte à qual a eth0 está conectada e xenbr1 é a ponte para a eth1 e usa o mesmo endereço MAC. A interface virbr0 é a ponte para a rede virtual interna e possui o 00: 00: 00: 00: 00: 00 MAC porque o protocolo de árvore de abrangência está ativado. Você pode confirmar o bridging em seu sistema executando brctl show , o que deve lhe dar algo como:

bridge name bridge id       STP enabled interfaces
virbr0      8000.000000000000   yes     
xenbr0      8000.feffffffffff   no  vif31.0
                            peth0
                            vif0.0
xenbr1      8000.feffffffffff   no  vif31.1
                            peth1
                            vif0.1

    

Answer 2

Sem os detalhes solicitados por outros nos comentários sobre sua pergunta, meu palpite é um problema estranho de roteamento, como o NAT configurado incorretamente.

Uma alternativa para tentar seria executar o sshd em uma porta diferente em domU ou dom0 e ver se isso funciona. Se isto consertar a conexão, isso corrobora a sugestão de que o NAT está configurado erroneamente, então a entrada da tabela de tradução para o port-22-to / from-domU é destruída pela entrada para o port-22-to / from-dom0. Não deixe esta "correção" em vigor se funcionar - você precisaria resolver o problema de roteamento ou causar outros problemas.

Esta solução alternativa também pode ter o efeito desejado se você tiver endereços MAC duplicados, como sugerido por katriel, então verifique essa possibilidade primeiro.

    

Answer 3

Eu faço isso e sei que esse método funcionará. Além disso, você não precisa pensar em portas. Para se conectar ao terminal do Host do convidado vm, ele é montado para fazer o seguinte. A forma como o xenserver é configurado é que existem limitações no tráfego da porta. Eu tentei aprender isso e trabalhar com os métodos gerenciados, mas depois percebi que tinha outra opção. Isso requer que a sua operação tenha uma conexão externa com a rede na qual o host está. Gerenciar por ip estático é uma maneira fácil de fazer isso.

ASSUMPTIONS:

1. "host_a" ( contains vm_a )
2. "vm_a" shares ip with host_a and has an external nic configured.
3. "host_b"

Você saberá se a suposição 2 foi configurada corretamente se você puder fazer ssh em outras máquinas na rede a partir da vm. Isso é necessário porque é assim que nos conectaremos ao "host_a". Para se conectar da sessão ssh no VM_A, você ssh para HOST_B.

para que seu terminal se pareça com isso.

[root@vm_a]$ssh root@host_b
[roo@host_b]#ssh root@host_a

agora fizemos um pequeno círculo divertido e estamos conectados ao terminal host. Existem outras maneiras de se conectar diretamente por portabilidade, mas duas linhas são mais simples para mim.