[Frage] FRITZ!Box 6490 Cable (lgi) UM 141.06.50: Spontane "NAS-IP" Port-Freigabe für 443?!?

[odoll]

Moin,

heute fand ich eine von meiner UM 6490 um 2:10 verschickte "Push"-Mail in meinem Postfach, in der sie mir Folgendes mitteilte:

Datum	Protokoll	Port	an Computer	an Port
23.11.2016 02:09	TCP	45495	tubedoor-NAS (a.b.c.254)	443

Stutzig geworden musst ich erst mal feststellen, dass mir UM, obwohl Business-Tarif, seit Oktober zum ersten mal ein neue WAN IPv4 zugeteilt hatte (weil ich kam nicht drauf; bisher 5.x.y.z).

Das Log sieht wir folgt aus:

23.11.16 10:32:05    Anmeldung des Benutzers <user> an der FRITZ!Box Benutzeroberfläche von IP-Adresse g.h.i.j.
23.11.16 02:08:28    Freigabe für Port 45495 auf a.b.c.254 (tubedoor-NAS) hinzugefügt.
23.11.16 02:08:22    Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 95.223.168.79, DNS-Server: 80.69.96.12 und 81.210.129.4, Gateway: 95.x.y.z
23.11.16 02:08:09    Anmeldung der Internetrufnummer +49202abcdefg war nicht erfolgreich. Ursache: DNS-Fehler [3 Meldungen seit 23.11.16 02:05:51]
23.11.16 02:05:40    Anmeldung der Internetrufnummer nNNNNNNNNN_3 war nicht erfolgreich. Ursache: Gegenstelle antwortet nicht. Zeitüberschreitung.
23.11.16 02:05:30    Anmeldung der Internetrufnummer +49202abcdefg war nicht erfolgreich. Ursache: DNS-Fehler
23.11.16 02:03:56    Anmeldung der Internetrufnummer nNNNNNNNNN_3 war nicht erfolgreich. Ursache: Gegenstelle antwortet nicht. Zeitüberschreitung.
23.11.16 02:03:33    Anmeldung der Internetrufnummer +49202abcdefg war nicht erfolgreich. Ursache: DNS-Fehler [2 Meldungen seit 23.11.16 02:03:12]
23.11.16 02:02:32    Anmeldung der Internetrufnummer nNNNNNNNNN_3 war nicht erfolgreich. Ursache: Gegenstelle antwortet nicht. Zeitüberschreitung. [2 Meldungen seit 23.11.16 02:01:18]
23.11.16 02:01:15    Anmeldung der Internetrufnummer +49202abcdefg war nicht erfolgreich. Ursache: DNS-Fehler
23.11.16 02:01:01    Internetverbindung ist fehlgeschlagen: Fehlergrund: 2 (DHCPv4 no answer on DISCOVER)
23.11.16 02:00:44    Anmeldung der Internetrufnummer nNNNNNNNNN_1 war nicht erfolgreich. Ursache: Gegenstelle antwortet nicht. Zeitüberschreitung. [3 Meldungen seit 23.11.16 01:58:06]
23.11.16 01:55:02    Freigabe für Port 45495 auf a.b.c.254 (tubedoor-NAS) entfernt.
23.11.16 01:54:57    Internetverbindung wurde getrennt.
23.11.16 01:54:57    Internetverbindung ist fehlgeschlagen: Fehlergrund: 1 (DHCPv4 lease timed out)
23.11.16 01:46:10    Anmeldung der Internetrufnummer nNNNNNNNNN_2 war nicht erfolgreich. Ursache: Gegenstelle antwortet nicht. Zeitüberschreitung. [2 Meldungen seit 23.11.16 01:44:56]
23.11.16 01:29:49    Anmeldung der Internetrufnummer nNNNNNNNNN_1 war nicht erfolgreich. Ursache: Gegenstelle antwortet nicht. Zeitüberschreitung.
23.11.16 00:42:55    Anmeldung der Internetrufnummer nNNNNNNNNN_3 war nicht erfolgreich. Ursache: Gegenstelle antwortet nicht. Zeitüberschreitung.
23.11.16 00:38:32    Anmeldung der Internetrufnummer +49202abcdefg war nicht erfolgreich. Ursache: Gegenstelle antwortet nicht. Zeitüberschreitung. [5 Meldungen seit 23.11.16 00:33:49]

Was hat es denn mit dieser Portfreigabe auf sich? (Die sich wohl schon von Anfang an in meiner Konfig befindet)

PS: wie bereits von Peterpawn angedeutet, "sprechen" die beiden CPUs miteinander über den Port (weil zweimal 443 geht nicht)?

 

[PeterPawn]

"sprechen" die beiden CPUs miteinander über den Port (weil zweimal 443 geht nicht)?

Ja und nein ... diese Portfreigabe wird dann eingerichtet, wenn man den externen Zugriff auf's GUI freigibt. Der zweite Kern (x86) mit den NAS-Funktionen wird dann einfach wie jeder andere beliebige Host im LAN mit einer Portfreigabe behandelt (bei IPv4) und beim Zugriff auf den "FRITZ!NAS"-Link im GUI wird mit einem Fehler 302 der externe Client auf den anderen Port umgeleitet, wo dann direkt die NAS-CPU antwortet. Das spart den Reverse-Proxy auf dem ARM-Core und die Daten müssen nicht erst komplett durch das Linux-System dort wandern.

Bei 20 MBit/s im Upload käme so ein Proxy (wenn der dann auch noch selbst TLS auf dem ARM-Core machen soll) wohl nicht mehr hinterher und würde zur eigentlichen Bremse ... bei dieser Lösung kann der x86-Core in aller Ruhe die ganze (TLS-)Verschlüsselung übernehmen und kommt tatsächlich auf einen besseren Durchsatz (egal ob Up- oder Downstream, denn die Verschlüsselung ist bei externem Zugriff auf das GUI natürlich immer dabei), wobei das natürlich nur für die Übertragung einer (größeren) Datei wirklich eine Rolle spielt, denn im Vergleich dazu sind die paar Daten für den Seitenaufbau beim FRITZ!NAS ja zu vernachlässigen.

 

[odoll]

"Long Shot": könnte man sich das zu Nutze machen und evt. auch den IPsec VPN Verkehr über einen anderen Port auf den x86er umleiten und dort "beackern" zu lassen?

 

[PeterPawn]

Nicht den vom AVM-VPN ... das muß dann schon AVM selbst machen, weil auf dem x86-Core kein "avmike" existiert, usw.

Aber mit einem selbst übersetzten OpenVPN für den x86-Core (am besten statisch linken) kann man auch das VPN vom ARM-Core holen.

Bei anderen Puma6-Geräten habe ich auch schon IPSec mit dem Intel CEFDK gesehen (z.B. bei Hitrons) - zumindest die Binaries. Ob das bei AVM auch auf den x86-Core "aufzupropfen" wäre, müßte man mal probieren - ich denke aber, da werden auf dem x86-Core gar keine Transformationen im IP-Stack (CONFIG_XFRM) möglich sein.