Die von dir genannten 2 Probleme beim Export der vpn-cfg sind ja nicht schwer per Editor zu lösen: 1. vp.cfg aus den Komplett-Export herauslösen und "vereinzeln" und 2. die Klartext-Keys für den nächsten Import eintragen.
Was ich da jetzt zugegebenermaßen nicht verstehe ... warum dann nicht gleich mit einer Datei starten und die erst (mehr oder weniger mühsam, da kann man ja gerne unterschiedlicher Meinung sein) zusammenfrickeln?
Aber das ist ja nur rein akademisch, da ich bei LAN-zu-LAN-VPNs allein zwischen Fritzboxen nur den WebIF-Assistenten benötige und an den nicht per WebIF erreichbaren Einstellungen nie was editieren muss.
Das gilt aber offensichtlich nicht für jeden Anwender der FRITZ!Box und hier war es von Beginn an klar (so auch meine Aussage), daß der GUI-Editor der FRITZ!Box die Anforderungen eben gerade nicht erfüllen kann.
Mit dem aktuellen FBEditor (FBEditor-0.7.2.jar) gibt es eigentlich keine Re-Import-Probleme mehr und der funktioniert im Gegensatz zum AVM-Tool nicht nur unter Windows.
Gut, der FBEditor hat zwar auch das "Editor" im Namen, den konnte man (ich zumindest) aber nicht aus dem "Per Editor ..."-Teilsatz herauslesen. Da er aber tatsächlich die Prüfsumme korrigieren kann ab einer bestimmten Version, ist er meines Wissens auch die einzige portable Anwendung, mit der sich eine Export-Datei überhaupt noch bearbeiten läßt. Es gibt dann irgendwo noch eine PHP- oder Perl-Bibliothek (so genau weiß ich das nicht) und ein paar Shell-Skripte, die die Prüfsumme korrigieren können.
Wobei dann immer noch die Wahl zwischen Pest und Cholera bleibt ... der "Vollimport" mit dem FBEditor (oder hat der inzwischen auf die Möglichkeit, einzelne VPN-Files an die Box zu senden?) erfordert einen Neustart und der Einzelimport das Zerlegen der Export-Datei/Ersetzen der verschlüsselten Daten (mit anschließendem manuellen Import) und spätestens dann wird man sich diese Arbeit des Zerlegens nur ein einziges Mal machen wollen und die einzelnen Dateien dauerhaft irgendwo ablegen.
Die gesamte VPN-Konfigurationsverwaltung hat ja auch eine Entwicklung hinter sich ... als erstes brauchte man immer eine komplette VPN-Datei mit allen Verbindungen auf einen Schlag, die man dann importieren konnte, dann kam irgendwann die Möglichkeit des einzelnen Imports und der Verwaltung anhand des Namens und erst mit der 06.xx (glaube ich jedenfalls mich zu erinnern) der eingebaute einfache Editor.
Beide Methoden haben ihre Vor- und Nachteile. [...] Es benötigt dringend mal einen Expertenmodus und einen Facelift.
Ich vermute mal, mit Tool meinst Du "FRITZ!Fernzugang konfigurieren", oder? Kann das denn inzwischen (ich habe es schon sehr lange nicht mehr benutzt) auch einzelne Dateien für den Import erzeugen oder ist das immer noch eine monolithische Konfigurationsdatei, die anhand der irgendwo abgelegten Datenbank zu den verschiedenen Boxen immer komplett zusammengebaut wird?
Das ist ja kein Workaround, sondern vermutlich die von AVM vorgesehene Methode.
Das glaube ich nicht, das ist nur eine Zweckentfremdung dieser Einstellung, wenn man damit den einseitigen Verbindungsaufbau (solange die andere Seite keine Daten übertragen will, denn dann scheitert das ja) bewirken will. Die Einstellung dient - meine Interpretation anhand des Namens und der verwendeten Variablen in der Konfigurationsdatei - eigentlich dazu, auch dann eine VPN-Verbindung aufzubauen und aufrecht zu erhalten, wenn da eigentlich gar keine Daten zu übertragen sind. Ansonsten würde die Verbindung ja erst beim ersten zu übertragenden Paket aufgebaut und irgendwann (nach Ablauf der Lifetime) dann auch wieder geschlossen, wobei ein NAT-Timeout unterwegs auch schon einen früheren Abbruch (wegen DPD) verursachen könnte.
Wenn AVM diesen Fall tatsächlich vorgesehen hätte, müßte er "Nur auf eingehende Verbindung warten" oder so ähnlich heißen und dann eben genau weder "remotehostname" noch "remoteip" setzen. Der avmike kann damit sehr gut umgehen und baut dann nur diese Verbindungen nicht selbst auf, d.h. er ist nur noch Responder für diese Verbindungen und ansonsten funktioniert alles reibungslos ... und zwar inklusive Keepalive-Ping, was bei aufgebauter Verbindung ja dann wieder NAT-Connections am Leben halten kann und soll.
Die Kollisionen bei dem VPN-Startversuch durch die DSL-Box gehen übrigens nach ein paar Minuten Nichtbenutzung vorbei. Ein "Verbindung dauerhaft halten" versehentlich auf der falschen Box kann das VPN dagegen sogar tagelang blockieren - gerade erst erlebt! Erst das Abschalten der Option auf dieser Box und eine SIP-Registrierung aus der Gegenrichtung mit dem richtigen Timing hat mir da den eher umständlichen Teamviewer-Einsatz erspart.
Es beruhigt mich, daß Du diese Kollisionen auch hast und sie nicht nur bei mir auftreten, wenn ich eine ungeeignete Konfiguration verwende. Wenn Du nach der von mir beschriebenen Methode vorgehst, kannst Du diese Kollisionen aber komplett vermeiden, dann braucht es kein Timing mehr. Auch ein "dauerhaft halten"
zu einer Box mit einer nicht-öffentlichen IP-Adresse spielt dann keine Rolle mehr, da das dabei eingesetzte ICMP-Paket ganz einfach verworfen wird, denn die Box kann mangels Ziel die Verbindung nicht aufbauen (sie versucht es auch erst gar nicht, wenn man nach dem Log in /var/tmp/ike.log urteilen will).
mit der Option "Bestimmte DNS-Anfragen immer über den VPN-Tunnel auflösen" die HOSTS-Variante zu ersetzen. Hat das jemand mal zum Laufen gebracht?
Ich glaube nicht, daß das eine erfolgsversprechende Variante ist. Wenn mich der GUI-Editor nicht täuscht, behandelt er genau drei Fälle von IPSec-VPNs:
1. Transport-Mode mit XAUTH und Config-Mode, FRITZ!Box ist der Server -> das sind die Verbindungen für "Benutzer" und die Box baut nie selbst solche Verbindungen auf
2. Transport-Mode mit XAUTH und Config-Mode, FRITZ!Box ist der Client -> Verbindung mit Firmennetzwerk und die Box muß solche Verbindungen selbst aufbauen
3. Tunnel-Mode (leider nur mit PSK und ohne Zertifikate), FRITZ!Box ist halt ein Endpunkt -> LAN-LAN-Kopplung und ob/wann da Verbindungen aufgebaut werden, hängt von der konkreten Konfiguration ab
Im Fall 2 besteht dann unter Umständen die Notwendigkeit, einem per VPN eingewählten Client andere Adressen für (interne) Dienste anzubieten, als einem externen ... ein Mail-Server ist ein häufiges Beispiel, gerne auch mal ein Intranet-Webserver anstelle der öffentlichen Website. Da bei der Konfiguration des VPN-Tunnels per "Config-Mode" auch ein DNS-Server automatisch konfiguriert werden kann, kann man dann bestimmte Domains festlegen, für die eine Namensabfrage über den Tunnel zum DNS-Server der Firma gehen soll und nicht über den Standard-DNS der Box. Das ist vermutlich nicht das, was Du erreichen willst, denn erstens würde das keine Tunnel-Mode-Connection mehr sein und zweitens muß das dann tatsächlich immer mit FQDN abgefragt werden.
Wenn Dich das mit dem Domain-Namen nicht stört, kannst Du ja auch einen externen DNS-Server (auf einem vServer irgendwo z.B.) betreiben und die FRITZ!Boxen auf diesen DNS-Server ansetzen. Wenn dieser DNS-Server dann für alles jenseits seines Horizonts als Forwarder arbeitet (oder auch gleich selbst rekursiv abfragt), dann kannst Du das zumindest für die Abfragen der FRITZ!Box so regeln.
Das Problem sind eigentlich meist eher die Windows-Clients, aber auch da gibt es eine Lösung, die zwar etwas einmaligen Konfigurationsaufwand erfordert, sich aber wunderbar an Änderungen anpaßt und eigentlich auch sehr gut skaliert. Wenn Windows-PCs tatsächlich ihren jeweiligen Domain-Namen über DHCP beziehen und der kommt von der FRITZ!Box, dann heißt die Domain überall "fritz.box" und so wird das dann eher nichts. Wenn man sich aber eine Domain (Name ist ziemlich egal, wir nehmen mal "meinedomain.de" an) zulegt und für jeden FRITZ!Box-Standort dort eine Subdomain anlegt (box_a.meinedomain.de, box_b.meinedomain.de, usw.) und dann auf den Windows-Clients explizit eine Domain-Reihenfolge für Namensauflösung festlegt, genauso wie einen Domain-Suffix für die Netzwerkkarte, dann meldet sich sogar der Windows-PC ganz ordentlich mit einem Versuch der Aktualisierung seiner eigenen IP-Adresse beim DNS-Server für diese Domain und versucht sie zu aktualisieren. Wenn dann also ein PC z.B. "pc1.box_b.meinedomain.de" heißt und auf einen genauso konfigurierten PC (pc2) bei Box A zugreifen soll, dann funktioniert das sogar mit der Angabe "pc2", wenn nur kein anderer "pc2" in irgendeiner Domain weiter vorne in der Suchreihenfolge existiert. Für Linux-Clients läßt sich das natürlich genauso realisieren, Knackpunkt ist halt, daß der Client seine eigene Adresse registriert und nicht auf die ansonsten übliche DHCP-DNS-Integration vertraut wird.
Problem bleibt halt der eigene DNS-Server. Den kann man allerdings theoretisch sogar auf einer definierten FRITZ!Box oder einem NAS hinter einer Box o.ä. laufen lassen. Dann muß man aber tatsächlich auf allen anderen Boxen die Benutzung dieses DNS-Servers konfigurieren (das ginge sogar mit der internen Adresse, dann braucht es eben eine funktionierende VPN-Verbindung für die Namensauflösung) und parallel dazu jeweils einen DNS-Server des Providers, der solange genutzt wird, wie der eigene DNS-Server mal nicht funktioniert bzw. vor dem Aufbau der VPN-Verbindung, wenn man die interne Adresse nimmt. Da dabei auch die Server-Adresse des Providers als zweiter Server statisch eingetragen werden muß, ist man allerdings bei Änderungen seitens des Providers gekniffen. Die gerne genommene Variante, da einfach einen Google-DNS-Server einzusetzen, finde ich persönlich suboptimal, die kriegen ohnehin schon zuviel mit.
Wenn sich AVM mal dazu entschließen könnte, die per DHCP ausgelieferte Domain konfigurierbar zu machen und den DNS-Server (nach innen) ebenso, wäre das alles wesentlich simpler zu lösen (besonders die Konfiguration zweier statischer DNS-Server in der FRITZ!Box kann ein echter Fallstrick sein). Aber ansonsten ist auch die Lösung mit dnsmasq eine denkbare Alternative, auch dafür braucht man nicht gleich immer unbedingt ein Freetz-Image. Das ist aber natürlich alles nicht für lau und ohne Beschäftigung mit der Materie zu haben und dürfte daher für die allermeisten eher ein paar Nummern zu groß sein. Aber für einen kleinen IT-Dienstleister, der den Überblick über die von ihm betreuten Schäfchen behalten will und dabei auch mal mehrere kleine Filialen o.ä. vernetzen muß, ist das m.E. eine gangbare Lösung, wenn man es mit FRITZ!Boxen realisieren will.
