Sem usar soquetes brutos, existe uma maneira no Linux de forçar um pacote de rede a ser enviado fisicamente para um gateway primeiro, mesmo que o endereço de destino esteja vinculado a uma interface local?
Meu sistema tem uma única interface ativa, eno1
, à qual é atribuído um IPv4 192.168.1.1
com uma /20
máscara. O gateway tem endereço 192.168.0.1
. Eu tentei adicionar uma rota usando ip route add 192.168.1.0/24 via 192.168.0.1
, que tem a maior especificidade de roteamento para 192.168.1.1
. Mas a chamada traceroute 192.168.1.1
ainda mostra apenas um único salto, indicando que não foi a lugar nenhum. Eu esperaria que mostrasse um primeiro salto de 192.168.0.1
, seguido por 192.168.1.1
. Evidência adicional para a rota que não está sendo seguida é que o envio de pacotes com SO_TIMESTAMPING
resultados em carimbos de data/hora de hardware ausentes, indicando que o pacote não foi realmente colocado na rede.
Caso este seja um problema XY, estou tentando construir uma ferramenta de medição semelhante a ping que mede a latência de ida e volta e a perda de pacotes para o CMTS do meu ISP, mas o roteador usa limitação de taxa nas respostas ICMP, então não posso t medir a latência com a frequência que eu gostaria. Além disso, pings de dispositivos locais na minha rede contam com o limite de taxa, levando a pacotes descartados espúrios (embora eu suponha que poderia bloquear o encaminhamento de pacotes com o CMTS como destino ou aqueles com TTL = 1). Observe que, enquanto estou testando isso localmente em um sistema em minha rede privada usando meu próprio roteador como primeiro salto, na realidade estarei executando isso no próprio roteador, substituindo o .1.1
endereço pelo meu endereço IPv4 público e o .0.1
endereço com o endereço do roteador upstream do CMTS.
Meu pensamento era enviar um pacote para o roteador upstream com um destino de meu próprio IP público, o que, com sorte, resultaria no envio de volta ao meu próprio roteador, tendo percorrido cada perna uma vez, mas aparecendo para o ISP como encaminhado genérico tráfego em vez de algo ao qual o CMTS responde diretamente.
Idealmente, a solução pode ser configurada uma vez como superusuário e, em seguida, usada por tarefas de espaço de usuário, ou seja, não requer a execução da ferramenta como superusuário (daí o desejo de evitar raw-sockets).