¿Por qué Linux no entrega datos a las aplicaciones cuando los paquetes llegan a través de un punto de acceso?

¿Por qué Linux no entrega datos a las aplicaciones cuando los paquetes llegan a través de un punto de acceso?

Mi objetivo es interceptar el tráfico con un proxy MITM. Para hacer esto, configuré mi computadora portátil para albergar un punto de acceso Wi-Fi, conecté el teléfono inteligente, inicié el proxy y configuré el teléfono inteligente para usar mi computadora portátil como proxy en esta red Wi-Fi.

La IP del host es 10.42.0.1y la del cliente 10.42.0.2. El proxy escucha en el puerto 8080, cualquier interfaz. Aparece correctamente netstaty puedo acceder netcata él desde localhost. El teléfono Android está configurado para funcionar como proxy a través 10.42.0.1del puerto 8080.

Desde el teléfono puedo hacer ping 10.42.0.1; en Wireshark veo las solicitudes de eco que entran y las respuestas que salen.

Sin embargo, cuando el teléfono envía un paquete TCP o UDP, el sistema no responde. Cuando se escucha en el punto de acceso con netcat en UDP y se envían datos UDP desde el teléfono, los datos no se entregan a netcat. Puedo ver el paquete con datos entrantes en Wireshark, pero el terminal permanece en blanco. Cuando escucho en TCP, puedo ver en Wireshark el paquete SYN que llega desde el teléfono, pero nunca se reconoce (no hay respuesta SYN+ACK).

El punto de acceso ( 10.42.0.1) claramente tiene ARP y una ruta de regreso o respuestas de eco ICMP no saldrían. No hay ningún firewall de host instalado. El problema persiste después de reiniciar.

¿Cual podría ser el problema?

Respuesta1

Mientras escribía la pregunta me di cuenta de que, aunque sabía que no podía ser un firewall porque no tenía ninguno instalado, y no podía ser iptables porque no persistirían después de un reinicio, me di cuenta de que en realidad no lo había comprobado. no se establecieron reglas de iptables.

# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
DROP       all  --  anywhere             anywhere             state INVALID
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     udp  --  anywhere             anywhere             udp dpt:isakmp
ACCEPT     esp  --  anywhere             anywhere
ACCEPT     ah   --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8528

Resulta que algo, probablemente NetworkManager en su infinita sabiduría, decidió agregar algunas reglas para nosotros, feliz de proporcionarnos inesperadamente un firewall.

Una solución alternativa es eliminar algunas reglas y restablecer la política predeterminada:

# iptables -L --line-numbers
Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
2    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps
3    ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
4    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
5    DROP       all  --  anywhere             anywhere             state INVALID
# iptables -D INPUT 5
# iptables --policy INPUT ACCEPT

No puedo encontrar ninguna referencia a nada de esto en la documentación de NetworkManager o incluso en el código fuente. No sé qué es este puerto 8528 que parece permitir de forma predeterminada (no está registrado ni referenciado en ninguna parte) y no puedo encontrar rápidamente el código relevante que llama a iptables, ni encontrar ninguna configuración relevante para evitar que bloquee el firewall. conexión. ¿Quizás NetworkManager llama a algún otro software que posteriormente lo instala?

información relacionada