Warum liefert Linux keine Daten an Anwendungen, wenn die Pakete über einen Hotspot kommen?

568
Luc

Mein Ziel ist es, den Verkehr mit einem MITM-Proxy abzufangen. Dazu habe ich meinen Laptop als Host für einen WLAN-Hotspot konfiguriert, das Smartphone angeschlossen, den Proxy gestartet und das Smartphone so konfiguriert, dass mein Laptop als Proxy in diesem WLAN-Netzwerk verwendet wird.

Die Host-IP lautet 10.42.0.1und der Client 10.42.0.2. Der Proxy überwacht Port 8080, eine beliebige Schnittstelle. Es zeigt sich richtig in netstatund ich kann netcates von localhost. Das Android-Telefon ist über den 10.42.0.1Port 8080 als Proxy konfiguriert .

Vom Telefon aus kann ich pingen 10.42.0.1; In Wireshark sehe ich die Echoanfragen und die Antworten.

Wenn das Telefon jedoch ein TCP- oder UDP-Paket sendet, antwortet das System nicht. Wenn Sie den Hotspot mit netcat über UDP abhören und UDP-Daten vom Telefon senden, werden die Daten nicht an netcat übermittelt. Ich kann das Paket mit den Daten sehen, die in Wireshark eingehen, aber das Terminal bleibt leer. Beim Abhören von TCP kann ich in Wireshark das SYN-Paket sehen, das vom Telefon eingeht, aber es wird nie bestätigt (keine SYN + ACK-Antwort).

Der Hotspot ( 10.42.0.1) hat eindeutig ARP und eine Route zurück oder ICMP-Echoantworten gehen nicht aus. Es ist keine Host-Firewall installiert. Das Problem bleibt nach einem Neustart bestehen.

Was könnte das Problem sein?

0

1 Antwort auf die Frage

0
Luc

Beim Schreiben der Frage wurde mir klar, dass ich zwar wusste, dass es sich nicht um eine Firewall handeln konnte, weil ich keine installiert hatte, und es sich nicht um iptables handeln konnte, weil sie nach einem Neustart nicht bestehen bleiben würden, aber mir wurde klar, dass ich das nicht wirklich geprüft habe Es wurden keine iptables-Regeln festgelegt.

# 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

Es stellt sich heraus, dass etwas, wahrscheinlich NetworkManager in seiner unendlichen Weisheit, beschlossen hat, einige Regeln für uns hinzuzufügen, die gerne eine Firewall bereitstellen.

Eine Problemumgehung besteht darin, einige Regeln aufzuheben und die Standardrichtlinie zurückzusetzen:

# 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

Ich kann in der NetworkManager-Dokumentation oder im Quellcode keinen Hinweis darauf finden. Ich weiß nicht, was dieser Port 8528 standardmäßig zuzulassen scheint (er ist weder registriert noch an irgendeiner Stelle referenziert) und ich kann den relevanten Code, der iptables aufruft, nicht schnell finden oder relevante Einstellungen finden, um die Firewall davon abzuhalten Verbindung. Vielleicht ruft NetworkManager eine andere Software auf, die diese anschließend installiert?

Verwandte Probleme