Eu tenho lido a página de manual do iptables (leitura leve na hora de dormir) e me deparei com o alvo 'TTL', mas ele avisa:
Definir ou incrementar o campo TTL pode ser potencialmente muito perigoso
e
Nunca defina ou aumente o valor nos pacotes que saem da sua rede local!
Posso ver como talvez diminuir ou diminuir o TTL poderia causar a queda de pacotes antes de chegar ao destino, mas que efeito poderia ter o incremento?
Respostas:
O TTL é diminuído quando passa por um roteador. Isso garante que, se o pacote estiver viajando em círculos, ele acabará morrendo.
O campo TTL de um pacote IP v4 é um campo de 8 bits (255 decimal). Portanto, defini-lo alto no início não é um grande problema, pois não pode ser tão grande em um pacote bem formado (embora algumas coisas possam aceitar pacotes IP malformados).
No entanto, se algo o incrementar e a etapa de incremento fizer parte do loop , o pacote poderá continuar em círculos sem chegar a zero. Com o tempo (pode ser muito curto ou um vazamento gradual), os pacotes podem se acumular no sistema que contém esse loop, causando sobrecarga.
O TTL nos pacotes mantém o roteamento saudável, basicamente. Se um pacote tiver um TTL muito grande e for pego em uma rota circular por algum motivo, isso poderá causar uma tonelada de tráfego (chamado de "tempestade de pacotes") e interferir nas operações normais. Um TTL muito baixo resultaria em perda de conectividade, pois você perderia o pacote antes que ele chegasse ao destino.
Há um ponto em que as respostas parecem ter sido perdidas, mas que seriam puramente acadêmicas (por causa de quantos saltos parecem ser necessários na internet): se um pacote normalmente falhar em chegar ao destino por causa de um TTL expirado, aumentá-lo permitiria que o pacote chegasse ao seu destino, mas não afetaria o retorno dos pacotes e eles expirariam antes de chegar à sua rede.
ATUALIZAÇÃO: De acordo com esta página na Wikipedia :
Em teoria, no IPv4, o tempo de vida é medido em segundos, embora todo host que passe pelo datagrama deva reduzir o TTL em pelo menos uma unidade. Na prática, o campo TTL é reduzido em um a cada salto. Para refletir essa prática, o campo é renomeado como limite de salto no IPv6.
ATUALIZAÇÃO 2: Como alguém atualizou meu post e referenciou a Wikipedia, achei que seria melhor fazer referência à própria RFC - http://www.ietf.org/rfc/rfc791.txt - Basta procurar por TTL lá e ele faz bastante um bom trabalho de explicá-lo:
Este campo indica o tempo máximo que o datagrama pode permanecer no sistema da Internet ... todo módulo que processa um datagrama deve diminuir o TTL em pelo menos um, mesmo que processe o datagrama em menos de um segundo
Eu sei apenas um programa, que poderia usar um valor TTL mais alto, e é isso traceroute. Como o nome diz, ele rastreia a rota para um host de destino modificando o valor TTL. O número máximo de saltos padrão é 20, mas você pode aumentar isso.
Cada roteador que lida com um pacote diminui o valor TTL, até que o pacote chegue ao seu destino ou TTL atinja zero e morra.
Como já foi dito, aumentar o TTL pode resultar em pacotes que nunca morrem, se houver um ciclo negativo. Geralmente, se um valor TTL não for grande o suficiente, a lógica para tentar um TTL maior provavelmente deve ser tratada pelos clientes de ponta a ponta.
Se você tem certeza de que um roteador não está em um ciclo (topologia em forma de árvore), em teoria, você pode aumentar com segurança o valor TTL. Dito isto, permitir mais saltos do que o padrão pode tornar o congestionamento mais provável na rede externa. Se você tiver uma longa cadeia de roteadores entre a rede interna e externa, desde que não haja ciclo, um valor TTL maior poderá ajudar. Dito isso, pode ser bastante fácil para alguém adicionar uma vantagem à rede e criar um ciclo, portanto, começar com um valor TTL maior, onde o pacote se originou em primeiro lugar, é muito mais seguro.