- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,156
- Punkte für Reaktionen
- 1,706
- Punkte
- 113
Da ich selbst gestern ca. 1 Stunde am Zweifeln ob meiner VPN-Kenntnisse war und es wohl dazu tatsächlich noch keine passenden Infos gibt (zumindest hier im IPPF und auch im gesamten Internet ist es nicht wirklich üppig, wie ich vor dem Schreiben dieses Beitrags festgestellt habe), hier mal eine passende Beispielkonfiguration für den Anwendungsfall aus dem Thread-Titel.
Es gibt zwar mehrere Hilfen, wie man das Ganze mit einer LAN-LAN-Kopplung einrichtet oder wie man eine FRITZ!Box als (Dial-In-)Client mit einem Linux-Server verwendet, aber der Fall, daß das Linux-System als VPN-Client für die Einwahl in einer FRITZ!Box genutzt werden soll, ist bisher wohl nur wenig "besprochen" worden und es hat sich sowohl die AVM-Implementierung der VPN-Funktionen etwas verändert und gleichzeitig muß man inzwischen wohl auch festhalten, daß "strongSwan" (https://www.strongswan.org/ - was ja eine "Multi-Plattform-Solution" ist) in den allermeisten Linux-Distributionen die früheren Projekte "FreeS/WAN", "Openswan" und "Libreswan" und auch das Racoon/KAME-Gespann für den IKE-Daemon ersetzt hat und sich daraus auch (teilweise subtile) Unterschiede zu alten Anleitungen (auch zu einigen im IPPF) ergeben.
Beginnen wir mit den zwei wichtigsten Dateien - wobei ich hier der Einfachheit halber die "alten" Dateien
Zuerst also die
und passend zu dieser braucht es dann noch eine
(in dieser Datei sind die Leerzeichen vor und hinter den Doppelpunkten - außer nach
Kurz zu den zu ersetzenden Werten ... diese sind alle in Rot dargestellt und die spitzen Klammern gehören jeweils zum zu ersetzenden Text. Bei der Benennung habe ich - soweit das vergleichbar war/ist - die Bezeichnungen aus der AVM-Anzeige für die VPN-Einstellungen eines Benutzer-Accounts verwendet ... der einzige Wert, der sich dort nicht finden wird, ist <FRITZ!Box-LAN-Segment>, was durch das im lokalen Netz der FRITZ!Box verwendete IPv4-Segment zu ersetzen ist - bei AVM-Standardeinstellungen (mit DSL-Router) also 192.168.178.0/24 (oder 192.168.188.0/24 bei LAN1-Router). Bei <choose_your_own_connection_name_here> gibt es hoffentlich keine Fragen/Unklarheiten und wer vor dem DynDNS-Namen das Prozentzeichen auslassen will, kann dem Template (oder der Verbindung) stattdessen auch ein
Da alle diese "dial-in connections" mit FRITZ!Boxen als Server ein paar Einstellungen gemeinsam haben, sind diese in der "Schablone" mit dem Namen
Noch ein paar Erläuterungen zu den Werten ... diejenigen, die hier in Wisteria dargestellt werden (ja, so heißt diese Farbe RGB(147, 101, 184)), sind zu den AVM-Einstellungen passende Standardannahmen meinerseits, während die in Denim für die jeweilige Verbindung bzw. die eigenen Anforderungen an Geschwindigkeit und Sicherheit passend gesetzt werden müssen.
Zu den nutzbaren Algorithmen für den Schlüsselaustausch und die Verschlüsselung der ESP-Pakete ... obwohl es in der
, habe ich es einfach nicht gepackt, hier mit irgendeiner anderen DH-Group als
Die acht Stunden, die AVM da für die "lifetime" so eines ausgehandelten Schlüssels vorgeben möchte, sind (meiner Ansicht nach) eher den früheren Schwierigkeiten mit irgendwelchen Smartphones geschuldet und bei ernsthafter VPN-Verwendung auch eher nicht sinnvoll (gilt für IKE und ESP), weil das einem Angreifer schon jede Menge Zeit läßt, den Schlüssel noch innerhalb seiner Gültigkeit zu knacken. Daher habe ich in meinen Vorgaben auch nur eine Stunde vorgesehen - die ansonsten auch noch übliche Beschränkung eines Schlüssels auf ein max. damit zu verarbeitendes Datenvolumen habe ich mir aber auch geklemmt, weil üblicherweise auf diesem Weg jetzt auch nicht diiieee Datenmengen bewegt werden.
In Abhängigkeit davon, wann und wie man so eine VPN-Verbindung starten läßt (komme ich gleich noch zu), kann es sinnvoll sein, diese mittels
Und damit zum ESP-Protokoll (die Zeilen in Denim und das Beispiel für das "Überschreiben" einer Angabe aus dem Template in Fern) - das FRITZ!OS bietet auch in der Auswahl der Algorithmen für die ESP-Verschlüsselung nicht sooo viele Möglichkeiten, denn der entsprechende Abschnitt in der
Der entscheidende Punkt ist hier - neben der, seit 07.2x und der Benutzung der Hardware-Einheiten für die Verschlüsselung, abgeschafften Verwendung (bzw. Auslassung) von
Das ist aber die Stelle, wo ich gestern erst mal wieder eine Weile gebraucht habe ... auch weil ich vergessen hatte, die AVM-Vorgaben in der
Für diese Dial-In-Connections bei einer FRITZ!Box (zumindest für diejenigen, die mit dem automatischen Satz an Vorschlägen konfiguriert sind), MUSS man also für ESP einen Vorschlag machen, der keine Angabe einer DH-Group beinhaltet ... dann klappt's auch mit dem Nachbarn, selbst wenn der eine FRITZ!Box hat (und sich für's Geschirrspülen überhaupt nicht interessiert).
Die Angabe von forceencaps=yes entspricht dem nat-t=force - dann "betrügt" strongSwan beim Hash über die IP-Adressen, mit dem letztlich festgestellt wird/werden soll, ob ein NAT-Router zwischen den Peers sitzt und ob von UDP 500 und ESP auf UDP 4500 für NAT-T umgeschaltet werden soll. Das bringt zwar einen (kleinen) Overhead mit sich (weil die ESP-Pakete jetzt alle noch einmal in eine UDP-Hülle gesteckt werden), aber es kann hilfreich sein, wenn die automatische Detection aus irgendeinem Grunde nicht funktionieren sollte. Man kann es also auch auslassen ... sollte man das für eine Verbindung anders wünschen, als es im Template steht, kann man das bei der Verbindung ja auch wieder "überschreiben".
Bleibt noch der auto-Parameter ... mit dem kann man jetzt festlegen, was mit der VPN-Verbindung beim Start von strongSwan (entweder über
Es gibt zwar mehrere Hilfen, wie man das Ganze mit einer LAN-LAN-Kopplung einrichtet oder wie man eine FRITZ!Box als (Dial-In-)Client mit einem Linux-Server verwendet, aber der Fall, daß das Linux-System als VPN-Client für die Einwahl in einer FRITZ!Box genutzt werden soll, ist bisher wohl nur wenig "besprochen" worden und es hat sich sowohl die AVM-Implementierung der VPN-Funktionen etwas verändert und gleichzeitig muß man inzwischen wohl auch festhalten, daß "strongSwan" (https://www.strongswan.org/ - was ja eine "Multi-Plattform-Solution" ist) in den allermeisten Linux-Distributionen die früheren Projekte "FreeS/WAN", "Openswan" und "Libreswan" und auch das Racoon/KAME-Gespann für den IKE-Daemon ersetzt hat und sich daraus auch (teilweise subtile) Unterschiede zu alten Anleitungen (auch zu einigen im IPPF) ergeben.
Beginnen wir mit den zwei wichtigsten Dateien - wobei ich hier der Einfachheit halber die "alten" Dateien
ipsec.conf und ipsec.secrets verwende, weil die Struktur der neueren Konfigurationsmöglichkeiten (strongswan.conf und swanctl.conf) "formalere Ansprüche" erfüllen muß und da schon die geschweiften Klammern für manchen eine Herausforderung darstellen.Zuerst also die
ipsec.conf:
Rich (BBCode):
# ipsec.conf - strongSwan IPsec configuration file
config setup
uniqueids = yes
conn avm_conntype_user
ikelifetime=60m
keylife=60m
rekeymargin=3m
keyingtries=1
ike=aes256-sha512-modp1024!
esp=aes256-sha512!
keyexchange=ikev1
aggressive=yes
leftauth=psk
leftauth2=xauth
leftsourceip=%config4
dpdtimeout=120s
dpdaction=restart
dpddelay=30s
forceencaps=yes
modeconfig=pull
compress=no
rightauth=psk
xauth=client
conn <choose_your_own_connection_name_here>
also=avm_conntype_user
leftid=keyid:<IPSec-ID / Gruppenname>
right=%<Serveradresse / Server>
rightsubnet=<FRITZ!Box-LAN-Segment>
xauth_identity=<Nutzername / Account >
esp=aes256-sha1!
auto=routeipsec.secrets:
Rich (BBCode):
#
# ipsec.secrets
#
# This file holds the RSA private keys or the PSK preshared secrets for
# the IKE/IPsec authentication. See the ipsec.secrets(5) manual page.
#
keyid:<IPSec-ID / Gruppenname> : PSK "<IPSec-Schlüssel / Shared Secret>"
<Nutzername / Account > : XAUTH "<Kennwort des FRITZ!Box-Benutzers>"keyid, wo keines stehen darf - wichtig!)Kurz zu den zu ersetzenden Werten ... diese sind alle in Rot dargestellt und die spitzen Klammern gehören jeweils zum zu ersetzenden Text. Bei der Benennung habe ich - soweit das vergleichbar war/ist - die Bezeichnungen aus der AVM-Anzeige für die VPN-Einstellungen eines Benutzer-Accounts verwendet ... der einzige Wert, der sich dort nicht finden wird, ist <FRITZ!Box-LAN-Segment>, was durch das im lokalen Netz der FRITZ!Box verwendete IPv4-Segment zu ersetzen ist - bei AVM-Standardeinstellungen (mit DSL-Router) also 192.168.178.0/24 (oder 192.168.188.0/24 bei LAN1-Router). Bei <choose_your_own_connection_name_here> gibt es hoffentlich keine Fragen/Unklarheiten und wer vor dem DynDNS-Namen das Prozentzeichen auslassen will, kann dem Template (oder der Verbindung) stattdessen auch ein
rightid=%any hinzufügen - aber eine der beiden Möglichkeiten sollte genutzt werden, weil man nie genau weiß, wie die FRITZ!Box die eigene localid in P1 wählt, wenn mehrere DynDNS-Konten (inkl. MyFRITZ!) aktiviert sind und strongSwan dann gerne mal mit dieser ID nichts anfangen kann.Da alle diese "dial-in connections" mit FRITZ!Boxen als Server ein paar Einstellungen gemeinsam haben, sind diese in der "Schablone" mit dem Namen
avm_conntype_user in der ipsec.conf enthalten - dieses Template kann dann mit einem also=avm_conntype_user für eine "echte" Definition einer Verbindung übernommen werden und dort definierte Werte können durch eine "konkrete" Verbindung auch wieder überschrieben werden (seit strongSwan 5.2.0 und eine noch ältere hält hoffentlich keine aktuelle Linux-Distribution bereit - die aktuelle Release-Version von strongSwan wäre 5.9.1). Da zusätzlich auch noch einige Werte durch eine %default-Verbindung "vordefiniert" sein könnten (wenn man das auf einem nicht jungfräulichen System macht, was schon ein paar andere IPSec-Verbindungen nutzt), gibt es in meinem Template auch ein paar Einstellungen, die eigentlich nicht angegeben werden müßten, weil sie ohnehin Standard sind - aber sicher ist sicher und so werden sie (u.a. compress=no oder auch xauth=client) noch einmal explizit gesetzt.Noch ein paar Erläuterungen zu den Werten ... diejenigen, die hier in Wisteria dargestellt werden (ja, so heißt diese Farbe RGB(147, 101, 184)), sind zu den AVM-Einstellungen passende Standardannahmen meinerseits, während die in Denim für die jeweilige Verbindung bzw. die eigenen Anforderungen an Geschwindigkeit und Sicherheit passend gesetzt werden müssen.
Zu den nutzbaren Algorithmen für den Schlüsselaustausch und die Verschlüsselung der ESP-Pakete ... obwohl es in der
ipsec.cfg bei AVM anders steht (hier aus der 154.07.24-84707 - das ist die IKE-Strategie, die bei conntype_user-Verbindungen in der vpn.cfg automatisch gesetzt ist):
Rich (BBCode):
name = "LT8h/all/all/all";
comment = "Alle Algorithmen, DH-Gruppe alternate (ausgehend) Lifetime 8h";
dhgroup = alt;
life_dur_sec = 8h;
life_dur_kb = 0;
accept_all_dh_groups = yes;
proposals {
hash = ike_sha2_512;
enc {
type = ike_aes;
keylength = 256;
}
}{2 (https://wiki.strongswan.org/projects/strongswan/wiki/IKEv1CipherSuites) eine Verbindung aufzubauen - die Antwort war schlicht immer "no proposal choosen". Damit kann man zwar mit dem Verschlüsselungsalgorithmus und dem HMAC-Verfahren beim IKE variieren, aber das modp1024 sollte "gesetzt" sein (nach meinen gestrigen Versuchen). Für Verschlüsselung kann man guten Gewissens eigentlich nur AES empfehlen, wobei AVM wohl die Schlüssellängen 128, 192 und 256 Bit versteht - beim HMAC-Verfahren sollte man (für den Schlüsselaustausch, also beim ike=...) aber schon auf etwas besseres als SHA1 gehen und dann läßt einem AVM mit den Vorgaben in der ipsec.cfg auch nicht mehr sooo viel Auswahl. Denn neben MD5 und SHA1 ist da für IKE nur noch ein einziges Proposal für AES256 mit SHA512 enthalten ... das sollte man dann auch verwenden. Der Datenverkehr beim IKE ist jetzt nicht so heftig (nicht mit dem über ESP zu verwechseln, wo dann die "echten Daten" übertragen werden), daß das einen spürbaren Nachteil in der Geschwindigkeit der Datenübertragung zur Folge hätte.Die acht Stunden, die AVM da für die "lifetime" so eines ausgehandelten Schlüssels vorgeben möchte, sind (meiner Ansicht nach) eher den früheren Schwierigkeiten mit irgendwelchen Smartphones geschuldet und bei ernsthafter VPN-Verwendung auch eher nicht sinnvoll (gilt für IKE und ESP), weil das einem Angreifer schon jede Menge Zeit läßt, den Schlüssel noch innerhalb seiner Gültigkeit zu knacken. Daher habe ich in meinen Vorgaben auch nur eine Stunde vorgesehen - die ansonsten auch noch übliche Beschränkung eines Schlüssels auf ein max. damit zu verarbeitendes Datenvolumen habe ich mir aber auch geklemmt, weil üblicherweise auf diesem Weg jetzt auch nicht diiieee Datenmengen bewegt werden.
In Abhängigkeit davon, wann und wie man so eine VPN-Verbindung starten läßt (komme ich gleich noch zu), kann es sinnvoll sein, diese mittels
DPD (Dead Peer Detection) zu überwachen und dann, wenn sie aus irgendeinem Grund nicht mehr funktioniert, neu aufzubauen. Die möglichen Aktionen und die Bedeutung der Zeitvorgaben findet man dann wieder im strongSwan-Wiki.Und damit zum ESP-Protokoll (die Zeilen in Denim und das Beispiel für das "Überschreiben" einer Angabe aus dem Template in Fern) - das FRITZ!OS bietet auch in der Auswahl der Algorithmen für die ESP-Verschlüsselung nicht sooo viele Möglichkeiten, denn der entsprechende Abschnitt in der
ipsec.cfg von AVM sieht so aus:
Code:
name = "LT8h/esp-all-all/ah-none/comp-all/no-pfs";
comment = "Alle Algorithmen, ohne AH, ohne PFS";
pfs = no;
life_dur_sec = 8h;
life_dur_kb = 0;
proposals {
comp = comp_none;
ah = ah_none;
esp {
typ = esp_aes;
enc_key_length = 256;
hash = hmac_sha2_512;
}
}{
comp = comp_none;
ah = ah_none;
esp {
typ = esp_aes;
enc_key_length = 256;
hash = sha;
}
}{
comp = comp_none;
ah = ah_none;
esp {
typ = esp_aes;
enc_key_length = 192;
hash = sha;
}
}{
comp = comp_none;
ah = ah_none;
esp {
typ = esp_aes;
enc_key_length = 0;
hash = sha;
}
}{
comp = comp_none;
ah = ah_none;
esp {
typ = esp_3des;
enc_key_length = 0;
hash = sha;
}
}{
comp = comp_none;
ah = ah_none;
esp {
typ = esp_des;
enc_key_length = 0;
hash = sha;
}
}{
comp = comp_none;
ah = ah_none;
esp {
typ = esp_aes;
enc_key_length = 256;
hash = md5;
}
}{
comp = comp_none;
ah = ah_none;
esp {
typ = esp_aes;
enc_key_length = 192;
hash = md5;
}
}{
comp = comp_none;
ah = ah_none;
esp {
typ = esp_aes;
enc_key_length = 0;
hash = md5;
}
}{
comp = comp_none;
ah = ah_none;
esp {
typ = esp_3des;
enc_key_length = 0;
hash = md5;
}
}{
comp = comp_none;
ah = ah_none;
esp {
typ = esp_des;
enc_key_length = 0;
hash = md5;
}
}compress - das Fehlen von Proposals MIT PFS. In strongSwan gibt es aber mittlerweile die Option pfs=yes gar nicht mehr - das wird jetzt implizit durch die Angabe des Algorithmus für ESP vorgegeben. Wenn dieser eine Angabe für eine DH-Gruppe enthält (also der modp1024-Teil enthalten ist), wird natürlich auch automatisch PFS gesetzt - sonst macht dabei die Angabe der DH-Group ja auch keinen Sinn.Das ist aber die Stelle, wo ich gestern erst mal wieder eine Weile gebraucht habe ... auch weil ich vergessen hatte, die AVM-Vorgaben in der
ipsec.cfg tatsächlich im Detail zu prüfen und einfach davon ausging, daß AVM PFS schon erlauben würde. Erst nach gründlicherer Überlegung und Analyse der Debug-Logs habe ich dann den Fehler gefunden ... AVM sagt da nämlich auch in der aktuellen VPN-Implementierung schlicht "Fehler 0x2026" in der eigenen Log-Datei und gut ist's - eine Anzeige, was angeboten wurde und was erlaubt wäre, fehlt in der ike.log immer noch (auch wenn's die jetzt wenigstens für den letztlich ausgewählten Vorschlag gibt).Für diese Dial-In-Connections bei einer FRITZ!Box (zumindest für diejenigen, die mit dem automatischen Satz an Vorschlägen konfiguriert sind), MUSS man also für ESP einen Vorschlag machen, der keine Angabe einer DH-Group beinhaltet ... dann klappt's auch mit dem Nachbarn, selbst wenn der eine FRITZ!Box hat (und sich für's Geschirrspülen überhaupt nicht interessiert).
Die Angabe von forceencaps=yes entspricht dem nat-t=force - dann "betrügt" strongSwan beim Hash über die IP-Adressen, mit dem letztlich festgestellt wird/werden soll, ob ein NAT-Router zwischen den Peers sitzt und ob von UDP 500 und ESP auf UDP 4500 für NAT-T umgeschaltet werden soll. Das bringt zwar einen (kleinen) Overhead mit sich (weil die ESP-Pakete jetzt alle noch einmal in eine UDP-Hülle gesteckt werden), aber es kann hilfreich sein, wenn die automatische Detection aus irgendeinem Grunde nicht funktionieren sollte. Man kann es also auch auslassen ... sollte man das für eine Verbindung anders wünschen, als es im Template steht, kann man das bei der Verbindung ja auch wieder "überschreiben".
Bleibt noch der auto-Parameter ... mit dem kann man jetzt festlegen, was mit der VPN-Verbindung beim Start von strongSwan (entweder über
ipsec start oder über irgendwelche Distro-Mechanismen zum Start aller Services) geschehen soll. Bei Angabe von route (wie in meinem Beispiel) werden nur die Vorkehrungen getroffen, daß beim ersten Versuch, ein Paket an eine Adresse aus rightsubnet zu senden, die VPN-Verbindung automatisch (on demand) aufgebaut wird. Bei auto=start wird die Verbindung gleich beim Start von strongSwan mit aufgebaut und bei auto=add wird ihre Definition zwar den verfügbaren Verbindungen hinzugefügt, aber sie wird weder automatisch, noch "on demand" aufgebaut. Dazu braucht es dann erst noch ein ipsec up <choose_your_own_connection_name_here> (was üblicherweise Superuser-Rechte benötigt) und erst dann kann die VPN-Verbindung genutzt werden. Der eigene Client kriegt dabei von der FRITZ!Box die IP-Adresse vorgegeben, die dem Benutzer im FRITZ!OS zugewiesen wurde (die wird mittlerweile im FRITZ!OS ja auch unter Netzwerkverbindungen angezeigt).
Zuletzt bearbeitet:
