Reenvío de tráfico desde el dispositivo TUN (backend C ++) a la puerta de enlace predeterminada

10

El siguiente problema es solo una parte de la solución más grande con la que tengo un problema. Todos los demás elementos parecen funcionar hasta ahora, así que intentaré describir una pieza muy pequeña con la que tengo problemas.

Tengo una máquina Linux, con tun0 (interfaz de túnel) y eth0 (bruja es mi puerta de enlace predeterminada a internet).

Objetivo: mi objetivo es recibir paquetes entrantes desde tun0 y reenviarlos a la puerta de enlace predeterminada. Así que, en realidad, es un caso NAT bastante simple, donde quiero "compartir" Internet con tun0 que simula la interfaz física.

Tun ha sido creado usando

sudo openvpn --mktun --dev tun0 --user USER
sudo ip addr add 10.2.0.1/24 dev tun0
sudo ip link set tun0 up

Así que lo tengo en funcionamiento, puedo hacer ping, etc. Además, tengo la aplicación C ++, que se conecta a este dispositivo TUN, puede leer y escribir en él. (fti: aquí hay un tutorial que he seguido: http://backreference.org/2010/03/26/tuntap-interface-tutorial/ )

Volqué alguna solicitud ICMP (ping) correcta hecha a 8.8.8.8 en la matriz de bytes en C ++. Ahora, usando mi programa, lo escribo en el dispositivo tun0. La solicitud ICMP tiene

  • fuente (10.2.0.10) - para que el núcleo conozca la ruta de regreso (la misma subred)
  • destino (8.8.8.8) - DNS de Google
  • suma de comprobación correcta, etc. (en Wireshark / TShark aparece correctamente en tun0)

Entonces, tengo las siguientes rutas:

iptables -F # flush
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface tun0 -j ACCEPT

Y aquí estoy atascado :( El paquete no se reenvía al gw predeterminado (tshark lo ve solo en tun0 como recibido, lo que supongo que es correcto)

Lo que falta Tal vez algún enfoque alternativo (pero tiene que hacerse usando un dispositivo tun, y tengo que ser capaz de ejecutarlo). Información adicional:

  • el reenvío está habilitado (/ proc / sys / net / ipv4 / ip_forward)
  • 8.8.8.8 es accesible a través de eth0 (desde local)
  • la puerta de enlace predeterminada es correcta (desde el ISP a través de eth0)
  • He intentado desactivar rp_tables (echo 0> / proc / sys / net / ipv4 / conf / eth5 / rp_filter)
  • y muchos otros...

¡Gracias de antemano por cualquier pista!

routing nat icmp forwarding tun Marcin Górski
fuente
Sé que esto tiene más de un año, pero ¿llegaste a algún lado con esto? Tengo exactamente el mismo problema.
hplbsh

Respuestas:

1

Una solución alternativa sería usar bridge. Así que puede conectar su tun0 con eth0 y no hay necesidad de nat o de configurar ip en tun0, simplemente coloque las IP de la misma subred de eth0 y la misma puerta de enlace que está utilizando en este momento en las interfaces de túnel de los clientes.

Comandos para configurar un puente:

# brctl addbr br0
# brctl addif br0 eth0 tun0

www.tldp.org/HOWTO/BRIDGE-STP-HOWTO/set-up-the-bridge

Para usar brctl tienes que instalar el bridge-utilspaquete.
Si tu distribución es Ubuntu:aptitude install bridge-utils

Arash
fuente
1

Recientemente me encontré con este problema (siguiendo la misma mención del artículo en la pregunta) y después de jugar un poco, descubrí que el siguiente comando habilita el reenvío local de los paquetes para el dispositivo tun.

echo 1 > /proc/sys/net/ipv4/conf/tun0/accept_local

Sé que es muy tarde, solo estoy publicando aquí para que cualquiera que enfrente el mismo problema pueda recibir algún tipo de ayuda.

Swarup Sengupta
fuente