Conceito e mecanismo
Um socket a ouvir em 127.0.0.1 aceita no âmbito de loopback; abrir portas no firewall não altera esse bind. Antes de expor o listener, confirma o desenho: pode existir um proxy local que é o único ponto de entrada autorizado. Usa ss para observar sockets e relaciona endereço e porta com o processo. Com várias interfaces, ip addr mostra endereços, mas não determina por si qual origem será escolhida para um destino. ip route get permite consultar essa decisão; em ambientes com policy routing, considera origem, regras e contexto relevantes. Evita remover uma default route só porque é a primeira apresentada.
Aplicação guiada
A resolução usada pela aplicação também importa. dig consulta DNS, enquanto getent segue bases configuradas através de NSS. Se a aplicação usa NSS e /etc/hosts contém um endereço antigo, um teste DNS correto pode não representar o caminho real. Com dual stack, testa IPv4 e IPv6 separadamente, preservando hostname e contexto TLS. Sucesso numa família não demonstra sucesso na outra. Em SSH, uma host key alterada depois de uma substituição é plausível, mas o ticket não autentica a chave nova. Confirma a fingerprint por um canal autenticado e atualiza apenas a confiança necessária. Não apagues todas as chaves conhecidas nem desatives a verificação globalmente para ultrapassar um aviso.
O parceiro recusa o IP de origem observado: consulta a rota para esse destino antes de propor mudanças de firewall.
Armadilhas comuns
Porta aberta como listener externo; lista de IPs como decisão de rota; dig como teste de qualquer aplicação; mudança prevista como chave autenticada.
Tópicos relacionados: Tempo, filtragem, bonds e proxies · Storage, mounts e recuperação
Reproduz o contexto do cliente e recolhe evidência em cada fronteira do fluxo.
Referência: ss(8) · LFCS current five-domain outline; exact edition date unconfirmed