Porque é que um servidor doméstico perde uma rota estática após uma atualização do NetworkManager?

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Uma rota estática pode desaparecer após uma atualização do NetworkManager quando a rota pertencia a um perfil ou caminho de configuração que já não corresponde à ligação ativa.

Num ZimaSpace ou servidor doméstico Linux, uma rota para uma VLAN de IoT, uma sub-rede de cópia de segurança ou um router secundário pode ter sido adicionada manualmente com ip route, armazenada num perfil de ligação antigo ou associada a um perfil que o NetworkManager substitui após a atualização. O teste correto compara a rota ativa com o perfil persistente ativo, em vez de voltar a adicionar o comando após cada reinício.

Verifique se a Rota Chegou a Ser Persistente

Compare uma rota adicionada com ip route com o perfil de ligação do NetworkManager que a deveria recriar.

Um guia prático e específico sobre o networkmanager, em as rotas estáticas persistentes devem pertencer ao perfil de ligação, ajuda a isolar esta possibilidade porque aborda o mesmo problema específico, em vez de apenas definir o protocolo subjacente.

Se a rota existir apenas na tabela do kernel, transfira-a para o perfil gerido antes de atribuir a culpa à atualização.

Inspecione as Alterações aos Perfis Desencadeadas pela Atualização

Compare os nomes dos perfis, os UUID, o estado de ligação automática e as entradas de rota antes e depois da atualização do pacote.

Um artigo específico de resolução de problemas em as rotas estáticas podem desaparecer quando o estado do NetworkManager muda ajuda a isolar esta possibilidade porque aborda o mesmo problema específico, em vez de apenas definir o protocolo subjacente.

Restaure a rota no perfil persistente ativo e guarde uma cópia do perfil anterior para comparação.

Lembre-se de que o NetworkManager é Centrado em Perfis

Uma interface pode ter vários perfis guardados, mas apenas o perfil ativado contribui com as respetivas definições de rota.

Um artigo técnico específico sobre networkmanager, em a configuração do NetworkManager gira em torno dos perfis de ligação, ajuda a isolar esta possibilidade porque aborda o mesmo problema específico, em vez de apenas definir o protocolo subjacente.

Identifique o perfil ativo pelo UUID, em vez de editar o nome de ficheiro que lhe parecer mais familiar.

Verifique em Conjunto a Tabela de Rotas e as Regras de Políticas

Uma rota pode ainda existir numa tabela diferente da principal, enquanto a regra que selecionava essa tabela foi alterada.

Uma explicação específica sobre encaminhamento em Linux, em o encaminhamento baseado em políticas usa tabelas e regras, ajuda a isolar esta possibilidade porque aborda o mesmo problema específico, em vez de apenas definir o protocolo subjacente.

Apresente ip rule e todas as tabelas relevantes antes de adicionar uma rota duplicada à tabela principal.

Verifique se as Métricas das Rotas Alteraram a Rota Escolhida

Quando duas rotas abrangem o mesmo destino, a métrica efetiva mais baixa ou a rota mais específica pode substituir o caminho que esperava ver.

Um tutorial específico sobre redes Linux, em as métricas das rotas alteram o caminho escolhido, ajuda a isolar esta possibilidade porque aborda o mesmo problema específico, em vez de apenas definir o protocolo subjacente.

Compare o prefixo de destino, a métrica e a interface após a atualização. Não conclua que a rota foi eliminada apenas porque o tráfego está a utilizar outra rota.

Mantenha a Configuração de Rede do Servidor num Único Gestor

Misturar scripts antigos, comandos manuais, Netplan e perfis do NetworkManager aumenta a probabilidade de as atualizações exporem conflitos de gestão.

Um guia prático e específico sobre redes Linux, em um único perfil do NetworkManager deve gerir o caminho do servidor, ajuda a isolar esta possibilidade porque aborda o mesmo problema específico, em vez de apenas definir o protocolo subjacente.

Uniformize a rota num único perfil gerido, reinicie duas vezes e confirme que a mesma rota e métrica regressam de cada vez.

Volte a Testar o Caminho Exato do Servidor Doméstico

Depois de alterar uma variável, repita o mesmo fluxo de trabalho do NAS ou do serviço autoalojado a partir do mesmo cliente, em vez de mudar para um teste diferente que possa utilizar outro caminho.

O guia relacionado do ZimaSpace, em o caminho de rede adjacente do servidor doméstico, ajuda a manter a verificação final associada ao mesmo ambiente autoalojado.

A correção só está concluída quando o sintoma original permanece resolvido após voltar a ligar, reiniciar o serviço e realizar uma segunda transferência ou pedido controlado.

Perguntas Frequentes

Porque é que ip route add funciona até reiniciar?

Altera a tabela ativa do kernel, mas não cria necessariamente uma configuração persistente do NetworkManager.

A rota pode continuar a existir, mas utilizar a tabela errada?

Sim. O encaminhamento baseado em políticas pode colocar as rotas em tabelas alternativas que precisam de regras correspondentes.

Devo editar manualmente os ficheiros de ligação depois de uma atualização?

Prefira o nmcli ou o gestor suportado pela plataforma, a menos que tenha uma razão controlada para gerir diretamente os keyfiles.

Suporte e Dicas

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.