PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Das "Nachrüsten" von IKEv2 durch AVM sehe ich (persönliche Einschätzung, durch keine AVM-Aussage untermauert) eher nicht, das ist schon einiges an Aufwand.
Das Umschwenken auf das unter Linux "übliche" Vorgehen bei IPSec-Implementierungen wird (vermutlich) auch nicht so einfach sein, der WAN-Stack ist ja in weiten Teilen proprietär und entweder das würde aufgegeben (eher friert vermutlich die Hölle zu) oder eine der möglichen Tools-Implementierungen, z.B. "racoon" oder "strongSWAN", und der "IPSec-Stack" bzw. die Transformationen allgemein wird auf den AVM-Stack angepaßt. In beiden Fällen müßte man wohl einen Wrapper für AVM-Konfigurationen schaffen, damit alte Einstellungen weiter verwendet werden können (den Aufschrei würde ich ansonsten auch nicht hören wollen, viele sind ja froh, wenn ihr VPN erst einmal "irgendwie" läuft und fassen das dann nicht mehr an).
Als ich das erste Mal den l2tpv3d in der Firmware gesehen habe (muß irgendwann in einer 06.10-Labor gewesen sein), dachte ich auch noch, AVM würde damit am Ende L2TP/IPSec für die "native Verbindung" mit MS-Betriebssystemen implementieren wollen. Leider wird der aber wohl nur für das Tunneln des Verkehrs von Clients an Repeatern zur "Hauptbox" verwendet, damit dort dann die ganzen Zugriffskontrollen noch auf der Basis von MAC-Adressen arbeiten können, ansonsten "sähe" man da ja nur die Repeater selbst und nicht die Clients (ich habe keinen Repeater mehr, daher ist das nur geschlußfolgert und nicht getestet bzw. mit einem Dump verifiziert).
Aber damit sollten eigentlich schon alle Bestandteile in der FRITZ!Box vorhanden sein, um tatsächlich L2TP/IPSec "zusammenzustöpseln" ... dabei unterstützt Windows dann auch schon länger IKEv1 bei der Aushandlung der Verschlüsselung. Wenn es bei W10 immer mehr in Richtung mobiler Geräte geht und die Verwendung eines gesonderten Clients nicht mehr "en vogue" ist, bin ich mal gespannt, wie die Reaktion von AVM ausfallen wird. Entweder man investiert Aufwand in eine Anpassung des (m.E. ohnehin schlechten, weil als Filter realisierten) AVM-Clients auch für W10 (ggf. dann als "App") oder man baut einfach auf die bereits im Betriebssystem eingebauten Mechanismen und setzt eben auf L2TP/IPSec, wo man den Aufwand hineinsteckt. Wenn W10 sich auf mobilen Geräten tatsächlich relevante Marktanteile sichern kann (ich schätze mal, so ab 10% wird das dann interessant), dann käme sicherlich auch etwas in der Richtung ... ich glaube nicht, daß AVM auf Dauer den Kunden auf einem Surface 3 die Verwendung des "FRITZ!Fernzugang"-Clients ans Herz legen will. L2TP/IPSec hätte dann auch bereits wieder die Mechanismen, um eine benutzerbasierte VPN-Verbindung zu realisieren (wie es XAuth auch bietet).
Ich hatte ja immer ein wenig die Hoffnung, daß AVM da bereits dran ist und als hier letztens in Berlin mehrmals Angebote für Freelancer im Rahmen der "Zertifizierung eines IPSec-Konnektors" "umgingen":
, habe ich schon überlegt, ob AVM da der Auftraggeber sein könnte und sich vielleicht mit einem zugekauften Produkt etwas am VPN der FRITZ!Boxen ändern könnte.
Das Umschwenken auf das unter Linux "übliche" Vorgehen bei IPSec-Implementierungen wird (vermutlich) auch nicht so einfach sein, der WAN-Stack ist ja in weiten Teilen proprietär und entweder das würde aufgegeben (eher friert vermutlich die Hölle zu) oder eine der möglichen Tools-Implementierungen, z.B. "racoon" oder "strongSWAN", und der "IPSec-Stack" bzw. die Transformationen allgemein wird auf den AVM-Stack angepaßt. In beiden Fällen müßte man wohl einen Wrapper für AVM-Konfigurationen schaffen, damit alte Einstellungen weiter verwendet werden können (den Aufschrei würde ich ansonsten auch nicht hören wollen, viele sind ja froh, wenn ihr VPN erst einmal "irgendwie" läuft und fassen das dann nicht mehr an).
Als ich das erste Mal den l2tpv3d in der Firmware gesehen habe (muß irgendwann in einer 06.10-Labor gewesen sein), dachte ich auch noch, AVM würde damit am Ende L2TP/IPSec für die "native Verbindung" mit MS-Betriebssystemen implementieren wollen. Leider wird der aber wohl nur für das Tunneln des Verkehrs von Clients an Repeatern zur "Hauptbox" verwendet, damit dort dann die ganzen Zugriffskontrollen noch auf der Basis von MAC-Adressen arbeiten können, ansonsten "sähe" man da ja nur die Repeater selbst und nicht die Clients (ich habe keinen Repeater mehr, daher ist das nur geschlußfolgert und nicht getestet bzw. mit einem Dump verifiziert).
Aber damit sollten eigentlich schon alle Bestandteile in der FRITZ!Box vorhanden sein, um tatsächlich L2TP/IPSec "zusammenzustöpseln" ... dabei unterstützt Windows dann auch schon länger IKEv1 bei der Aushandlung der Verschlüsselung. Wenn es bei W10 immer mehr in Richtung mobiler Geräte geht und die Verwendung eines gesonderten Clients nicht mehr "en vogue" ist, bin ich mal gespannt, wie die Reaktion von AVM ausfallen wird. Entweder man investiert Aufwand in eine Anpassung des (m.E. ohnehin schlechten, weil als Filter realisierten) AVM-Clients auch für W10 (ggf. dann als "App") oder man baut einfach auf die bereits im Betriebssystem eingebauten Mechanismen und setzt eben auf L2TP/IPSec, wo man den Aufwand hineinsteckt. Wenn W10 sich auf mobilen Geräten tatsächlich relevante Marktanteile sichern kann (ich schätze mal, so ab 10% wird das dann interessant), dann käme sicherlich auch etwas in der Richtung ... ich glaube nicht, daß AVM auf Dauer den Kunden auf einem Surface 3 die Verwendung des "FRITZ!Fernzugang"-Clients ans Herz legen will. L2TP/IPSec hätte dann auch bereits wieder die Mechanismen, um eine benutzerbasierte VPN-Verbindung zu realisieren (wie es XAuth auch bietet).
Ich hatte ja immer ein wenig die Hoffnung, daß AVM da bereits dran ist und als hier letztens in Berlin mehrmals Angebote für Freelancer im Rahmen der "Zertifizierung eines IPSec-Konnektors" "umgingen":
Code:
08.10.2015
SW-Architekt C++ / embedded systems / krypto (m/w)
Beginn:
Einsatzort: 19.10.2015 - 31.12.2015
Berlin / evtl z.T. remote
Textauszug:
SW-Architekt C++ / embedded systems / krypto (m/w) Berlin / evtl z.T. remote
Projektbeschreibung Konzeption und Implementierung von Maßnahmen zur Optimierung der Performance eines Liefergegenstandes (Konnektor), der durch einen Unterauftragnehmer bereit gestellt wird.
Vertrauter Umgang mit Objektorientierter Programmierung und SW-Architekturen von C++-Programmen
Kenntnisse
Mind. 10 Jahre Erfahrung mit Objektorientierter Programmierung und Programmierung in C++
Sehr gute Netzwerkkenntnisse zu SSL, DNS, PKI, X.509, RSA, ECC
Sehr gute Kenntnisse der Protokolle IPSec und IKE
Gute Kenntnisse von SOAP und Verschlüsselungsverfahren
Gute Erfahrung mit embeddet devices
Beginn / Dauer 19.10.2015 - 31.12.2015
Anzahl der gesuchten Mitarbeiter (m/w) 1
