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:
- Eu executo meu programa. Ele aloca e instancia o dispositivo TUN e aguarda que o dispositivo seja ativado.
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
Agora meu programa começa a ler pacotes com sucesso (e imprime/registra seu conteúdo).
- 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 tshark
o 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 tun0
novamente, 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.