Cenário:

Cenário:

Resumindo

Os pacotes que são lidos de uma interface TUN não encontram seu caminho quando são gravados de volta na mesma interface TUN.

Na íntegra

Cenário:

Em uma máquina com apenas1NIC (eth0) que está conectado à Internet, escrevi um aplicativo que lê pacotes IP da interface TUN; então pode:

  • escreva o pacote sem qualquer alteração na mesma interface TUN
  • bloquear pacote
  • fazer alterações no pacote (por exemplo, criptografar sua carga útil) e gravar o pacote manipulado de volta na interface TUN.

Feito:

Eu passei pelas seguintes etapas:

  1. Eu executo meu programa. Ele aloca e instancia o dispositivo TUN e aguarda que o dispositivo seja ativado.
  2. Então executo os seguintes comandos:

    ifconfig tun0 up ifconfig tun0 10.0.0.2 route add -net 0.0.0.0 netmask 0.0.0.0 dev tun0 echo 1 > /proc/sys/net/ipv4/ip_forward

  3. Agora meu programa começa a ler pacotes com sucesso (e imprime/registra seu conteúdo).

  4. Meu programa escreve de volta o pacotesem qualquer alteraçãovoltar ao dispositivo tun0

PROBLEMA:

O pacote reescrito não encontra sua rota de volta para ir, por exemplo, para eth0 ou para a camada de aplicação. Por exemplo, quando executo um ping:

ping 4.2.2.4

e em outro terminal:

tshark -i tun0

Vejo que o tun0 vê o pacote de eco ICMP (também meu programa):

 10.0.0.2 → 4.2.2.4      ICMP 84 Echo (ping) request  id=0x14b1, seq=2/512, ttl=64
 10.0.0.2 → 4.2.2.4      ICMP 84 Echo (ping) request  id=0x14b1, seq=3/768, ttl=64
 10.0.0.2 → 4.2.2.4      ICMP 84 Unknown ICMP (obsolete or malformed?)

Meu programa escreve de volta o pacote em tun0 e tsharko vê (no trecho acima)

Mas a solicitação ICMP não chegaeth0para que pudesse encontrar o caminho para 4.2.2.4. IMHO, há um problema com as regras de roteamento, mas não consegui descobrir como modificá-lo.

Qualquer comentário é bem-vindo, Atenciosamente

Responder1

é claro que há um problema com as regras de roteamento, você disse ao kernel para rotear todos os pacotes tun0:). Quando você envia esse pacote de volta tun0, ele é roteado tun0novamente, não eth0. Exceto que parece que no seu caso o pacote foi descartado devido ao "filtro de caminho reverso", ou seja, ele se recusa a devolver os pacotes da mesma interface em que entraram.

informação relacionada