WireGuard: Dauerhaften Verbindungen nicht dauerhaft

[WulfmanGER]

Hallo in die Runde,

Erstmal mein Aufbau:
Pi.Hole mit Wireguard <-> Fritz!Box <-> Client(s) (iOS)
Und somit NAT (ipv4), DNS-Update erfolgt unmittelbar (Max. 1min nach 24h/Discon bin ich wieder erreichbar). Die Clients haben fixe lokale IP-Adresse.

Anwendungszweck: Pi.Hole soll auch unterwegs seinen Dienst tun. Dazu gibt es 1-2 Dienste im LAN die ich Remote nutzen möchte.

Problem:
Ich bin gerade im Ausland (AT) und habe regelmäßig das Problem das Wireguard „Tod“ ist. VPN-Verbindung ist aufgebaut, aber es läuft Nichts rüber.

Flugmodus an/aus bringt nichts, ich muss explizit Wireguard öffnen und deaktivieren/aktivieren. Das hält dann etwas aber kurioserweise nicht so lang wie in DE (da kann ich den ganzen Tag in LTE rumlaufen und alles super; hier in AT geht das nicht)

Meine Idee war jetzt das es am PersistentTimeout liegt. Davon gibt es aber ja zwei: Client (0) und Server (Standard; also nichts). Aber welcher ist relevant und was trägt man da am besten ein?

Ich brauch ja wegen DNS eine permanente Verbindung - somit wäre Clientseitig doch 0 die richtige Wahl. Aber Server? Oder wo habe ich hier sonst ein Problem?

Danke schon mal

 

[Mar1u5]

Ändert sich evtl. die IP deiner FB und danach funktioniert die Verbindung nicht mehr? Der DynDNS wird glaube ich nur beim Start der Verbindung von der Wireguard App zur IP aufgelöst und nicht während aufgebauter Verbindung aktualisiert.

 

[DonConto]

0 heißt deaktiviert. Ich würde es mit dem empfohlenen Default von 25sek clientseitig probieren.

 

[Raijin]

Das Problem ist, dass WireGuard kein wirklich Handling für wechselne Enpunkte hat. Wie @Mar1u5 schon geschrieben hat löst WireGuard nur einmalig beim Start die Domain auf und das war's. Das heißt, dass selbst ein Timeout das Problem vermutlich nicht löst, weil tendenziell einfach nur erneut mit der bereits ermittelten IP neu verbunden wird. Wobei sich das zwischenzeitlich durchaus geändert haben kann, das kann ich nicht beurteilen, weil ich vorwiegend OpenVPN einsetze und bei meinen WireGuard-Szenarien wechselne IPs keine Rolle spielen.

Hier wird das an einem anschaulichen Beispiel gezeigt und in dem Falle über einen cronjob als Script gelöst. Das ist bei einem Mobiltelefon natürlich eher schwierig, sofern das Telefon nicht gerootet ist.

Ein Workaround wäre beispielsweise ein gemieteter VPS im www mit statischer IP-Adresse. Aber ein Server im Internet will auch ordentlich abgesichert werden, weil man sonst den nächsten Bot für Hackergruppe XY vorbereitet...


*edit
Bei OpenVPN ist es im übrigen so, dass mittels der timeout-Optionen (zB ping-restart) die Verbindung vollständig neu aufgebaut wird, inkl. erneuter DNS-Auflösung. Deswegen lässt sich mit OpenVPN eine stabilere Dauerverbindung nutzen als es bei WireGuard der Fall ist. Ein OpenVPN-Server daheim, sei es parallel oder als Ersatz für WireGuard, wäre also ebenfalls eine Alternative. Siehe hier

 

[spcqike]

Ich kann den Vorrednern nur zustimmen. Solche Probleme, wie du sie beschreibst, kenne ich nur, wenn die IP des Heimanschlusses sich ändert.

Wireguard löst die DNS nur einmal am Anfang auf. ändert sich dann die IP des Anschlusses, sendet der Client die Pakete immer noch an die alte IP.

der persistentkeepalive ändert daran auch nichts. im Gegenteil: Am Handy würde ich den nicht einschalten. Der führt unweigerlich zu einem erhöhten Akkuverbrauch.

Das gute an Wireguard ist ja grade, dass der Verbindungsaufbau (Handshake) nur 20ms dauert. Die Verbindung ruht, solange keine Daten durch das VPN geschickt werden müssen. Das spart Datenvolumen (minimal, aber hey) und Akku. OpenVPN verbraucht meiner Erfahrung nach auf dem Handy viel mehr Strom, da der Tunnel dauerhaft offen gehalten wird und minimale Datenpackete verschickt werden, was das Modem permanent aktiv lässt.

Persistentkeepalive brauchst du bspw, wenn du ein Gerät, welches hinter einer Firewall sitzt, jederzeit erreichen willst. Bspw. ein PC/Pi/NAS/... hinter einer Firewall. Ein Peer, zu dem du von Außen nicht selbstständig eine Verbindung aufbauen kannst.
Beim Handy ist das meiner Meinung nach unnötig. wie oft greifst du von Außen auf dein Handy zu?

Was steht denn im Log, wenn der Handshake nicht mehr zustande kommt? Hat sich die IP der Fritz!Box vielleicht wirklich geändert?

Mir fällt grade noch ein:
Einer meiner Peers hat auch ein Problem damit, wenn sich meine IP zu Hause verändert. Normalerweise erkennt Wireguard, dass dass die externe IP eines Peers sich geändert hat (also nachdem der Peer die Verbindung erneut aufbauen möchte) und ändert dann die Peer-IP in seiner config. Bei meiner OPNSense FIrewall, einem Synology NAS und auf dem Root-Server funktioniert das auch prima, nur auf einem Edgerouter-X nicht. bei diesem muss die IP meines Anschlusses manuell erneuert werden... bei den restlichen Systemen reicht es, wenn einmalig eine neue Verbindung aufgebaut wird. Diese erkennen dann, dass die Anfrage nicht mehr von A.B.C.D sondern nun von A.B.C.E kommt, und berücksichtigen das. nur der ER-X nicht... der braucht einen Neustart vom Wireguard Service inkl. erneuter Namensauflösung...

 

[foofoobar]

Das Problem ist, dass WireGuard kein wirklich Handling für wechselne Enpunkte hat.

Jein, wenn für eine "Verbindung" ein gültiges Pakt von einer IP kommt die WG nicht als aktuellen Peer hat wird diese Adresse als neuer Peer übernommen. Oder man konfiguriert eine neuen Peer von Hand.

Hilft allerdings bei NAT-Quirks oder dummen Middleboxen zwischen den Peers nicht immer.

 

[spcqike]

Hilft allerdings bei NAT-Quirks oder dummen Middleboxen zwischen den Peers nicht immer.

Kannst du das näher erläutern? Ich suche immer noch den Grund, warum besagter ER-X keine Verbindung mehr aufbaut und akzeptiert, wenn sich meine heimische Adresse wechselt.

Vielleicht komme ich dem Problem da ja etwas näher

(wie gesagt, zu Hause läuft Wireguard auf ner OPNSense VM, am Remoteplatz auf dem ER-X hinter einem Draytek Modem. Ich verstehe nicht, warum nur der ER-X Probleme macht, wenn sich meine IP zu Hause ändert. beim Handy mit wechselnder IP hat der ER-X ja auch keine Probleme....)

 

[foofoobar]

Was auch immer ER-X sein mag und wie auch immer deine Topologie mit was für einer Konfig aussieht, meine Glaskugel ist gerade defekt.
Normalerweise würde man mit dem tracen (z.b. tcpdump) anfangen, bzw. sich überlegen ob dort wo es jetzt funktioniert es möglicherweise Zufall ist das es funktioniert.