☰

Por que o Linux não entrega dados aos aplicativos quando os pacotes passam por um hotspot?

tag-icon • tag-icon networking networkmanager
Por que o Linux não entrega dados aos aplicativos quando os pacotes passam por um hotspot?

Meu objetivo é interceptar o tráfego com um proxy MITM. Para fazer isso, configurei meu laptop para hospedar um hotspot Wi-Fi, conectei o smartphone, iniciei o proxy e configurei o smartphone para usar meu laptop como proxy nesta rede Wi-Fi.

O IP do host é 10.42.0.1e do cliente 10.42.0.2. O proxy está escutando na porta 8080, em qualquer interface. Ele aparece corretamente netstate posso netcatfazer isso no host local. O telefone Android está configurado para proxy via 10.42.0.1porta 8080.

Do telefone, posso fazer ping 10.42.0.1; no Wireshark vejo as solicitações de eco chegando e as respostas saindo.

Porém, quando o telefone envia um pacote TCP ou UDP, o sistema não responde. Ao ouvir no hotspot com netcat em UDP e enviar dados UDP do telefone, os dados não são entregues ao netcat. Posso ver o pacote com dados chegando no Wireshark, mas o terminal permanece em branco. Ao ouvir no TCP, posso ver no Wireshark o pacote SYN vindo do telefone, mas ele nunca é reconhecido (sem resposta SYN+ACK).

O ponto de acesso ( 10.42.0.1) claramente possui ARP e uma rota de retorno ou respostas de eco ICMP não seriam enviadas. Não há firewall de host instalado. O problema persiste após uma reinicialização.

Qual poderia ser o problema?

Responder1

Ao escrever a pergunta, percebi que, embora soubesse que não poderia ser um firewall porque não tinha nenhum instalado, e não poderia ser iptables porque eles não persistiriam após uma reinicialização, percebi que na verdade não verifiquei isso nenhuma regra de iptables foi definida.

# 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

Acontece que algo, provavelmente o NetworkManager em sua infinita sabedoria, decidiu adicionar algumas regras para nós, feliz em fornecer inesperadamente um firewall.

Uma solução alternativa é eliminar algumas regras e redefinir a política padrão:

# 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

Não consigo encontrar nenhuma referência a nada disso na documentação do NetworkManager ou mesmo no código-fonte. Não sei o que é essa porta 8528 que parece permitir por padrão (não está registrada nem referenciada em lugar nenhum) e não consigo encontrar rapidamente o código relevante que chama o iptables ou encontrar quaisquer configurações relevantes para impedir que ele bloqueie o conexão. Talvez o NetworkManager chame algum outro software que o instale posteriormente?

informação relacionada