5
Empfehlungen für einen stabilen und leistungsfähigen VPN-Tunnel
Zahlreiche Beiträge beschäftigen sich mit dem Aufbau und der Fehlerbehebung von VPN-Tunneln. Doch auch wenn der VPN-Tunnel steht, beeinflussen zahlreiche Parameter die Stabilität und Leistung der Verbindung. Welche Empfehlungen und Erfahrungswerte gibt es für eine "guten" Tunnel?
Wir verbinden über VPN-Tunnel (IPSec Router to Router) mehrere Standorte mit unserer Zentrale. Der Aufbau der Tunnel klappt und die Verbindung ist einwandfrei. Genutzt werden Dateifreigaben auf den zentralen Server und vor allem VoIP über die Tunnel. Mit Blick auf maximale Stabilität und Leistung möchte ich die Tunnel nun optimal einstellen.
Unsere Router lassen die Konfiguration von zahlreichen VPN-Parametern zu. Gibt es Empfehlungen und Erfahrungswerte zu folgenden Parametern:
- IKE und IP-Sec Llifetime (Wie lang/kurz sollten diese sein mit Blick auf einen möglichst stabilen Tunnel, schnellen Wiederaufbau nach Trennung)
- MTU-Werte (mit Blick auf Leistung/Fragmentierung)
- Dead Peer Detection (Lifetime, Action, usw.)
- Keep Alive
- Max IPsec ESP Length
- usw.
Folgende Infrastruktur:
- Zentrale / T-DSL 16000 / feste IP / D-Link DFL-800
- Remote-Standorte / T-DSL 16000 bzw. DSL3000 (Ausland) / dynamische IP / D-Link DFL-800
Wir verbinden über VPN-Tunnel (IPSec Router to Router) mehrere Standorte mit unserer Zentrale. Der Aufbau der Tunnel klappt und die Verbindung ist einwandfrei. Genutzt werden Dateifreigaben auf den zentralen Server und vor allem VoIP über die Tunnel. Mit Blick auf maximale Stabilität und Leistung möchte ich die Tunnel nun optimal einstellen.
Unsere Router lassen die Konfiguration von zahlreichen VPN-Parametern zu. Gibt es Empfehlungen und Erfahrungswerte zu folgenden Parametern:
- IKE und IP-Sec Llifetime (Wie lang/kurz sollten diese sein mit Blick auf einen möglichst stabilen Tunnel, schnellen Wiederaufbau nach Trennung)
- MTU-Werte (mit Blick auf Leistung/Fragmentierung)
- Dead Peer Detection (Lifetime, Action, usw.)
- Keep Alive
- Max IPsec ESP Length
- usw.
Folgende Infrastruktur:
- Zentrale / T-DSL 16000 / feste IP / D-Link DFL-800
- Remote-Standorte / T-DSL 16000 bzw. DSL3000 (Ausland) / dynamische IP / D-Link DFL-800
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 96877
Url: https://administrator.de/contentid/96877
Ausgedruckt am: 22.11.2024 um 10:11 Uhr
5 Kommentare
Neuester Kommentar
Wir haben hunderte von Site-to-Site Verbindungen. Da die Peers oft ganz andere VPN Gateways benutzen sind auch die Parameter fast jedesmal etwas anders. Unterschied in Stabilität konnte ich keine feststellen.
Prinzipiell wirkt sich der Einsatz von MD5 statt SHA als Hash performanter aus, wird jedoch unter akademischer Sichtweise als weniger sicher eingestuft.
Die Kombination einer starken Verschlüsselung (AES256) mit MD5 als hash wäre ein gangbarer Weg um die Performance zu erhöhen (Datendurchsatz).
Die Lifetimes der SAs sind auch egal - hauptsache auf beiden Peers sind sie gleich eingestellt. Je länger, desto performanter, doch je kürzer, desto "sicherer".
Prinzipiell ist vor allem wichtig, dass die WAN Anbindung stabil und performant ist.
Ansonsten könnte man QoS einführen, um z. B. VoIP zu priorisieren, falls das probleme macht.
Prinzipiell wirkt sich der Einsatz von MD5 statt SHA als Hash performanter aus, wird jedoch unter akademischer Sichtweise als weniger sicher eingestuft.
Die Kombination einer starken Verschlüsselung (AES256) mit MD5 als hash wäre ein gangbarer Weg um die Performance zu erhöhen (Datendurchsatz).
Die Lifetimes der SAs sind auch egal - hauptsache auf beiden Peers sind sie gleich eingestellt. Je länger, desto performanter, doch je kürzer, desto "sicherer".
Prinzipiell ist vor allem wichtig, dass die WAN Anbindung stabil und performant ist.
Ansonsten könnte man QoS einführen, um z. B. VoIP zu priorisieren, falls das probleme macht.
Hallo SpacyFreak,
danke für Deine schnelle Reaktion und Deine Empfehlungen.
Die Diskussion um MD5 und SHA habe ich auch schon in Foren verfolgt. Ich denke auch, Dein Weg (AES256 / MD5) ist pragmatisch und gut.
Bei den Lifetimes ist klar, je kürzer -> umso weniger Overhead -> höhere Leistung. Spricht darüber hinaus etwas für eine kürzere Lifetimes? zum Beispiel schnellerer Aufbau nach einem Abbruch o. ä. Hast Du auch den IKE-Lifetime etwas länger als den IPSec-Lifetime?
QoS haben wir auf allen Sites implementiert. Welche MTU hast Du für die Tunnel?
danke für Deine schnelle Reaktion und Deine Empfehlungen.
Die Diskussion um MD5 und SHA habe ich auch schon in Foren verfolgt. Ich denke auch, Dein Weg (AES256 / MD5) ist pragmatisch und gut.
Bei den Lifetimes ist klar, je kürzer -> umso weniger Overhead -> höhere Leistung. Spricht darüber hinaus etwas für eine kürzere Lifetimes? zum Beispiel schnellerer Aufbau nach einem Abbruch o. ä. Hast Du auch den IKE-Lifetime etwas länger als den IPSec-Lifetime?
QoS haben wir auf allen Sites implementiert. Welche MTU hast Du für die Tunnel?
Hallo,
die Schlüssellänge erhöhen und gleichzeitig einen unsichern Hash zu verwenden, erscheint mir nicht sinnvoll. Die Theorie wurde ja bereits angesprochen, also sollte auch klar sein, daß AES128 als Algorithmus (mit herkömmlichen Mitteln) kaum zu brechen ist, MD5 schon. Im Zuge der Verfügbarkeit sind DPD und Hartbeats sinnvoll, die Lifetimes eher nebensächlich. Die MTU sollte der Router selbst setzen können.
Insgesamt ist die Prozessorleistung des Routers (bzw. des VPN Gateways) der limitierende Faktor.
Grüße, Steffen
die Schlüssellänge erhöhen und gleichzeitig einen unsichern Hash zu verwenden, erscheint mir nicht sinnvoll. Die Theorie wurde ja bereits angesprochen, also sollte auch klar sein, daß AES128 als Algorithmus (mit herkömmlichen Mitteln) kaum zu brechen ist, MD5 schon. Im Zuge der Verfügbarkeit sind DPD und Hartbeats sinnvoll, die Lifetimes eher nebensächlich. Die MTU sollte der Router selbst setzen können.
Insgesamt ist die Prozessorleistung des Routers (bzw. des VPN Gateways) der limitierende Faktor.
Grüße, Steffen
Nun ja - der Hashalgorithmus in der IPSEC Suite dient ja "nur" dazu, die Datenintegrität zu gewährleisten - sprich zu verifizieren, dass das in IP eingekapselte und stark verschlüsselte IP-Paket sowie die Daten die es trägt nicht manipuliert wurde.
Wie man jedoch ein mit AES256 verschlüsseltes IP-Paket entschlüsseln geschweigedenn manipulieren können soll ist mir ehrlichgesagt schleierhaft. In Anbetracht dass sich die Schlüssel dynamisch abhängig von der Lifetime ändern ist das Brechen des Keys ein Unterfangen das wohl keinem in diesem Teil der Galaxis (ausser vielleicht NSA) gelingen würde.
Ein Angreifer wird letztendlich - wenn er es wirklich drauf anlegt an Daten zu kommen - das SCHWÄCHSTE Einfallstor suchen, und nicht seine kostbare Zeit mti dem knacken eines IPSEC Tunnels verschwenden.
Er wird die Firma mit mails "besuchen" mit verlockenden Anhängen, bei tausenden von Mitarbeitern findet sich bestimmt der eine oder andere der neugierig und doof genug ist draufzuklicken - und schon hat der Angreifer eine Anwendung im Netz, die die Tür "von innen" öffnet, was das Knacken eines Tunnels überflüssig macht.
Oder er schleust einen "Praktikanten" in die Firma, der das Opfer von innen aushöhlt.
Wie man jedoch ein mit AES256 verschlüsseltes IP-Paket entschlüsseln geschweigedenn manipulieren können soll ist mir ehrlichgesagt schleierhaft. In Anbetracht dass sich die Schlüssel dynamisch abhängig von der Lifetime ändern ist das Brechen des Keys ein Unterfangen das wohl keinem in diesem Teil der Galaxis (ausser vielleicht NSA) gelingen würde.
Ein Angreifer wird letztendlich - wenn er es wirklich drauf anlegt an Daten zu kommen - das SCHWÄCHSTE Einfallstor suchen, und nicht seine kostbare Zeit mti dem knacken eines IPSEC Tunnels verschwenden.
Er wird die Firma mit mails "besuchen" mit verlockenden Anhängen, bei tausenden von Mitarbeitern findet sich bestimmt der eine oder andere der neugierig und doof genug ist draufzuklicken - und schon hat der Angreifer eine Anwendung im Netz, die die Tür "von innen" öffnet, was das Knacken eines Tunnels überflüssig macht.
Oder er schleust einen "Praktikanten" in die Firma, der das Opfer von innen aushöhlt.
Zitat von @spacyfreak:
Nun ja - der Hashalgorithmus in der IPSEC Suite dient ja
"nur" dazu, die Datenintegrität zu gewährleisten -
sprich zu verifizieren, dass das in IP eingekapselte und stark
verschlüsselte IP-Paket sowie die Daten die es trägt nicht
manipuliert wurde.
Nun ja - der Hashalgorithmus in der IPSEC Suite dient ja
"nur" dazu, die Datenintegrität zu gewährleisten -
sprich zu verifizieren, dass das in IP eingekapselte und stark
verschlüsselte IP-Paket sowie die Daten die es trägt nicht
manipuliert wurde.
Der Hash stellt auch sicher, daß der Session-Key nicht kompromittiert ist (auch wenn dieser noch so lang ist).
Grüße, Steffen
