Iptables-Weiterleitungs-Webinterface von E3531

Iptables-Weiterleitungs-Webinterface von E3531

Ich habe einen Raspberrypi mit einem E3531 UMTS-Stick, der mit dem Internet verbunden ist. Da der Rpi ohne Header ist, wollte ich das Webinterface des Sticks über die IP des Rpi verfügbar machen.

Der Stick baut ein Netzwerk von 192.168.8.0/24 auf, wobei die Schnittstelle die 192.168.8.1 hat und der Rpi immer die 192.168.8.100 erhält. Auf die Webschnittstelle wird über einfaches http zugegriffen. Auf den Rpi kann entweder über ein Wireguard-VPN (aufgebaut über den Stick) zugegriffen werden, wobei er die 10.253.3.4/24 hat, oder über seine physikalische eth0-LAN-Wartungsschnittstelle mit 192.168.13.24/24. Idealerweise sollte die Webschnittstelle über beide Wege zugänglich sein.

Mein erster Ansatz war, dass die LAN-Schnittstelle zwei Regeln befolgte:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.8.1:80
iptables -t nat -A POSTROUTING -o enx001e101f0000 -j MASQUERADE

Die erste Regel dient dazu, die http-Anfragen des eth0 des Rpi selbst an das Webinterface weiterzuleiten und die zweite, die Quelladresse für die Schnittstelle des Sticks zu maskieren (enx001e101f0000).

Leider funktioniert es nicht. Wenn ich im Browser mit auf den Rpi zugreife, http://192.168.13.24wird die Anfrage geändert in http://192.168.8.1/html/index.html?url=192.168.13.24und der Fehler ERR_ADDRESS_UNREACHABLEwird angezeigt.

Was übersehe ich hier und woher kommt dieser Abfrageparameter „URL“?

Vielen Dank im Voraus

Antwort1

Dies liegt an der Konfiguration des http-Servers auf dem Stick, die Sie nicht (zumindest nicht dauerhaft und ohne Änderung der Firmware) ändern können.

Eine Möglichkeit für Sie besteht darin, einen Reverse-Proxy auszuführen und die vom Stick zurückgegebene URL umzuschreiben.

Die übergeordnete Frage ist, warum Sie überhaupt drei DHCP-Server benötigen. Um die Einrichtung zu vereinfachen, sollten Sie einen davon deaktivieren.

verwandte Informationen