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

O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...

Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...

Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...

