Ich versuche, ein Raspberry Pi Model B+ als WLAN-Zugangspunkt mit der IP-Adresse 192.168.0.1 zu verwenden. Dieser Zugangspunkt sollte den gesamten HTTP- und HTTPS-Verkehr auf einen anderen Computer mit der IP-Adresse 192.168.0.29 auf Port 8080 umleiten.
Auf 192.168.0.29 verwende ich Burp Proxy, das auf eingehende Verbindungen wartet. Ich habe Burp mit der Option „unsichtbares Proxying unterstützen“ konfiguriert.
Ich habe den WLAN-Zugangspunkt erfolgreich eingerichtet und kann mich mit verschiedenen Client-Rechnern damit verbinden. Die Internetverbindung über den Zugangspunkt funktioniert ebenfalls einwandfrei.
Ich habe hostapd zum Einrichten des WLAN-Zugangspunkts verwendet.
Wenn ich jedoch versuche, die Proxy-Konfiguration hinzuzufügen, funktioniert der Zugriffspunkt nicht mehr. Ich kann sehen, dass ausgehende Anfragen über meinen Proxy unter 192.168.0.29 laufen, aber ich erhalte keine Antworten auf dem Proxy oder auf den Client-Computern, die versuchen, den Proxy zu verwenden.
Ich verwende die folgende Konfiguration auf meinem Pi:
sudo iptables-legacy -t nat -A POSTROUTING -j MASQUERADE
sudo iptables-legacy -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.0.29:8080
sudo iptables-legacy -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 192.168.0.29:8080
Burp hört zu und die Option „unsichtbares Proxying unterstützen“ ist aktiviert. Ich sehe jedoch keine eingehenden Antworten, sondern nur die ausgehenden Anfragen.
Dies ist das Ergebnis einer curl-Anforderung anhttps://webhook.site/
curl "https://webhook.site/213c00e4-5ec8-4c8d-a89a-34d542c6d81/network=PiAP" -v [17/12/22 14:07:10]
* Trying 46.4.105.116:443...
* Connected to webhook.site (46.4.105.116) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
* subject: C=PortSwigger; O=PortSwigger; OU=PortSwigger CA; CN=webhook.site
* start date: Dec 3 13:00:10 2022 GMT
* expire date: Dec 3 13:00:10 2023 GMT
* subjectAltName: host "webhook.site" matched cert's "webhook.site"
* issuer: C=PortSwigger; ST=PortSwigger; L=PortSwigger; O=PortSwigger; OU=PortSwigger CA; CN=PortSwigger CA
* SSL certificate verify ok.
> GET /213c00e4-5ec8-4c8d-a89a-34d542c6d81/network=PiAP HTTP/1.1
> Host: webhook.site
> User-Agent: curl/7.84.0
> Accept: */*
>
^C
Ich sehe die eingehende Anfrage nicht unterhttps://webhook.site, was mich fragen lässt, ob die ausgehende Anfrage tatsächlich wie erwartet funktioniert.
Dies ist die Ausgabe von ifconfig:
ifconfig | grep 192
inet 192.168.0.29 netmask 0xffffff00 broadcast 192.168.0.255
Und das ist Traceroute
traceroute google.com
traceroute to google.com (142.250.181.206), 64 hops max, 52 byte packets
1 192.168.0.1 (192.168.0.1) 16.717 ms 4.513 ms 3.043 ms
2 fritz.box (192.168.178.1) 3.710 ms 3.758 ms 3.484 ms
3 ip1f11XXXX.dynamic.kabel-deutschland.de (31.17.8X.XXX) 17.808 ms 35.506 ms 14.934 ms
4 ip5886XXXX.static.kabel-deutschland.de (88.134.21X.XXX) 16.788 ms 14.614 ms 14.202 ms
5 ip5886XXXX.dynamic.kabel-deutschland.de (88.134.18X.XXX) 13.349 ms 13.917 ms 16.057 ms
6 145.254.3.88 (145.254.3.88) 20.858 ms 18.649 ms 17.655 ms
7 145.254.2.217 (145.254.2.217) 26.106 ms 16.028 ms 17.017 ms
8 72.14.194.138 (72.14.194.138) 17.006 ms