Half-managed IPsec-VPN ist wie ...
... ein Ochsenkarren mit Tieren aus verschiedenen Ställen mit zwei Treibern, die sich vorher nicht kannten und oft verschiedene Sprachen sprechen.
Natürlich kann die Reise gut gehen, aber oft dauert es länger als gedacht bis alles ineinander greift und zueinander passt. Dann ist es von Vorteil, zu wissen, an welchen Stellen ich nachschauen kann und wie ich das Gesehene interpretiere.
Worum geht es?
Neben der verwendeten Technologie unterscheidet man VPN auch danach, ob verschiedene Netze miteinander verbunden werden (L2L), ein Host mit einem Netz (L2H) oder zwei Hosts (H2H). Für die folgenden Ausführungen konzentriere ich mich auf L2L-VPN und betrachte die anderen beiden Varianten als Spezialfälle, bei denen einige Probleme nicht vorhanden oder irrelevant sind.
Schaue ich auf das Diagramm, erkenne ich folgende Problemfelder:
An zentraler Stelle ist IPsec als Protokoll selbst. Im Gegensatz zu OpenVPN, bei dem beide Seiten Software aus der gleichen Quelle verwenden, was Interoperabilitätsprobleme sehr stark reduziert, handelt es sich bei IPsec um ein durch RFCs definiertes und standardisiertes Protokoll, das von verschiedenen Herstellern auf je eigene Weise interpretiert wird.
Die verschiedenen Hersteller implementieren verschiedene Features des Protokolls, über die ich eine Schnittmenge bilden muss, zwischen den Fähigkeiten der beteiligten Geräte und den Anforderungen an die Verbindung.
Manchmal verwenden die Hersteller gleiche Begriffe für unterschiedliche Dinge und unterschiedliche Begriffe für die gleichen Dinge. Beides trägt keineswegs dazu bei, die Verständigung zwischen den Administratoren der beiden Seiten zu erleichtern. Dabei ist gerade eine gute Kommunikation notwendig, denn im schlimmsten Fall sieht jeder Administrator nur sein VPN-Gateway, was im Diagramm durch die Strichlinien angedeutet ist.
Das nächste Problem ist NAT, die Manipulation von IP-Adressen. NAT führt dazu, dass sich die Adressen ein und desselben Datagrams im Netz A von den im Tunnel verwendeten und diese von den im Netz B unterscheiden können. Solange alles funktioniert, mag das angehen, im Fehlerfall kann es die Verwirrung vergrößern.
Gerade bei L2L-VPN kommen im Fehlerfall Koordinationsprobleme hinzu. Während es bei den meisten VPN-Gateways eine Möglichkeit gibt, Traffic nachzuweisen und zu dokumentieren, muss ich für vollständige Tests geeigneten Traffic erzeugen, wofür ich auf die Mitarbeit der Nutzer des VPN angewiesen bin. Dazu muss ich mich mit allen Beteiligten absprechen, was das Finden eines passenden Termins erschweren kann.
Das Protokoll IPsec
Das Protokoll IPsec ist der Dreh- und Angelpunkt dieser Art von VPN. In guter Internet-Tradition ist es in RFC beschrieben und von verschiedenen unabhängigen Stellen implementiert.
IPsec nutzt seinerseits selbst verschiedene Protokolle für die einzelnen Bestandteile. Allein die Wikipedia-Seite, die als guter Einstieg in das Thema dienen kann listet weit mehr als 30 RFCs, die sich mit unterschiedlichen Aspekten von IPsec beschäftigen.
Betrachten wir IPsec nur oberflächlich, um einen Überblick zu erhalten, so finden wir
ISAKMP (Internet Security Association Key Management Protocol), das wiederum für den Schlüsselaustausch zwischen den Partnern auf IKE (Internet Key Exchange) in Version 1 oder 2 setzt.
ESP (Encapsulating Security Payload) für die verschlüsselte Übertragung der Nutzerdaten, und
AH (Authentication Header) für die Sicherung der Integrität der übertragenen Daten.
ISAKMP wird immer verwendet, weil damit die Schlüssel ausgetauscht werden. Bei neuen VPN würde ich immer auf IKEv2 setzen, weil hier der Schlüsselaustausch schneller vonstatten geht und im besten Fall ein VPN-Tunnel nach dem Austausch von vier Datagrammen steht. Auch ist das Erkennen und Behandeln von NAT zwischen den VPN-Gateways in IKEv2 von vornherein berücksichtigt.
ESP ist zwar nicht unbedingt erforderlich, sichert aber das 'P' für Privacy in VPN und wird darum in allen mir bekannten IPsec-VPN verwendet.
AH allein könnte die Integrität der übertragenen Daten sichern. In der Praxis ist es mir jedoch bisher noch nicht untergekommen, dass jemand auf die Verschlüsselung und ESP verzichtet hätte.
Außerdem finden wir bei IPsec zwei Betriebsarten, und zwar
Transport Mode, bei dem lediglich ein IPsec-Header zwischen den IP-Header und die nachfolgenden Daten geschoben wird, und
Tunnel Mode, bei dem vor das komplette Datagramm mit Nutzdaten ein zusätzlicher IP- und ein IPsec-Header eingefügt wird.
Für die Verbindung zweier oder mehrerer Netze über ein L2L-VPN greife ich zum Tunnel-Mode und kann dann auch Netze miteinander verbinden, deren Adressen sonst nicht geroutet werden, wie zum Beispiel solche mit Adressen nach RFC 1918 über das Internet.
Will ich nur den Datenverkehr zwischen zwei Hosts absichern, kann ich den Transport-Mode verwenden und habe mehr Platz für die übertragenen Nutzdaten.
Beim Aufbau eines IPsec-Tunnels werden zunächst die Schlüssel für ISAKMP ausgetauscht (Phase 1 bei IKEv1) und anschließend die Traffic-Selektoren und Schlüssel für die Datenübertragung (Phase 2 bei IKEv1). Bei IKEv2 überschneiden sich die beiden Phasen, wodurch das Protokoll mit weniger Datagrammen zum Verbindungsaufbau auskommt und ein Tunnel schneller ausgehandelt werden kann.
Dabei sind mir bisher am häufigsten die folgenden Probleme begegnet, die dazu führen, dass entweder ein Tunnel gar nicht erst aufgebaut wird, oder keine Daten übertragen werden:
verschiedene IKE-Versionen auf beiden Seiten,
unterschiedliche Krypto-Parameter für Verschlüsselung, Integrität, Pseudozufallsfunktion oder die DH-Gruppe für die Schlüsselgenerierung,
unterschiedliche Krypto-Parameter oder Traffic-Selektoren für die IPsec-SA, die festlegen, welcher Traffic durch das VPN gehen soll,
Senden von Traffic, der nicht in den Traffic-Selektoren für die zugehörige IPsec-SA vereinbart wurde.
Will ich Probleme mit IPsec VPN beheben, sollte ich den grundlegenden Ablauf verstanden haben und wissen, wann und wie ich welches der obigen Probleme erkennen kann.
Einem Teil dieser Probleme kann ich schon mit einem Paketmitschnitt zwischen den VPN-Gateways beikommen. Aus diesem kann ich direkt Informationen über die verwendeten IKE-Versionen und die Krypto-Parameter in Phase 1 herauslesen. Sobald jedoch der erste Sitzungsschlüssel festgelegt ist, kann ich nur noch Vermutungen anhand der Größe der einzelnen Datagramme und des zeitlichen Ablaufs anstellen. Dazu muss ich wissen, wann welche Daten übertragen werden und was ich daraus schließen kann.
Für Probleme in der zweiten Phase des Protokolls und bei der Datenübertragung komme ich mit Paketmitschnitten nicht sehr weit. Dann muss ich auf die Protokoll- und Debug-Möglichkeiten meines VPN-Gateways zurückgreifen.
Verschiedene Hersteller
Ein großer Vorteil von IPsec ist, dass das Protokoll von verschiedenen Herstellern implementiert wurde, was einen Vendor-Lock-In für IPsec in den meisten Fällen ausschließt.
Gleichzeitig ist das auch ein Nachteil, weil die verschiedenen Hersteller diesen Standard unterschiedlich interpretieren, was zu kleinen, manchmal doch sehr störenden Unstimmigkeiten führen kann. Auch haben die verschiedenen Hersteller den Standard in unterschiedlichem Umfang implementiert, so dass ich genau prüfen muss, ob eine Implementierung meine Anforderungen überhaupt erfüllen kann.
Jedes Gerät reagiert anders auf ähnliche Situationen. Idealerweise habe ich bereits vor der konkreten Fehlersuche verschiedene Szenarien in einem Testlabor durchgespielt und habe somit eine ungefähre Vorstellung davon, welches Problem vorliegen könnte, wenn mein Gerät auf eine bestimmte Art reagiert.
Habe ich ein VPN-Gateway, das Verbindungen zu sehr vielen Peers aufbaut, gerate ich in zusätzliche Zwänge dadurch, dass die verschiedenen Peers, wenn deren Gateways von verschiedenen Herstellern kommen, sehr unterschiedliche Anforderungen haben können. Dass kann dazu führen, dass ich im ersten Datagramm mehrere unterschiedliche Proposals für die Crypto-Parameter senden muss. In einem konkreten Fall kam das Proposal für den betreffenden Peer an neunter Stelle, das VPN-Gateway des Peers verarbeitete jedoch nur die ersten acht, so dass schon das Aushandeln des ISAKMP-Tunnels scheiterte.
Begriffsverwirrungen
Da jeder Hersteller IPsec auf seine Art interpretiert und teilweise für den Administrator nur eine Untermenge der vom Standard abgedeckten Optionen anbietet, die er dann noch in der Administrationsumgebung anders präsentiert als die anderen Hersteller, gibt es genügend Ursachen für Verwirrung zwischen den Administratoren, die VPN zwischen verschiedenen Geräten aufbauen wollen. Dazu kommen die Unterschiede zwischen IKEv1 und IKEv2, die die Verständigung erschweren können.
So habe ich häufig das Problem erlebt, dass die IPsec-Implementation einiger Hersteller bei IKEv2 nur die eine IPsec-SA verwendet, die im Rahmen der Authentisierung ausgehandelt wurde. Senden diese VPN-Gateways dann Traffic, der nicht zu den ausgehandelten Traffic-Selektoren passt, verwirft das andere Gateway den Traffic und schreibt entsprechende Lognachrichten. Oft lassen sich die problematischen VPN-Gateways dazu bewegen, mehrere IPsec-SAs mit den passenden Traffic-Selektoren auszuhandeln, doch die entsprechenden Optionen heißen fast überall anders und sind an anderen Stellen zu finden.
NAT
Netzwerkadressumsetzung, eine Erblast von IPv4, die sich nach IPv6 gerettet hat, kann ein VPN auf verschiedene Art beeinflussen:
NAT zwischen den beiden VPN-Gateways sorgt zuerst einmal dafür, dass IPsec, so wie es ursprünglich gedacht war, nicht funktioniert, weil dabei die Quell- und Zieladressen vom Protokoll abgesichert werden und durch das Ändern der Adressen die Datagramme ungültig werden. Bei IKEv1 wurde nachträglich mit NAT-T eine Erweiterung gefunden, bei IKEv2 wird NAT-T gleich automatisch berücksichtigt. In diesem Fall werden die übertragenen Nutzdaten in UDP-Datagramme mit Port 4500 gekapselt, anstatt das Protokoll ESP (50) oder AH (51) direkt zu verwenden.
Insbesondere, wenn die via VPN verbundenen Netze überlappende Adressbereiche (zum Beispiel nach RFC 1918) verwenden, muss ich diese Adressen umsetzen. Dabei muss ich beachten, dass die Datagramme, die zwischen den VPN-Gateways verschlüsselt ausgetauscht werden, genau den ausgehandelten IPsec SA entsprechende Adressen tragen. Hier gibt es Probleme, wenn eine Seite das nicht so genau nimmt und unpassende Datagramme sendet, die die andere Seite verwirft. Hält man sich an die Regel, verschlüsselte Daten nur mit den für die IPsec SA ausgehandelten Adressen zu versenden, hat man einen Teil der Probleme schon vermieden. Dann muss nur noch jede Seite für sich sicherstellen, dass die bei ihr lokal verwendete NAT-Zuordnung eingehalten wird und die Firewallregeln entsprechend angepasst sind.
Aus dem Diagramm wird deutlich, dass im internen Netz A nur Datagramme auftauchen sollten, die von Adresse Aa nach Ab gehen, oder umgekehrt. Im VPN-Tunnel sollten nur Datagramme auftauchen, die von Adresse TSa nach TSb oder umgekehrt gehen. Das sind die Adressen, die mit den Traffic-Selektoren für die entsprechende IPsec-SA ausgehandelt wurden. Ob die Adresse Aa mit TSa identisch ist, beziehungsweise Ab mit TSb, hängt von den Gegebenheiten im Netz A ab und obliegt dem Administrator dieses Netzes. Das gleiche gilt für das Netz B, in dem nur Datagramme mit den Adressen Ba und Bb vorkommen sollten. Sinngemäß gilt für NAT am VPN-Gateway B, dass die Adressen umgesetzt werden müssen, wenn TSa verschieden ist von Ba und/oder TSb verschieden von Bb. Das ist die Aufgabe von Administrator B.
Bei L2H- und erst recht bei H2H-Verbindungen, die mit IPsec gesichert sind, reduziert sich das NAT-Problem, da auf der Seite des Hosts keine Adressen umgesetzt werden müssen. Es verbleibt jedoch das Problem von NAT-Boxen im IPsec-Pfad.
Koordinationsprobleme
Bei H2H VPN gibt es außer den Absprachen zwischen den beiden Administratoren keine weiteren Koordinationsprobleme.
Sobald aber auf einer oder beiden Seiten ganze Netzwerke an das VPN angeschlossen werden (L2L, L2H), müssen für vollständige Tests auch Anwender der Rechner in den beteiligten Netzwerken mitwirken, um den benötigten Test-Traffic zu erzeugen. Das sind im ungünstigen Fall vier oder noch mehr Personen, deren Aktionen koordiniert werden müssen.
Geht es nicht um Performanceprobleme, kann für einfache Funktionstests eine Sonde helfen, die den benötigten Traffic generieren kann. Auch wenn ich damit keine vollständige Verbindung herstellen kann, so kann ich damit grundlegende Probleme erkennen und die Funktionsfähigkeit der VPN-Verbindung mit Paketmitschnitten demonstrieren.
Natürlich kann ich damit nicht jede Verbindung prüfen, aber zumindest die auf meiner Seite ausgehenden Flows.
Als Sonde eignet sich bereits ein Linux-Rechner mit netcat. Ob eine Sonde am VPN-Gateway platziert werden kann, muss ich jedoch im konkreten Fall prüfen. Dagegen könnten organisatorische Probleme sprechen, weil diese Sonde eine starke Sicherheitsbedrohung darstellen kann, wenn der Zugriff darauf nicht hinreichend reguliert ist. Technische Probleme, die dem Einsatz der Sonde entgegen stehen könnten, liegen vor allem im Bereich des OSI-Layer 2. Zum Beispiel, wenn die von der Sonde generierten Datagramme vom VPN-Gateway verworfen werden, weil die Absender-MAC-Adresse nicht passt. Oder, wenn die Datagramme vom Switch verworfen werden, weil die - für den Einsatzfall korrekte - MAC-Adresse am falschen Switch-Port verwendet wird.
Ausblick
Damit habe ich die grundlegenden Probleme bei der Fehlersuche in IPsec-VPN angesprochen. Wie ich die einzelnen Probleme eingrenzen und identifizieren kann, bleibt anderen Artikeln vorbehalten. Im Wesentlichen geht es dann darum,
- wann welche Informationen bei den einzelnen Protokollen von IPsec ausgetauscht werden,
- wie ich IPsec-VPN mit Paketmitschnitten analysieren und welche Informationen ich daraus gewinnen kann, und
- wie ich die Protokoll- und Debugnachrichten meines VPN-Gateways analysiere und mit den anderen Informationen abgleiche.
Der letzte Punkt ist sehr implementationsspezifisch und meist nicht einfach auf andere VPN-Gateways übertragbar.
Posted 2017-12-13