Console, shell e SSH: três portas distintas para a mesma máquina

Você não consegue alcançar uma máquina. Antes de entrar em pânico, faça uma pergunta: qual porta você estava usando?

Existem três portas distintas para a mesma máquina, e cada uma depende de coisas diferentes estarem funcionando. Saber qual delas fechou já diz onde está o problema.

Três portas

Console. Olhar a tela e o teclado da máquina. O equivalente a chegar perto de um servidor físico e ligar um monitor. Não usa a rede do convidado, passa pelo hospedeiro.

Shell. Digitar um comando e receber a saída. Não imita uma tela, abre diretamente um canal de comandos.

SSH. Um serviço rodando dentro do convidado. Precisa da rede, precisa do serviço no ar, precisa de credenciais.

A regra: quanto mais confortável a porta, mais partes do convidado precisam funcionar

SSH é a mais confortável. Você conecta do seu próprio terminal, copiar e colar funciona, você move arquivos. Em troca, exige o máximo: a configuração de rede tem que estar certa, a interface tem que estar ativa, o serviço tem que rodar, o firewall tem que permitir, a chave ou a senha tem que ser válida. Se um elo dessa corrente quebra, a porta fecha.

O console é o menos confortável. Você olha uma tela dentro do navegador, e copiar e colar costuma ser trabalhoso. Em troca, quase não exige nada: a rede do convidado pode estar quebrada, o firewall pode bloquear tudo, o SSH pode nem estar instalado, e a tela aparece mesmo assim. Porque essa tela vem do hospedeiro, não da rede do convidado.

É por isso que o console é um caminho de recuperação. Não por ser confortável, mas por depender de tão pouco.

O incidente clássico

Você muda uma configuração de rede. Aplica. A conexão cai e não volta.

O que você fez pode nem ter sido errado: às vezes a configuração está certa e a sessão simplesmente morre enquanto a interface troca. Mas agora você não alcança mais a máquina pela rede, e para consertar seria preciso justamente alcançá-la.

Você abre o console, a tela aparece, corrige a configuração. Como ele nunca passou pela rede, a rede quebrada não o afetou.

O hábito prático que sai daí: confirme que o console abre antes de mexer numa configuração de rede. Faça o trabalho arriscado já segurando um caminho de recuperação que funciona, em vez de procurar um depois.

No lado do shell, contêiner e máquina virtual não são a mesma coisa

Essa distinção surpreende muita gente, porque no painel os dois ficam lado a lado e oferecem o mesmo botão.

Num contêiner o hospedeiro pode entrar direto. O contêiner compartilha o núcleo do hospedeiro, então os processos lá dentro já são visíveis para ele. O hospedeiro pode executar um comando ali sem pedir nada ao interior.

Numa máquina virtual não é assim. Uma máquina virtual é uma caixa selada: o hospedeiro vê o disco e a memória dela como blocos e não sabe o que há dentro. O hospedeiro não consegue empurrar um comando para dentro da caixa.

O único caminho é ter algo dentro da caixa escutando. É exatamente isso que o agente convidado é: um pequeno serviço instalado dentro da máquina virtual que escuta os pedidos do hospedeiro e responde. Se não estiver instalado, a porta do shell não existe para aquela máquina virtual, e isso não é defeito, é consequência da arquitetura.

Pelo mesmo motivo o shell não funciona enquanto uma máquina virtual está desligada. Não há nada escutando. Já o console mostra também a tela de uma máquina desligada, e quando você a liga vê o que acontece desde o primeiro segundo.

O console também tem limites

Para ser honesto, o console não é mágico.

Se o próprio hospedeiro estiver fora, as três portas estão fechadas. O console passa pelo hospedeiro, então vai embora junto com ele.

E tem mais: o console dá uma tela, não arquivos. Se você precisa tirar um arquivo de lá, o console é uma ferramenta ruim. Boa para recuperação, não para o trabalho diário.

Por fim, o acesso ao console é uma permissão separada. Um usuário poder ler o painel não significa que ele possa olhar as telas das máquinas, e essa separação é proposital: uma tela mostra o conteúdo do trabalho em andamento.

O que o Atlas faz

O Atlas abre o console a partir da própria tela, sem pedir um segundo login. Parece pouco, mas há por trás uma história que vale contar com honestidade.

O console na verdade vive no endereço próprio do painel do Proxmox. O Atlas está em outro. Para um navegador esses são dois sites distintos, e a sessão de um não passa sozinha para o outro. Sem nenhuma providência, o usuário que aperta o botão do console recebe um erro de "sem sessão" e é convidado a entrar no painel uma segunda vez.

A primeira solução foi esta: entregar a sessão ao painel de dentro de um quadro invisível. Funcionava. Depois os navegadores apertaram as regras de cookies de terceiros e parou de funcionar. Não havia erro nenhum no código; o chão embaixo dele se moveu.

A segunda solução ficou porque é mais firme: o console é servido pelo endereço próprio do Atlas. O navegador enxerga um único site, não sobra sessão a entregar, e o problema some na origem.

Dois detalhes pequenos mas honestos: os cabeçalhos que gravam cookies nas respostas vindas do painel são removidos, então o Atlas não acumula cookies do painel no próprio endereço. E a conexão até o painel fica dentro da máquina, nunca sai para a rede.

A lição geral, independente de qualquer produto: uma solução que funcionava e para de funcionar nem sempre significa um erro. Às vezes mudou uma suposição em que você se apoiava. A solução que dura é a que se apoia em menos suposições.