☰

capturar paquetes IP cuando la puerta de enlace no es el enrutador ISP

tag-icon • tag-icon linux networking ip
capturar paquetes IP cuando la puerta de enlace no es el enrutador ISP

En mi red doméstica tengo la siguiente topología

          Internet
              |
     wifi     |
C ----------- A ---------- B

dónde

  • A (IP estática 192.168.0.254) es el enrutador/AP proporcionado por mi ISP.
  • B (IP estática 192.168.0.1) es una máquina Linux que funciona como servidor DNS y DHCP local (ejecutando dnsmasq)
  • C es cualquier cliente que se conecta al AP y está configurado por DHCP.

Por ahora, la puerta de enlace predeterminada proporcionada por B (como servidor DHCP) es solo A.

Entonces, supongamos que quiero capturar en B todo el tráfico proveniente de cualquier cliente C. Esto es lo que hice en B:

  1. activar el reenvío de IP con

    # sysctl net.ipv4.ip_forward=1"

  2. suministre B como puerta de enlace. Por supuesto, el propio B utiliza A como su propia puerta de enlace.

  3. ejecute tcpdump en B para ver qué está pasando

En un cliente C, inicio cualquier solicitud, por ejemplo

$ traceroute www.google.com

Ahora, espero que el tráfico que se origina en C se dirija a B, luego a A y finalmente a Internet.

Que funciona.C puede acceder a Internet

Qué no funciona.Excepto por la primera solicitud, parece que B se omite por completo: tcpdump no muestra nada; la dirección de B no aparece en la salida de traceroute. Aún así, estoy seguro de que el redireccionamiento se realiza porque C queda desconectado de Internet si desactivo el reenvío de IP en B.

Si se produce algún tipo de cortocircuito, ¿cómo puedo evitarlo?

Descargo de responsabilidad: Sé que cambiar la topología de la red podría resolver el problema de "capturar todo el tráfico" (por ejemplo, mediante duplicación de puertos, etc.), pero realmente quiero entender qué está pasando con mi configuración y cómo solucionarlo sin cambiar la topología.

Respuesta1

Necesita que el host B realice traducciones NAT para que A no vuelva a ver el mismo paquete. En lugar de eso, B debería enviar paquetes a través de A como si se originaran en B. Para lograrlo, agregue una iptablesregla de la siguiente manera:

# iptables -t nat -A POSTROUTING -s ip-of-C -j MASQUERADE

Según esa regla, todos los paquetes que salen de B se reescribirán para que procedan de B, pero manteniendo una tabla de retrotraducciones, de modo que las respuestas asociadas puedan volver a traducirse y enviarse a C.

Tenga en cuenta la -s ...parte que limita la regla para que solo se aplique a los paquetes provenientes de C (o podría configurarse como la LAN local) y, por ejemplo, no a los paquetes de respuesta.

EDITAR (teniendo en cuenta el comentario de @theuncle): La explicación de por qué no funciona sin NAT sería que el host B se da cuenta de que el paquete entra y sale sin cambios en la misma interfaz, por lo que puede mejorar la red diciéndole a C hablar directamente con A para el tráfico en cuestión.

información relacionada