Per Editor lässt sich auch das lösen
Bitte erkläre (mir und auch späteren Lesern) doch, was Du damit meinst. Welcher Editor und wie ist das konkret zu lösen?
Das alles ändert aber nichts daran, dass frz per WebIF schneller zu seinem Ziel gekommen wäre
Das mag sein, ich will darüber nicht richten ... denn ich kenne die konkreten Voraussetzungen nicht gut genug.
Wenn frz erst "FRITZ!Fernzugang konfigurieren" installieren mußte (das weiß ich nicht, Du ?), dann kann das tatsächlich so sein. Wenn er Template-Files verwenden konnte oder das Programm bereits installiert war, ist das längst nicht mehr so eindeutig, da selbst bei "FRITZ!Fernzugang konfigurieren" einem einzelnen Aufruf des Programms zwei Aufrufe per GUI (einer auf jeder Box) gegenüber stehen. Natürlich muß man auch eigene Dateien erst mit zwei GUI-Aufrufen installieren, aber es sind keine weiteren Einstellungen vorzunehmen und die Fehlerwahrscheinlichkeit sinkt, eben weil die beiden Konfigurationsdateien von "FRITZ!Fernzugang konfigurieren" gleich für beide Seiten passend erstellt werden und damit abweichende Angaben für Netzwerkadressen und/oder PSK usw. direkt vermieden werden.
Gerne genommen ist nämlich der Fehler (aus Unaufmerksamkeit), das entfernte Gateway anstelle der Netzwerk-Adresse anzugeben, da das nicht geprüft wird - das ist mir selbst schon passiert, obwohl ich in dem Glauben lebe, mich mit VPNs an sich und dem AVM-IPSec-VPN im Speziellen ziemlich gut auszukennen. Da eine Angabe des Gateway samt Maske eigentlich in das Segment umgerechnet werden könnte und sich daraus dann gleich noch eine funktionierende keepalive_ip ableiten ließe, liest man manchmal eben nicht so genau (aber das war selbstverständlich (m)ein Fehler, den man nicht direkt dem Assi anlasten muß, den er aber als "Assistent" problemlos aufzeigen könnte); das mit dem ungenauen Lesen soll aber dem Vernehmen nach nicht nur mir passieren.
Da man den Preshared-Key (vollkommen zurecht, nicht daß ich das kritisiere, ich konstatiere es nur) bei jedem Editieren von Eigenschaften der VPN-Verbindung erneut eingeben muß, bleibt auch das eine potentielle Fehlerquelle und die Sicherheit wird durch die - bei ausreichend kompliziertem PSK unumgängliche - Speicherung (und sei es in Form eines Notizzettels) des PSK im Klartext an irgendeiner anderen Stelle auch ggü. der Klartext-Speicherung in einer für den Import geeigneten Datei nicht verbessert.
Meine Aussage ("Nimm Dateien und einen Editor.") bezog sich auch auf einen konkreten Kritikpunkt ("dual use" für die Adresse/den Namen der Gegenstelle), der existiert objektiv und führt jenseits der Standardkonfiguration zu Problemen - eine Seite mit nicht-öffentlicher IP-Adresse ist ein solcher Spezialfall. Auch die immer wieder auftauchende Anforderung, die VPN-Verbindung nur für bestimmte Clients zuzulassen (was eine Anpassung der accesslist-Eintragungen erforderlich macht), erfordert ein nachträgliches Editieren der VPN-Konfiguration und das ist nun einmal nur auf zwei Wegen möglich ... entweder direkt über Telnet auf der Box (was dann bei DOCSIS-Boxen nicht mehr funktioniert) oder den Export der gesamten FRITZ!Box-Konfiguration.
Bei den Änderungen an der Export-Datei besteht dann seit 06.20 wieder die Schwierigkeit, daß der Import nur noch mit korrekter Prüfsumme möglich ist und damit ist es mit einem "einfachen Editor" schon mal vorbei ... auch der nach einem solchem Import unumgängliche Neustart der Box führt - gerade dann, wenn man etwas mit VPN-Einstellungen experimentieren muß, bis es klappt - zu einem unnötig großen Aufwand (und Wartezeiten, die man leicht vermeiden kann).
Bei der Alternative, die einzelne VPN-Verbindung aus dem gesamten Export auszuschneiden für den einzelnen Import, sind wir wieder beim Ersetzen der verschlüsselten Daten durch Klartext beim Import (auch die Einstellung "editable = yes;" sollte man dann dringend in "editable = no;" ändern, wenn sie vorhanden ist) und damit letztlich wieder bei meinem ursprünglichen Vorschlag.
Wenn man diesen Aufwand irgendwann ohnehin treiben muß (weil man schon vorher weiß, daß man manuelle Änderungen vornehmen will/muß), dann kann man es auch gleich von Beginn an so machen und erspart sich spätere Kopfstände, um an die zu editierende Vorlage zu gelangen.
Ich bleibe dabei, daß mein Vorschlag - mit "FRITZ!Fernzugang konfigurieren" für Templates, wobei man diese Templates auch von woanders beziehen kann, und manuelle Anpassung der Dateien mit einem passenden Text-Editor - mit jeder (mir bekannten) aktuellen FRITZ!Box funktioniert (Telnet eben nicht) und bei mehr als einer Änderung der Konfiguration am Ende den geringeren Gesamtaufwand erfordert.
Nebenbei ... auch ansonsten verschenkt der "Assistent im GUI" (er ist ja eigentlich keiner, das weiß ich auch - gerade bei so komplizierten Sachen wie VPN und den aus Konfigurationsfehlern resultierenden (Sicherheits-)Problemen sollte er aber einer sein) in meinen Augen viel zuviele Möglichkeiten, die ihn zu einem echten Assistenten machen würden.
So warnt er beispielsweise nicht bei Überlappungen von entfernten Netzen (nicht mal bei Identität) für mehrere Verbindungen und auch die klaglose Akzeptanz der simpelsten PSKs wie "1234" ist bei der Verwendung des "aggressive mode" eine schwere Verfehlung. Ich meine tatsächlich nur "warnen und erklären", nicht Bevormunden des Nutzers. Wenn er darauf aufmerksam gemacht wird, daß 1234 untauglich ist, reicht das vollkommen und wenn er es dann immer noch verwenden will, ist ihn nicht zu helfen ... wobei man da sogar noch rigoroser sagen könnte: "Wenn Du Deine Sicherheit gefährden willst, nimm gefälligst Dateien ..." und sich als "Assistent" vielleicht tatsächlich verweigern sollte.
Apropos Sicherheit: Wenigstens konfiguriert das GUI für Phase2 eine Proposal-Auswahl, die PFS zuläßt ... die Auswahl für Phase1 (all/all/all), wo dann ein Downgrade bis zu DES/MD5 denkbar wäre, ist aber auch eher ein Witz.
Aber zurück zum Thema ...
Dein Workaround mit dem Auslassen von "Verbindung dauerhaft halten" funktioniert eben auch nicht in jeder Situation, das muß man an diesem Vorschlag kritisieren ... selbst wenn die Wahrscheinlichkeit von Kollisionen natürlich geringer ist, sind sie doch nicht ausgeschlossen.
Wenn nämlich irgendein Client auf der Seite von FRITZ!Box A Verbindung mit einem Client hinter FRITZ!Box B (oder der Box selbst) Kontakt aufnehmen will, startet FRITZ!Box A immer noch eine VPN-Verbindung, wenn die zu diesem Zeitpunkt nicht besteht. Das läßt sich - meines Wissens, aber ich lerne auch gerne dazu, wenn Du die richtige Vorgehensweise beschreibst - nur dadurch vermeiden, daß die FRITZ!Box A durch Auslassen von "remotehostname" und "remoteip" keine Möglichkeit hat, ihrerseits Kontakt aufzunehmen, was ja ohnehin nicht funktionieren würde und ein ganz normaler Fall bei der Konfiguration einer VPN-Verbindung mit mindestens einem Teilnehmer mit dynamischer IP-Adresse ist (road warrior configuration).
Die früher beschriebene Kollision läßt sich zumindest mit 50%iger Wahrscheinlichkeit dann auch wieder erzielen, wenn man z.B. von einem Client hinter FRITZ!Box A über die VPN-Verbindung die FRITZ!Box B konfiguriert und dabei ein Neustart der FRITZ!Box B erforderlich wird. Die dann aufgerufene Seite "Box wird neu gestartet, sie werden verbunden, wenn sie wieder bereit ist." (sinngemäß, ich starte jetzt nichts neu, nur um den Wortlaut zu haben) versucht in regelmäßigem Abstand das GUI der FRITZ!Box erneut aufzurufen. Damit würde also FRITZ!Box A - genauso wie vorstehend beschrieben - selbst die, durch den Neustart unterbrochene, VPN-Verbindung versuchen aufzubauen und auch ein erster, zweiter, dritter Fehler (jeweils mit dem Verwerfen des Pakets, das den Verbindungsaufbau ausgelöst hat) würde keine Auswirkungen haben, da diese "Neustart"-Seite im Browser eben immer wieder auf's Neue versucht, die wieder gestartete Box zu finden. Das ist ja sicherlich kein an den Haaren herbeigezogenes Szenario des Einsatzes einer VPN-Verbindung.
"VPN-Verbindung dauerhaft halten" ändert ja offenbar nur "keepalive_ip" und auch da hat der Assistent der FRITZ!Box seine Schwächen bei der Konfiguration, denn die von ihm auserkorene IP-Adresse für dieses Keepalive-Paket ist ganz simpel immer die erste Adresse im entfernten Netz (das geht soweit, daß bei (falscher) Konfiguration von 192.168.10.1/24 tatsächlich 192.168.10.2 ge"ping"t wird) und das funktioniert dann u.U. auch wieder nicht, wenn da andere "accesslist"-Vorgaben vorhanden sind. Eigentlich ist es nur ein "Mißbrauch" einer beliebigen entfernten Adresse für den umgehenden Aufbau der VPN-Verbindung, die tatsächliche Antwort der Gegenseite interessiert überhaupt nicht beim Verbindungsaufbau. Ob das sauber ist und einem nicht irgendwann mal auf die Füße fällt, mag jeder für sich selbst entscheiden. An die dort angegebene Adresse (das keepalive_ip hat nicht das geringste mit "dead peer detection" (DPD) von IPSec zu tun, eher noch mit einem "Offenhalten" von NAT-Verbindungen) wird ganz simpel ein ICMP-Echo-Request mit 25x "PING" als Payload gesendet, die Antwort kann ruhig auch ausbleiben, da der eigentliche Zweck (NAT offenhalten und Verbindung aufbauen) ja erfüllt ist. Wie das ggf. der Admin des entfernten Netzes sieht (das muß ja nicht zwingend auch eine FRITZ!Box sein), wenn da irgendjemand wild in seinem Netzwerk Adressen aufruft, die es u.U. gar nicht gibt, hängt auch von dessen Ansichten ab (ein anschlagendes IDS, das in einem solchen Ping den Versuch einer Kartographie des LAN von einer externen Adresse sieht, ist bestimmt auch nicht so spaßig). Ist sicherlich auch ein Spezialfall ... aber auch ein weiteres Beispiel für nicht immer sinnvolle Standardannahmen/-vorgaben des Assistenten. Da steht eben einfache Konfigurierbarkeit für häufige Szenarien gegen universelle Verwendung auch für etwas kompliziertere Konfigurationen.
und die Konfigurationen einstellbar bleiben - was natürlich auch nachträglich geht per "editable = yes;"
Das Ansinnen verstehe ich nicht ... wenn das heißen soll, daß man die Konfiguration dann einfacher per GUI editieren kann, dann will man das i.d.R. in dem hier vorliegenden Szenario gar nicht, warum habe ich schon geschrieben.
Da der eingebaute Assistent (ich bleibe dabei, um eine Abgrenzung zum Begriff "Editor" zu haben) auch alle Optionen/Einstellungen, die er nicht kennt, konsequent auf seine eigenen Vorstellungen zurücksetzt (von accesslist bis remotehostname), macht das für mich auch nur wenig Sinn.
Da hat ein kluger Programmierer/Designer erkannt, daß der GUI-Editor (vielleicht ist der Begriff besser) bei weitem nicht alle Szenarien abdeckt (das will er ja auch gar nicht) und es wurde Vorsorge getroffen, daß selbst erstellte VPN-Konfigurationen nicht ohne weiteres vom GUI-Editor "zerstört" werden können, indem für "editable" eben "no" als Standard angenommen wird. Wer das absichtlich mit "yes" ersetzt, kann dann auch gleich den GUI-Editor mit den aufgeführten "Unzulänglichkeiten" verwenden.
Auch die Tatsache, daß der GUI-Editor grundsätzlich jede mit ihm bearbeitete Konfiguration auch sofort wieder aktiviert (unabhängig davon, ob die Checkbox vor dem Bearbeiten aktiv war oder nicht), finde ich persönlich extrem unglücklich, denn so kann man eben nicht "mal nebenbei" eine deaktivierte Konfiguration bearbeiten und speichern. Bei dem dann offenbar zwingend erfolgenden "vpnreload" werden leider auch bestehende Verbindungen erst einmal getrennt und dann neu aufgebaut, was einem in einer parallel aufgebauten Verbindung laufenden Datentransfer auch nur in den seltensten Fällen gut tut. Das ist zwar auch beim Import einer VPN-Verbindung so, aber da sehe ich das sogar noch als Notwendigkeit ein ... beim GUI-Editor, der den aktuellen Zustand genau kennt, aber eher nicht. Auch der Abbruch und Neuaufbau der DSL-Verbindung beim Löschen einer VPN-Konfiguration ist sicherlich nur dann wirklich notwendig, wenn tatsächlich der dsld neu initialisiert werden muß, weil sich die Konfiguration z.B. von ipsecbrX-Bridges geändert hat. Das erfolgt aber nach meinem Verständnis/meinen Tests auch "ins Blaue" hinein.
Eine HOSTS-Datei ist da recht hilfreich
Das ist zweifellos auch vollkommen richtig (für Windows-Netzwerk-Clients gibt es dann mit der LMHOSTS-Datei sogar noch weitergehenden Möglichkeiten, die auch SMB-Besonderheiten konfigurierbar machen), allerdings hätte ich den Einwand von frz etwas anders interpretiert (angesichts des angeführten Beispiels Steam-InHome-Streaming). Und für das dort unbedingt erforderliche (und für die Sichtbarkeit im Windows-Netzwerk auch wünschenswerte) Layer2-Forwarding ist das AVM-IPSec-VPN einfach nicht geeignet.
Ich wollte das nur noch einmal festhalten, falls es jemand so verstehen sollte, daß man mit einer hosts-Datei auch die Steam-Problematik lösen könnte ... die besteht nicht darin, ob man IP-Adressen oder Namen verwendet, die hat andere Ursachen. Auch andere link-lokale Protokolle, wie mDNS (Bonjour, avahi) o.ä. zum Auffinden von Diensten im lokalen Netzwerk, funktionieren über eine VPN-Verbindung nicht ohne weitere Hilfsmittel.
Da könnte man ja glatt denken, daß Netbios doch durchgelassen wird.
Das ist auch tatsächlich so, betrifft aber nur die Unicast-Pakete, die direkt an das entsprechende Ziel gesendet werden.
Das wäre auch tatsächlich die notwendige Einstellung, wenn man über die VPN-Verbindung auf SMB-Server/-Clients zugreifen will, das habe ich vorher glatt noch vergessen zu erwähnen. Das war auch garantiert nicht das Problem beim Ping von frz, da das davon nicht beeinflußt wird.
Aber auch "dont_filter_netbios" ändert aber nichts an der Sichtbarkeit von entfernten Windows-Rechnern ... dafür braucht es das Layer2-Forwarding für Broadcasts oder einen WINS-Server.
Zum Glück gibt es euch!
