☰

Guión:

tag-icon • tag-icon linux networking routing firewall network-interface
Guión:

En resumen

Los paquetes que se leen desde una interfaz TUN no encuentran su camino cuando se vuelven a escribir en la misma interfaz TUN.

En su totalidad

Guión:

En una máquina con sólo1NIC (eth0) que está conectada a Internet, he escrito una aplicación que lee paquetes IP desde la interfaz TUN; entonces puede:

  • escribir el paquete sin ningún cambio en la misma interfaz TUN
  • bloquear paquete
  • realizar cambios en el paquete (por ejemplo, cifrar su carga útil) y escribir el paquete manipulado en la interfaz TUN.

Hecho:

He seguido los siguientes pasos:

  1. Ejecuto mi programa. Asigna e crea una instancia del dispositivo TUN y espera a que se active el dispositivo.

  2. Luego ejecuto los siguientes 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. Ahora mi programa comienza a leer paquetes con éxito (e imprime/registra su contenido).

  4. Mi programa, vuelve a escribir el paquete.sin ningún cambiovolver al dispositivo tun0

PROBLEMA:

El paquete devuelto escrito no encuentra su ruta de regreso para ir, por ejemplo, a eth0 o a la capa de aplicación. Por ejemplo cuando ejecuto un ping:

ping 4.2.2.4

y en otra terminal:

tshark -i tun0

Veo que tun0 ve el paquete de eco ICMP (también mi 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?)

Mi programa escribe el paquete en tun0 y tsharklo ve (en el fragmento anterior)

Pero la solicitud ICMP no llegaeth0para que pudiera encontrar su camino hacia 4.2.2.4. En mi humilde opinión, hay un problema con las reglas de enrutamiento, pero no pude encontrar cómo modificarlo.

Cualquier comentario es bienvenido, Saludos

Respuesta1

Por supuesto, hay un problema con las reglas de enrutamiento, usted le dijo al kernel que enrute todos los paquetes desde tun0:). Cuando envía ese paquete nuevamente a tun0, se enruta nuevamente tun0, no a eth0. Excepto que parece que en su caso el paquete se descarta debido al "filtro de ruta inversa", es decir, se niega a rebotar paquetes desde la misma interfaz en la que entraron.

información relacionada