Gateway ou cliente encaminhado? Ler o endereço de origem

O servidor web registra um endereço, e todos assumem que ele pertence ao processo do próprio gateway. Ele pode pertencer a um cliente encaminhado cujo endereço privado desapareceu na etapa de tradução. O destino vê a origem de rede visível e nada mais. É uma afirmação de fronteira, não a pretensão de que a origem nunca possa ser estabelecida.

O que o destino realmente vê

Tome um cliente em 10.20.0.7, um gateway cujo endereço externo é 198.51.100.10 e um destino na internet. Se o gateway traduz a origem do cliente, o socket do destino registra 198.51.100.10. O endereço privado desaparece do pacote, e o destino não pode lê-lo de volta a partir desse cabeçalho. Esses números são ilustrativos, não uma captura da sua rede.

A observação continua útil: ela identifica a origem de rede que o destino deve permitir ou bloquear. Ela simplesmente não identifica a pessoa ou o processo por trás. Para o operador do destino, essa distinção decide se um bloqueio é uma decisão de rede ou uma decisão de conta.

O estado de tradução não é visível para o destino

O gateway mantém o mapeamento entre a conexão traduzida e o cliente original, e esse estado é exatamente o que falta ao destino. descrição tradicional do NAT separa o registro de tradução dos cabeçalhos visíveis depois. Ler um lado não dá o outro.

Projetos diferentes produzem evidências diferentes. O tráfego roteado com endereços de origem preservados mostra o endereço real do cliente, enquanto um proxy de aplicação encerra a conexão e cria uma nova. Uma rota com origem preservada também exige que o endereço do cliente seja roteável de volta a partir do destino, o que nem toda implantação oferece. Pergunte qual projeto está implantado antes de interpretar uma linha de log.

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

TTL e impressões digitais são indícios, não provas

O TTL no IPv4 depende do valor inicial escolhido pelo remetente e do número de saltos que o pacote percorreu. Sem ambos os fatos, um valor não pode provar que ocorreu um salto de VPN. Um salto roteado extra conhecido também não consegue distinguir um roteador de LAN, um caminho de túnel ou outro arranjo de encaminhamento. Trate uma diferença de TTL como uma pergunta, não como uma conclusão.

Outros sinais se comportam da mesma forma. Um cabeçalho User-Agent pode ser definido pela aplicação, e a semelhança de tempo pode refletir infraestrutura compartilhada em vez de uma pessoa compartilhada. Vários usuários podem compartilhar uma saída, e um usuário pode mudar de caminho entre sessões. Reunidos, vários sinais fracos podem justificar um olhar mais atento aos registros de um gateway, mas não se tornam provas fortes por acumulação.

Autorize por identidade, não por endereço

Se o destino precisa separar a administração do gateway da atividade de usuários remotos, dê a esses papéis identidades autenticadas separadas e operações permitidas. Uma origem pública compartilhada ainda pode servir como restrição de rede, mas não substitui a autenticação do usuário ou do dispositivo.

Mantenha as evidências rotuladas: origem observada, conta autenticada, momento e a inferência em consideração. Não traduza «nenhuma origem interna visível aqui» como «nenhuma atribuição possível em lugar algum». O rótulo importa quando alguém que não participou da investigação lê o registro meses depois.

Registre a data da observação e o sistema que a produziu. Um trecho de log sem atribuição é difícil de defender mais tarde.