Conceito e mecanismo
Um fluxo depende de origem, destino, rota, encaminhamento do kernel e políticas aplicáveis. Ip route get ajuda a observar uma decisão concreta; num host com várias interfaces, inclui a origem relevante e considera regras de encaminhamento. Num router IPv4, rotas e filtros preparados não substituem ip_forward ativo. NAT altera endereços, mas não concede autorização universal: um destino noutro host continua sujeito ao caminho forward. Uma alteração deve incluir retorno e conectividade nova, não apenas uma sessão antiga. Nft -c valida comandos sem aplicar mudanças, mas sintaxe correta não demonstra a política pretendida.
Aplicação guiada
Túneis acrescentam encapsulamento e podem revelar problemas de MTU. Pedidos pequenos que passam e transferências grandes que bloqueiam justificam medir essa hipótese, sem a declarar provada. Num túnel SSH local de diagnóstico, confirma bind a loopback e o destino encaminhado; uma porta alta não limita quem consegue ligar. Em routing dinâmico, sessão Established não prova aceitação nem anúncio de prefixos. Se FRR exige políticas e falta filtro, define o âmbito permitido em vez de desligar os controlos para obter rotas. Num exercício fictício de firewall, conserva consola autorizada e testa um novo login antes de encerrar a recuperação. Regista também os acessos que devem continuar recusados.
A sessão SSH antiga sobrevive, mas uma nova falha: os testes medem estados diferentes.
Armadilhas comuns
NAT como autorização; Established como rotas aceites; sintaxe como conectividade; MTU como diagnóstico certo sem teste.
Tópicos relacionados: Automatizar com evidência · Operar e recuperar sistemas · Identidade, PAM e SSH
Valida o fluxo completo, incluindo os casos que devem ser recusados.
Referência: Linux route inspection · Historical LFCE V3.18 (2018-06-12); exam retired 2022-05-01; technical references inspected 2026-09-30