Problem mit FritzboxVPN und rsync

flomow

Neuer User
Mitglied seit
3 Jun 2011
Beiträge
21
Punkte für Reaktionen
0
Punkte
0
Hallo *,

ich möchte gerne von einem Linux-PC auf die Diskstation (DS716+) per rsync und ssh sichern.
Beide Geräte stehen an verschiedenen Standorten und haben einen Internetanschluss.
Datenmenge: ca 400GB, von Sicherung zu Sicherung geändert ca 16GB

Mein Problem: Bei Verbindung der Geräte über ein Fritzbox-zu-Fritzbox-VPN steigt irgendwann reproduzierbar die Fritzbox auf Diskstation-Seite aus (7362SL). Die Fritzbox auf Linux-PC-Seite (7390) hat dieses Problem nicht.

Setze ich auf DS-Seite eine Freigabe und sichere "direkt" über das inet/ssh, dann gibt es keine Probleme.

(Das log der Fritz gibt keine brauchbare auskunft - die Fritzbox auf DS-Seite muss dann tatsächlich resettet werden [vom Strom getrennt], auch Telefonie geht nicht mehr...)

Hat jemand ähnliche Probleme oder ist das Problem bekannt?

Viele Grüße, flomow
 
es sieht nach Problem mit Memory-Engpaß aus
Rsync-Programm ist bekannt für großen Memory-Bedarf bei Sync von large-files, evtl. steigt Rsync aufgrund von Out-of-Memory aus.

Vorschlag:
Bitte mal Memory-Usage per "free" während rsync-Job ansehen
Alternativ: Swapfile auf externer USB-HD anlegen

Code:
FB7362SL# cd /var/media/ftp/<Disk-Label>
FB7362SL# dd if=/dev/zero of=swapfile bs=1024 count=131072
FB7362SL# mkswap swapfile
FB7362SL# swapon swapfile


Kontrolle des swapfiles:
FB7362SL# free
 
Zuletzt bearbeitet von einem Moderator:
es sieht nach Problem mit Memory-Engpaß aus

Hallo PanthaRei,

VPN ist das doch aber egal?!
auf der Fritz!Box läuft kein rsync, die Fritzboxen machen nur das VPN....

Die DS (server) hat 2GB RAM und d er Linux-PC 32GB, da ist viel! frei....


VG, flomow
 
Gibt es nach Restart von FB7362SL ein Crashlog ?
Bitte mal supportdata.txt nachsehen
 
Setze ich auf DS-Seite eine Freigabe und sichere "direkt" über das inet/ssh, dann gibt es keine Probleme.

Könnte es sein, daß die 7362SL ein Problem mit der Rechenleistung bekommt ? VPNs können auf den SL-Boxen recht rechnintensiv sein.
Ich verstehe daß doch richtig, daß das rsync durch die VPN-Verbindung zwischen den Boxen läuft ?
Wenn Du ein Freetz auf der 7362 hättest, könnte man evtl. noch was in den Syslogs lesen, sofern diese auf einen Stick o.Ä. kommen.
 
Hey, also:

Code:
##### BEGIN SECTION CRASHLOG /proc/avm/log_sd
==========

BEGIN SECTION '/proc/avm/log_sd/crash'
----------
2015-11-03 18:05:20(1) [Bus error] avmike(1369) CRASHED at timercb_del+0x84 (/lib/libavmcsock.so.2 at 000462fc) accessing 0+0x8001800a (/lib/libewnwnet.so.0 at 5512100a)
SIGNO 10 ERRNO 0 CODE 2
Version: 06.30
No bugmsg
ze: 00000000 at: 2ac8a826 v0: 2aab7680 v1: 80000001
a0: 00000001 a1: 00000001 a2: 2af2b000 a3: 00000001
t0: 00000000 t1: 00000000 t2: 851eb624 t3: 00008000
t4: 00000001 t5: 869fbd06 t6: 851eb620 t7: 00000559
s0: 80018002 s1: 00000000 s2: 2af6d9b0 s3: 7fb9cf0c
s4: 7fb9cf94 s5: 00000000 s6: 00000000 s7: 2af1e000
t8: 00010000 t9: 2ada1280 k0: 00000000 k1: 00000000
gp: 2ac940a0 sp: 7fb9ce48 fp: 2ac42000 ra: 2ac582e0
FA 8001800a 0+0x8001800a (/lib/libewnwnet.so.0 at 5512100a)
PC 2ac582fc timercb_del+0x84 (/lib/libavmcsock.so.2 at 000462fc)
RA 2ac582e0 timercb_del+0x68 (/lib/libavmcsock.so.2 at 000462e0)
Code: 3c038000  24630001  02038026 <8e030008> 10600038  2411ffff  8e030020  14620034  8f91803c 
[bt]  2ac582d8 timercb_del+0x60 (/lib/libavmcsock.so.2 at 00046278)
[bt]  0040fc00 [0040fbd4] <0+0x40fbd4>+0x2c (/bin/avmike at 0000fbd4)
[bt]  00424ae8 _Z15FinishQuickModePP20tIKE_ExchangeContext+0x98 (/bin/avmike at 00024a50)
[bt]  00426770 _Z17QuickModeExchangePP20tIKE_ExchangeContext+0x6ec (/bin/avmike at 00026084)
[bt]  00407db4 [00406dc4] <0+0x406dc4>+0xff0 (/bin/avmike at 00006dc4)
[bt]  0040834c [004082fc] <0+0x4082fc>+0x50 (/bin/avmike at 000082fc)
[bt]  2ac43784 [2ac43448] <0+0x2ac43448>+0x33c (/lib/libavmcsock.so.2 at 00031448)
[bt]  2ac45cc4 [2ac458a0] <csock_select_with_timeval+0x10>+0x424 (/lib/libavmcsock.so.2 at 000338a0)
[bt]  00408864 [00408364] <0+0x408364>+0x500 (/bin/avmike at 00008364)
[bt]  00406a5c main+0x22c (/bin/avmike at 00006830)
-----
(first) sent on: Mon Nov 23 14:14:52 2015 UTC by support data
----------
END SECTION '/proc/avm/log_sd/crash'
==========
##### END SECTION CRASHLOG


sowohl CPU als auch Temperatur gehen nicht über die 25% Marke hinaus während rsync läuft...

Viele Grüße, flomow
 
Das sieht nach einem Problem bei Rekeying aus ... allerdings ist dieses Crash-Protokoll ja schon knapp 3 Wochen alt.

Normalerweise handeln die Peers beim IPSec einen Sitzungsschlüssel aus, der für eine begrenzte Zeit und/oder eine begrenzte Datenmenge gilt. Eines der beiden Limits war bei Dir offenbar erreicht und während der Aushandlung eines neuen Schlüssels kam es zu einem Problem, das am Ende in einem SIGBUS mündete.

Allerdings war das mit einiger Wahrscheinlichkeit doch eine softwaregenerierte Ausnahme der AVM-Firmware, denn offenbar trat das Problem in einer Routine "timercb_del" auf, die ich - rein dem Namen nach - dafür verantwortlich machen würde, daß eine Routine zur Behandlung eines Timer-Events (timer callback) aus der Kette der Handler gelöscht werden soll (del) und - auch reine Vermutung meinerseits - die wird wohl nicht mehr dort in der Queue vorhanden gewesen sein.

Ob das jetzt aber bei der Eingrenzung Deines derzeitigen Problems helfen wird, wage ich zu bezweifeln, solange dieser Fehler nicht reproduzierbar erneut auftritt.

-Wobei generell Rekeying tatsächlich zu diesen Abstürzen beitragen könnte, dazu müßte man aber wissen, wann solche Abstürze genau auftreten. Da die Lebensdauer eines Session-Keys eben entweder in Sekunden oder in Bytes "gemessen" wird, braucht es eine Beobachtung beider Größen. Die Zeit läuft auch, wenn gar keine Daten übertragen werden und eine Volumengrenze kann auch wieder zuerst überschritten werden, wenn die Leitung "dick genug" ist und eine recht lange Lebensdauer ausgehandelt wurde.

Was die FRITZ!Box selbst als Proposal an dieser Stelle anbietet, kann man am einfachsten mit einem Debug-Protokoll einer racoon- oder StrongSwan-Installation feststellen, nach dem Standard einigen sich beide Peers auf den jeweils kleinsten gemeinsamen Nenner bei beiden Werten.

Komischerweise hat AVM bei den neueren Versionen des avmike etwas eingebaut, daß bereits nach dem Ablauf von 90% der vereinbarten Lebensdauer (nach Zeit) ein zusätzlicher Session-Key (bzw. eine weitere "security association" (SA)) ausgehandelt wird und diese existiert normalerweise erst einmal parallel zu der alten. Wann genau jetzt auf den neuen Schlüssel umgeschaltet wird, kann man leider weder im AVM-Protokoll (/var/tmp/ike.log) sehen noch irgendwo anders in der Firmware ... jedenfalls habe ich dazu bisher noch nichts gefunden.

Den avmike zu debuggen ist auch alles andere als leicht ... trotz vorhandener Optionen "-d" und/oder "-v" für den Aufruf kommt man gar nicht dazu, das wirklich selbst aufzurufen, da der avmike bei aktivierten VPN-Verbindungen selbst nach einem "kill" sofort wieder neu gestartet wird und bei nicht aktivierten Verbindungen startet er zwar mit den gewünschten Einstellungen, wird aber bei jeder Änderung der VPN-Einstellungen (also auch beim Aktivieren einer Verbindung) gekillt und neu gestartet. Man muß also das eigentliche Binary /bin/avmike durch ein geeignetes Wrapper-Skript ersetzen, wenn man da etwas mehr sehen will ... wobei das auch nicht so ausführlich ist in den Release-Versionen.

Sollte es aber am Ende tatsächlich das Problem des Rekeyings sein, müßte sich der Fehler entweder bereits früher provozieren oder auf später verschieben lassen - in Abhängigkeit von den derzeit verwendeten Sets für P2. Wenn das jetzt schon eines der "LT8h"-Sets ist, sollte bei Verwendung eines "1h"-Lifetime-Sets das Problem früher auftreten. Wird schon jetzt eine Lifetime von 3600 Sekunden verwendet (wie gesagt, AVM initiiert ein Rekeying bereits nach 54 Minuten, bei den 8h-Sets nach 7:12 h), sollte ein 8h-Set das Problem (wenn es tatsächlich nur von der Zeit abhängt) nach dem Neuaufbau einer VPN-Verbindung (auch das wäre wichtig, da - wie oben geschrieben - die Zeit ab Aktivierung der SA zählt) den Fehler hinauszögern können.

Zumindest einen Blick wäre es in jedem Falle mal wert, ob es eine Abhängigkeit vom Rekeying gibt oder nicht ... den Inhalt der /var/tmp/ike.log kann man auch den Support-Daten entnehmen, dort findet sich das Hinzufügen und Entfernen von SAs in Form von Protokoll-Einträgen.
 
Hey,

im ike.log steht zum fraglicehn Zeitpunkt:

Code:
2015-11-22 20:40:05 avmike:FreeIPsecSA: spi=b213		protocol=4 iotype=1
2015-11-22 20:40:05 avmike:FreeIPsecSA: spi=8a8d4d1a		protocol=3 iotype=2
2015-11-22 20:40:05 avmike:FreeIPsecSA: spi=de92		protocol=4 iotype=2
2015-11-22 20:40:05 avmike:[hostname]
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-11-22 20:40:05 avmike:[hostname]
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-11-22 20:40:05 avmike:[hostname]
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-11-22 20:40:05 avmike:[hostname]
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-11-22 20:46:04 avmike:FreeIPsecSA: spi=cce1ddd1		protocol=3 iotype=1
2015-11-22 20:46:04 avmike:FreeIPsecSA: spi=6b73		protocol=4 iotype=1
2015-11-22 20:46:04 avmike:FreeIPsecSA: spi=b18d3a3c		protocol=3 iotype=2
2015-11-22 20:46:04 avmike:FreeIPsecSA: spi=dc70		protocol=4 iotype=2


hilft das weiter?

Danke, flomow
 
Wenn mit "fraglicher Zeitpunkt" tatsächlich 20:40 Uhr oder 20:46 Uhr gemeint ist (das letzte Erzeugen einer SA fand dann vermutlich um 19:46:xx Uhr statt), dann läuft das tatsächlich darauf hinaus.

Die Meldungen "falsche Paketlaenge" dürften dann mit einiger Wahrscheinlichkeit darauf zurückzuführen sein, daß dort noch Pakete eintreffen, die mit der alten SA (die vermutlich gerade gelöscht wurde bei "FreeIPsecSA") verschlüsselt wurden ... wenn der falsche Schlüssel verwendet wird, stimmt natürlich auch keine Längenangabe in den "entschlüsselten" Headern.

Da sieht man jedenfalls das Löschen von SAs zu unterschiedlichen Zeitpunkten in diesem Ausschnitt ... wenn das zweite Löschen 6 Minuten nach dem ersten erfolgt, deutet das auf die Verwendung von 1h-Lifetime-Sets hin und auf das "54-Minuten-Phänomen".

Eigentlich sollten die durch solche Fehler verloren gegangenen Pakete aber von einer höheren Protokollschicht mit entsprechenden Sicherungsmechanismen (z.B. TCP auf L4) wiederholt werden, so daß so ein Schlüsselwechsel ohne Konsequenzen bleibt. Wenn sich dabei eine der beiden Seiten tatsächlich komplett aufhängt, würde ich erst einmal versuchen, auf beiden Seiten die identische Firmware-Version einzusetzen (dazu steht hier bisher nichts).

Bei einer aktuellen 06.30 auf beiden Boxen solltest Du dann auf beiden Seiten eines der 8h-Sets einstellen können (die Angaben dazu findest Du in der FRITZ!Box im Verzeichnis /etc/default.$CONFIG_PRODUKT/$OEM/ipsec.cfg) und an Deiner Stelle würde ich es damit einmal versuchen. Wenn die FRITZ!Box ihrerseits nur auf Zeit spielt und gar keine Volumenbegrenzung verwendet (eigentlich Leichtsinn - ich weiß es auch für 06.30 nicht definitiv, was da abgeht), dann sollte sich Dein Problem zumindest weit nach hinten schieben lassen, ja ggf. sogar ganz beheben lassen, wenn Dir die 7:12 h für die Übertragung ausreichen und Du vor dem Start von rsync für einen Neuaufbau der VPN-Verbindung sorgst.

Ich selbst nutze z.B. regelmäßig eine NFS-Verbindung über eine solche LAN-LAN-Kopplung zweier FRITZ!Boxen (1x 7390 mit der alten 06.20 (aber ich weiß auch, wo (zumindest einige) Security-Probleme der 06.20 liegen) und 1x 7490 mit 06.30) zur Übertragung von Daten in derselben Größenordnung (allerdings nicht in einer einzelnen Datei/Verbindung) und habe eigentlich wenige bis keine Probleme mit dem Erneuern einer SA (1h life-time). Wo es klemmt, ist allerdings regelmäßig die "AVM-Zwangstrennung", bei der sich die IP-Adresse des Peers ändert. In diesem Falle werden wohl von der FRITZ!Box Pakete nicht lange genug "aufgehalten" bis die neue Verbindung wieder steht bzw. der dann notwendige Wechsel der IP-Adresse und deren Aktualisierung auf dem DynDNS-Server brauchen vermutlich so lange (ich beobachte das auch nicht jedesmal), daß für die gerade aktive Datei dann eben ein Fehler auftritt, weil die neue Adresse noch nicht im DynDNS registriert ist und mit der alten keine Verbindung mehr zustande kommt.
 
Zuletzt bearbeitet:
Mein Problem: Bei Verbindung der Geräte über ein Fritzbox-zu-Fritzbox-VPN steigt irgendwann reproduzierbar die Fritzbox auf Diskstation-Seite aus
...
(Das log der Fritz gibt keine brauchbare auskunft - die Fritzbox auf DS-Seite muss dann tatsächlich resettet werden [vom Strom getrennt], auch Telefonie geht nicht mehr

Hallo flomow,
nur um sicher zu sein,
liegt hier eine so starke Interaktionen zwischen avmike-prozess mit "dev dsl" Routing-Device vor, die die FB komplett Offline setzt ?
Ist hier evtl. VPN-CatchAll konfiguriert, d.h. alle Daten durch Tunnel, d.h. auch Internet- und VOIP-Traffic.

n.m.V. sollte es bei Non-CatchAll VPN Setting, d.h. LAN2LAN-Only-Verbindung via Proxy-Arp-Technik, eigentlich alle Zugriffe auf Internet (d.h. auch VOIP-Telefonie) noch funktionieren.

zum CatchAll Verständnis wäre auch Abschnitt accesslist= aus vpn.cfg interessant.

PantaRhei
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,171
Beiträge
2,247,421
Mitglieder
373,714
Neuestes Mitglied
Panicmaker
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.