Weiterleitung über iptables funktioniert nicht mehr

[Zerstoerer]

Guten Abend zusammen,

aktuell läuft bei mir zu Hause ein Odroid C2 mit USB-Festplatte und einem Nextcloud-Dienst. Dieser ist auch voll funktionstüchtig und bisher hatte ich noch keine Probleme damit. Da ich allerdings keinen Zugriff auf den Router habe, ich den Server aber im Internet verfügbar machen möchte, habe ich mir einen VPS gemietet, dort einen VPN-Server erstellt, sodass sich der Odroid automatisch als Client anmeldet und jeglicher Verkehr auf Port 80 und 443 per iptables mit dnat und snat an den Odroid weitergeleitet wird.
Bis heute früh hat das auch alles prima funktioniert, denn da gab es noch eine funktionierende CalDAV-Synchronisierung, aber ab irgendwann danach ist der Server nicht mehr erreichbar(Chrome: ERR_CONNECTION_TIMED_OUT).
Wenn ich mich selbst in das VPN einklinke und direkt auf die IP-Adresse von Nextcloud zugreife, habe ich weiterhin Zugriff darauf, deshalb schätze ich, dass der Fehler bei der Weiterleitung liegen muss. Deshalb habe ich schon versucht meine Regeln neu zu erstellen, leider ohne Erfolg. Meine aktuellen Regeln sehen so aus:

iptables -t nat -A PREROUTING -d X.X.X.X -p tcp --dport 443 -j DNAT --to-dest 10.8.0.14:443
iptables -t nat -A POSTROUTING -d 10.8.0.14 -p tcp --dport 443 -j SNAT --to-source 10.8.0.1

iptables -t nat -A PREROUTING -d X.X.X.X -p tcp --dport 80 -j DNAT --to-dest 10.8.0.14:80
iptables -t nat -A POSTROUTING -d 10.8.0.14 -p tcp --dport 80 -j SNAT --to-source 10.8.0.1

Dabei ist X.X.X.X die externe IP, 10.8.0.1 der VPN-Server und 10.8.0.14 der Nextcloud-Server. Nun meine Frage: Hätte einer von euch eine Idee, wo hier noch ein Fehler liegen könnte oder wie ich an die Sache weiter ran gehen könnte, um den Fehler zu finden?

Wäre dankbar für ein paar Tipps.

 

[snaxilian]

Wurde dein VPS ggf neu gestartet und du hattest das IP-Forwarding nicht permanent eingerichtet? Wie man dies einrichtet, steht z.B. hier.

Ansonsten ein klassischer Fall für Wireshark bzw direkt tcpdump auf der Shell:
Filtern auf tcp und 80/443 und dann auf allen beteiligten Interfaces einen Dump starten.

Dann siehst du schon mal ob netzwerkseitig die Kommunikation zwischen externer Anfrage z.B. vom Handy auf VPN-Server per Forwarding bis zum Nextcloud-Server funktioniert. Wenn dies irgendwo hakt, weißt du schon einmal an welchem Gerät du weiter suchen musst.

 

[Zerstoerer]

Also IP-Portforwarding ist natürlich aktiviert, das hatte ich auch schon geprüft. Mit Wireshark werde ich sicher mal testen, aber ich schätze der Fehler liegt irgendwo bei der Weiterleitung, weil im VPN funktioniert die Verbindung ja.

Edit: Ok,der Tipp mit tcpdump hat mir schonmal geholfen, ich habe heute mal auf beiden Geräten den Verkehr analysiert und bin zu folgendem Ergebnis gekommen:
1. Die Pakete werde vom VPN-Server aus dem Internet empfangen und weitergeleitet.
2. Der VPN-Server erhält aber nie eine Antwort vom VPN(Nextcloud)-Client.
3. Der VPN-Client erhält die weitergeleiteten Pakete.
4. Der VPN-Client hat innerhalb des VPN leider auch gar keinen Internetzugriff mehr, außerhalb schon und sendet deshalb auch nichts nach außerhalb.

Hat jemand nun noch eine Idee, woran es liegen könnte, das nie eine Antwort zurückgesendet wird?

 

[snaxilian]

Wenn die Pakete vom "Internet" über den VPN-Server bis zum Nextcloud-Server kommen aber nicht zurück, dann würde ich mal die gesetzten Routen auf dem Nextcloud-Server überprüfen. Dieser müsste im besten Fall als Default-Gateway den VPN-Server, also die 10.8.0.1, eingetragen haben.

 

[Zerstoerer]

Okay, dies ist meine aktuelle Routingtabelle, wenn ich im VPN bin:



Interpretiere ich die 1. Zeile richtig, dass für das Internet(externe Netz) als Gateway die IP 10.8.0.13 verwendet wird? Wäre nun hier schon die Lösung zu finden, da die IP des VPN Servers ja 10.8.0.1 beträgt?

 

[snaxilian]

Ich frage mich wo die 10.8.0.13 her kommt, hast du die mal selbst gesetzt oder wird die per openVPN gepusht? Prinzipiell müsste hier anstatt der .13 die IP des VPN-Servers stehen aber nicht nur in der ersten Zeile sondern auch in der sechsten. Ist eine kleine Sonderlösung von openVPN da es so ohne administrative Rechte das Default-Gateway "ändern" kann.

Der Fehler wird vermutlich entweder in der server.conf liegen oder in der client.ovpn, in einer von beiden wirst ja die routen eingetragen haben, die bei erfolgreicher Einwahl gesetzt werden sollen.

 

[Zerstoerer]

Also ich habe die gerade schon mal überprüft, das Einzige was vom Server gepusht wird, ist:

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

Sonst kommt da nix. Kann ich die Route denn irgendwie manuell ersetzen?

 

[snaxilian]

Die genaue Syntax hängt von der verwendeten Distribution und Version ab aber einer guter Anfang wäre: http://letmegooglethat.com/?q=linux+add+delete+route