VPN-Problem Wireguard Client in fremden Netzwerk

Es gibt 5 Antworten in diesem Thema, welches 666 mal aufgerufen wurde. Der letzte Beitrag () ist von daujens.

    Ich bin mir relativ sicher, das der Fehler nicht in der UDM liegt, aber vielleicht hat ja jemand eine Idee.


    Die Aufgabe: Ich will/soll einen PV-Wechselrichter an einem fernen Standort monitoren. Der vorhandene Router soll nicht geändert werden. Also habe ich mir einen ThinClient (FSC Futro S550) genommen. Dort ein Debian 11 aufgesetzt. Auf diesem läuft WireGuard sowie Node-Red. Der WireGuard verbindet sich bei Systemstart mit meiner UDM und Node-Red sammelt die Daten vom WR und sendet sie mir dann via MQTT. Funktioniert auch alles so wie es sein soll.


    Allerdings ist nach 1-3 Tagen immer die Verbindung weg und mir bleibt nicht übrig als mich am entfernten Standort zu melden und den ThinClient via Stecker raus/rein neu zu starten. Selber vor Ort zu schauen ist aufgrund der Entfernung etwas aufwändiger.

    Als ich mal dort war, sah es nach einem Problem der DNS-Auflösung aus. Ist ja soweit auch erstmal erklärbar, da der Client ja nicht mitbekommt ob/wann der Router die Internetverbindung trennt und WireGuard ja wohl nur bein Tunnel starten eine DNS-Anfrage stellt.

    Also habe ich entsprechen https://blog.netways.de/blog/2…it-dynamischen-dns-namen/ eine Neuauflösung alle 5 min eingestellt. Leider war jetzt nach 3 Tagen der Tunnel wieder down.

    Den ThinClient habe ich auch schon mal gewechselt, also einen FSC Futro 720 mit Debian 11 und auch WireGuard/Node-Red. Dort war der selbe Fehler, also kann ich die Hardware auch ausschließen.


    Setup: ferner Standort Speedport Smart 3 am Telekom Magenta, ThinClient dort im LAN via DHCP

    Bei mir läuft eine UDM SE hinter einem Lancom883+ wobei der Lancom nur Modem ist. Leitung ist auch Telekom Magenta.

    In der UDM auch Dynamic-DNS via spdns.de aktiv.

    2 andere Standorte mit je einer Fritzbox 7530 laufen als LAN/LAN-Kopplung seit Monaten problemlos.


    Und jetzt fehlen mir die Ideen. Zumal ich auch nicht wüsste, ob/wo ich in dem Debian ein Ereignissprotokoll finde. Meine Linux-Kenntnisse sind eher rudimentär und beschränken sich meisst auf des nacharbeiten von im Netz zu findenden Tutorials.


    Danke

    Die Idee mit dem anpingen und im Bedarfsfall neu starten finde ich schon mal einen guten Ansatz. Ich vermute mal ganz stark, dass dieses Script bei Dir nicht so ganz das tut was es soll. Da müsste man ja direkt prüfen ob der Hostname noch auf die IP zeigt, die dann aktiv als Endpoint verwendet wird, was nur vor Ort geht ohne das Blech neu zu starten.


    Ich hatte gleiches Problem mit einem Edgerouter der als Wireguardclient arbeitet und auf einen DDNS hostnamen connected hat. Die Verbindung ging immer dann flöten wenn die IP des Serveranschlusses sich geändert hat. Das konnten 2 Wochen sein und dann 3 Nächte hintereinander bis zum "Ausfall". Ich hab mir dann mit meinen bescheidenen Scriptingkünsten auch einen Cronjob gebastelt, der den aktiven Wireguard Endpoint ohne Neustart des Wireguarddienstes geändert hat. Das sorgte dafür dass die Zeiten zwischen den Ausfällen deutlich länger wurden. Sie waren aber noch immer da. Es gab da immer eine Konstellation in der das Skript in einen nicht nachvollziehbaren Zustand geriet und dann keine Änderungen mehr erkannte. Hab das dann sein lassen weils ehh noch mehr Tunnel zu dem Zel werden sollten und der Kunde hat dann den Tarif gewechselt mit fester IP.


    Eine andere Lösung wäre natürlich auch der Einsatz eines VPS in einem Rechenzentrum mit fester IP. Dann alle beteiligten dorthin verbinden und routen. Die Kosten sind da auch noch recht überschaubar, zumal Du nur relativ wenig Traffic hast und der virtuelle Server dann von der Ausstattung kleiner gewählt werden kann. Könnte man in betracht ziehen falls diese Lösung evtl. noch auf weitere Standorte ausgedehnt werden soll.


    In debian findest Du unter /var/log alle möglichen Logfiles von irgendwelchen Softwarepaketen, so diese irgendwas loggen. Ich denke mal im syslog oder daemonlog solltest Du zumindest irgendwelche Wireguardmeldungen sehen können. Wenn ich nicht irre schaut das Skript nach dem letzten Handshake und setzt dann auch nur den Enpoint für den Peer neu. Kann also sein dass Du bis auf den Start von Wireguard nix findest, je nachdem wie gesprächig das logging ist.

    Einen externen Server mieten ist keine Option, da die ganze Monitoring-Geschichte mehr Spielen als produktiv wichtig ist.

    Im schlimmsten Fall könnte ich ja mir einfach einen öffentlichen MQTT-Server suchen und die Daten daruber zu schieben.

    Ich will aber auch ergründen, wo der Fehler liegt, also werd ich mal demnächst hinfahren und mal die Logs durcharbeiten.

    Ansonsten muss ich mich mal mit den Script zum ping und wireguard neustarten beschäftigen.

    Ich bin ja schon froh, das ich nicht allein mit diesem Problem bin.


    Ich überlege parallel auch, zumindest bis ich eine funktionierende Wireguardlösung gefunden habe, im Router mir den Port 22 auf irgendeinen wilden externen Port zu routen um zumindest via ssh auf die Kiste raufzukommen zum schauen.

    Theoretisch könntest Du dir auch eine Wireguard Einwahl auf dem Rechner erstellen und dann per SSH ... Bei Einwahl bei Bedarf hast Du das Problem mit dem DDNS und den IPs ja eher nicht so stark bemerkbar. Dann müsste sich schoon in der Sitzung die IP ändern. Dann brauchst Du auch kein ssh Port forwarden. Der wird auch auf hohen ports recht schnell gefunden und gebruteforced.

    Zitat von Peterfido

    Per Node Red das Gegenüber anpingen, wenn der Ping länger weg ist, die ganze Kiste einfach neustarten.

    Zwar nicht ganz so brutal aber prinzipiell so habe ich jetzt (erstmal) gelöst. Ich starte nicht den Rechner sondern nurf den Tunnel neu.

    Funktioniert seit 3 Tagen daher bin ich zuversichtlich.