Als Ergänzung zu dem von Telefonmännchen geschriebenen:
Eine konkrete VPN-Konfigurationsdatei kann man sich am einfachsten aus der Export-Datei mit den Einstellungen der Box "herausklauben", es ist die Datei vpn.cfg in diesem File.
Screenshots machen auch nur Sinn, wenn man eine Anzeige/Einstellung im GUI der Box illustrieren will und es sonst nicht anders geht. An anderen Stellen stiften sie - zumindest bei mir - nur Verwirrung. Ich lege lieber nicht offen, wie oft ich schon in einem Screenshot auf die Scrollbar geklickt habe, um da weiter runter zu kommen in dem angezeigten Inhalt. Da ist ein Textauszug einfacher zu lesen und auch einfacher zu zitieren in einer Antwort. (Subjektiv und auf die Spitze getrieben: Irgendwelche Einstellungen, die auch in Textform zu erlangen sind, schaue ich mir persönlich als Screenshot gar nicht erst an.)
AVM-1st-Level (OT):
Dem AVM-First-Level-Support sollte man - ich muß es leider so sagen, es geht nicht gegen einzelne Mitarbeiter, nur gegen die anzunehmende "Schnellbesohlung" für die Arbeit im Support - nicht unbedingt alles vorbehaltlos glauben. Schon die von HilliBilli68 zitierten Aussagen zur "FRITZ!Fernzugang einrichten"-Software und zum "Verbot", die 192.168.178.1 (oder auch das 24er-Subnet) auf auch nur einer Seite der Verbindung zu benutzen, sind ja ersichtlich blühender Unsinn. Was interessiert es, ob eine Software auf einem PC installiert ist oder nicht, solange man sie nicht benutzt (was imho ein Fehler ist). Manchmal kann man gar nicht so viel mit dem Kopf schütteln wie man möchte, da die Kopfschmerzen dann unvermeidlich wären.
Zurück zum VPN:
Das Einrichten in einem Szenario mit mehr als einer Gegenstelle würde ich persönlich immer mit einem passenden Template für eine solche Verbindung machen, der einfachste Weg zu diesem Template führt nach wie vor über die Verwendung der "FRITZ!Fernzugang einrichten"-Software als Einstieg.
Eine mit der Box selbst erstellte Verbindung kann man zwar auch (über den Umweg der Export-Datei) nachträglich editieren, aber die (bisher) im GUI angebotenen Einstellungsmöglichkeiten decken nur den Standardfall ab und nichts weiter. Wenn man wirklich einige "unübliche" Einstellungen braucht, kommt man um das manuelle Editieren nicht herum und dann sollte man besser - wenigstens in etwa - wissen, wofür da welche Einstellung gut ist.
Wenn man hier eigene Konfigurationen veröffentlicht, muß man sich um die Daten mit den Dollarzeichen nicht weiter kümmern, die sind schon verschlüsselt und ohne weitere Angaben zur betreffenden Box kann die selbst AVM nicht entschlüsseln.
Ein Konfigurationsabschnitt für eine Verbindung sähe also so aus:
Code:
vpncfg {
connections {
enabled = no;
editable = no;
conn_type = conntype_lan;
name = "Bob";
boxuser_id = 0;
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = no;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = 0.0.0.0;
remote_virtualip = 0.0.0.0;
keepalive_ip = 0.0.0.0;
localid {
fqdn = "$$$$6RVVVRKTQB5CYMHCEZYWRXXMWUWGX2EIP3LTQB44VBL4XMR51BA4TKJWBTRO6SGQKIWBYTG5F4WR6CCQEYSNF1WCWFTPEZUVSITYRMIA";
}
remoteid {
fqdn = "$$$$DTADUIYDL56K13ADPT6JTWKEFA2W26PCVPNE4JJB3XUKHTQCUWO25MP3BTFC3OUI4PC3VVEIAMWR3IGWXRDAXUZH4FV11NRRGSS2CYYA";
}
mode = phase1_mode_aggressive;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "$$$$WBCOUW1SXWA1IQVJ2Y14I3QQTPKTAOXQAS33YAIP2LZ46DLSAFVLLBRVSLGL2MVB26ZPEHKYZAXSIBOVYF14P5LMRKY6GEBLO6ANJPQA";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.1.0;
mask = 255.255.255.240;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.2.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.2.0 255.255.255.0";
}
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
"udp 0.0.0.0:4500 0.0.0.0:4500";
}
Weil ich es immer wieder (falsch) sehe, ein paar Bemerkungen, wie man diese Datei vor dem Posten verändern sollte, damit es am Ende auch Sinn macht. Das Problem bei der Sache ist hier, daß es eigentlich immer zwei Dateien (für jede VPN-Seite eine) gibt, die auch zusammenpassen müssen.
Der Eintrag im Feld "name" kann ja auch eine schützenswerte Information sein, wenn er nicht nur FB1 oder FB2 ist. Da hat sich - wie bei vielen Szenarien mit Kryptographie - die Bezeichnung "Alice" für die eine Seite und der Name "Bob" für das Gegenüber eingebürgert. Daß es wenig hilfreich ist, den Namen in beiden Dateien einfach nur mit "****" zu ersetzen, leuchtet hoffentlich ein ... das gilt für alle anderen Einstellungen genauso. Wenn man die eigenen Einstellungen verschleichern will, nimmt man andere Adressen/Namen/was auch immer, das aber immer konsequent und konsistent für
jedes Vorkommen einer solchen Einstellung in der Datei. Wenn die Firewall-Regel am Ende so aussieht: "permit ip 192.168.***.*** 255.255.***.*** 192.168.***.*** 255.255.***.***", dann kann damit niemand etwas anfangen. Gleiches gilt für DynDNS-Namen als remotehostname, für keepalive-IPs, etc. pp. - wenn verschleiern, dann bitte so, daß man den Unterschied zwischen den verschleierten Einstellungen noch klar nachvollziehen kann (und die Ansage, daß es verschleiert ist, erleichtert auch dem Leser die Kontrolle von Einstellungen, wenn er nicht sofort bei der kleinsten Abweichung durch das "Editieren" der Datei laut "Heureka" rufen will).
Ein weiterer hilfreicher Ansatz bei Problemen mit VPN-Verbindungen ist die Datei /var/tmp/ike.log (ältere Protokolle finden sich nach einiger Zeit in der ike.old im gleichen Verzeichnis). Dort protokolliert der AVM-IKE-Daemon ein paar Sachen, die bei der Fehlersuche nützlich sein können. Selbstverständlich stehen da auch wieder "geheime" Daten drin, die man dann besser vorher ersetzt. Dabei gilt das oben Geschriebene wieder analog. Es muß auch nicht immer die komplette Protokolldatei dabei sein, aber etwas Kontext sollte ein Ausschnitt aus diesem Log auch haben. Eine Zeile wie
Code:
fehlerhafte Paketlaenge: Hdr-length > read-Data
ist zwar ein Hinweis darauf, daß da ein Paket nicht "verstanden" wurde, aber ohne entsprechende Informationen zur "Umgebung" ist das witzlos.
Code:
2014-11-17 14:19:31 avmike:FreeIPsecSA: spi=3ddd protocol=4 iotype=2
2014-11-17 14:19:31 avmike:< cb_sa_deleted(name=Bob,id=16,what=2)
2014-11-17 14:19:31 avmike:FreeIPsecSA: spi=8037b7f0 protocol=3 iotype=1
2014-11-17 14:19:31 avmike:FreeIPsecSA: spi=1881 protocol=4 iotype=1
2014-11-17 14:19:31 avmike:Bob
fehlerhafte Paketlaenge: Hdr-length > read-Data
2014-11-17 14:19:31 avmike:Bob
fehlerhafte Paketlaenge: Hdr-length > read-Data
2014-11-17 14:20:44 avmike:mainmode Bob: del SA 14
2014-11-17 14:20:45 avmike:mainmode Bob: del SA 13
Hier "sieht" man dagegen, daß vor den Fehlermeldungen auf der einen Seite die "security association" (SA) gelöscht würde (das ist - platt gesagt - der Schlüssel für dieses Schließfach) und da ist es nicht weiter verwunderlich, wenn weitere eintreffende Pakete, die mit dieser SA verknüpft sind, nicht mehr entschlüsselt werden können. Wie gesagt, nur als Beispiel für "Kontext", das kann sich noch viel weiter verteilen im Protokoll ... so unmittelbar hintereinander steht es nur selten.
Noch ein - nicht ganz ernst gemeinter - Hinweis zu den vielen Zahlen am Beginn jeder Zeile -> das ist nur das Datum und die Uhrzeit, die muß man nicht unbedingt auch noch maskieren (alles schon dagewesen).
Eine Antwort um 3:00 Uhr, Hut ab.
