Servidor raiz com configurações de rede alteradas - como evitar ser excluído?

Question

Eu apenas trabalhei em um servidor Linux local no meu escritório, conectando-me via SSH. Eu mudei algumas configurações de rede. Especificamente, adicionei uma ponte de rede simples que substituiu a conexão Ethernet anterior (eth0). Em ambos os casos, o endereço de rede é um endereço IPv4 estático.

Depois que fiz essas alterações e reiniciei o daemon de rede usando systemctl restart systemd-networkd , fui bloqueado e não pude voltar ssh para a máquina.

Por sorte, eu tive acesso ao console físico. Ao reiniciar a rede me deu a nova ponte com o endereço correto, ela não removeu o endereço da eth0 - mesmo que todas as configurações estejam corretas. Então, eu tive que manualmente ip a flush eth0 , e eu estava de volta em funcionamento.

Eu acho que se isso fosse um servidor raiz em um local remoto em vez de uma máquina local, eu ficaria muito velho agora.

O que eu deveria ter feito diferente, qual é a abordagem correta aqui?

Atualização: Das duas respostas fornecidas até agora, vejo que deveria ter sido mais claro. Eu estou totalmente ciente de todas as opções de hardware como manter o acesso à minha estação. Porque eu tenho e usá-los, me sinto confortável para invocar certas mudanças com o risco de algo ruim acontecer. É um pouco trabalhoso, mas posso apenas fazer o login através do console serial e tudo está bem novamente. Mas eu estava pensando, e se eu não os tivesse, como o resto de vocês mudaria as configurações de rede que teoricamente podem desconectar você?

E, francamente, eu também me pergunto de uma maneira muito concreta por que minha interface eth0 mantinha o antigo endereço IP mesmo que eu reiniciei o serviço de rede com novas configurações? Isso não parece o comportamento desejado para mim.

    

Answer 1

Existem pelo menos duas maneiras de fazer isso de maneira diferente:

1. Console remoto (HP ILO, DELL DRAC, ...) permitindo o acesso por meio de sua própria NIC e seu próprio IP, que é independente das configurações principais do sistema operacional. Se você errar, você pode apenas 'remotamente pegar o console' e consertar as coisas.
2. Configure uma reinicialização para um estado de funcionamento seguro em um timer. Faça as suas alterações e, em seguida, mate o temporizador de segurança.

Por exemplo,

sleep 15*60 && shutdown -r +NOW "I messed up. Rebooting"  

(On a new shell)
ifconfig / ip whatever

Depois, com um estado alterado de trabalho, cancele a reinicialização.

PS1: suspensão e desligamento usados para não enviar spam para os usuários. (embora você possa apenas desligar-15m e depois cancelar o desligamento.

PS2: repare no desligamento do & & e não durma ; desligue.

    

Answer 2

As formas menos intrusivas para lidar com esse problema são aquelas que não exigem reinicialização.

Um console serial é uma maneira de obter acesso. Outro hardware mais especializado também existe para obter acesso a um host sem rede funcional.

Se você não tiver esse acesso fora de banda, vale a pena tentar meios alternativos de comunicação com o host através da rede. A primeira alternativa é tirar vantagem da pilha dupla, dando-lhe um pouco de redundância. Se você bagunçar sua configuração IPv4, ainda poderá alcançar o host por meio do IPv6 e vice-versa.

Se você atrapalhar o IPv4 e o IPv6, talvez ainda consiga alcançar o host por meio da comunicação local de vínculo IPv6. A maneira como a comunicação IPv6 link-local funciona, torna-a um pouco mais robusta contra redes mal configuradas, então há uma boa chance de que funcione. Esse método só funciona se você tiver acesso a pelo menos um outro host funcional no mesmo segmento de rede que seu destino.

As formas mais intrusivas para lidar com o problema são reinicializar. Mesmo se você não tiver o hardware para acesso remoto total, ainda poderá ter o hardware para acionar uma reinicialização remotamente. Isto pode ser conseguido através de hardware que pode disparar a linha de reset na placa-mãe ou através de hardware que energize o host.

Se não houver hardware para administração fora da banda no host, talvez seja necessário pedir ajuda à equipe no local. Nesses casos, é certamente mais fácil pedir que reinicializem a máquina do que pedir que depurem a conectividade de rede.

Quando a máquina for reinicializada, você precisará, de alguma forma, garantir que ela volte a ficar on-line. Se a alteração incorreta ocorreu apenas na memória e a reinicialização voltará a uma configuração válida, nenhum cuidado especial poderá ser necessário. Em casos mais problemáticos, pode ser útil ter o host configurado para tentar a inicialização PXE e inicializar apenas a partir do disco local, se nenhum servidor PXE estiver presente na rede. No entanto, essa abordagem só é sensata se você souber que pode confiar na rede.

O mais intrusivo é aplicar quaisquer procedimentos que você tenha para lidar com a situação em que o host está completamente perdido. Esses procedimentos são geralmente destinados a falhas de hardware ou, pior ainda, que o prédio tenha queimado até o chão. Mas eles poderiam ser aplicados para algo tão trivial quanto uma rede mal configurada. (Por mais intrusiva que essa abordagem seja, raramente é a solução preferida).