Teil 6 – Abschnitt G: Weitere Tools zum Troubleshooting

Autor: Claus Greck [MVP], MCSEboard.de

Obwohl Sniffer wie Ethereal oder der Netzwerkmonitor die erste Wahl bei der Fehlersuche im Netzwerkbereich sein sollten, beschränkt sich ihr Einsatz bei Verbindungsproblemen mit L2TP oder auch PPTP mehr darauf, zu sehen, ob generell was läuft. Dadurch dass die Tunneldaten verschlüsselt sind, das will man ja mit dem Tunnel schließlich erreichen und zwar auch für die Tunnelaushandlung, sind die einzelnen Rahmen schwer auswertbar.

Es gibt aber weitere Tools, die einem bei der Fehlersuche nützlich sein können

Oakley-Logging.

Das in meinen Augen wertvollste Tool zum Aufspüren möglicher Fehlerursachen bei IPSec-verschlüsselten Verbindungen, ist das Oakley-Logging. Es muss erst in der Registry eingeschaltet werden.

Anschließend  muss der IPSec-Dienst und auch der Ras-Dienst neu gestartet werden. In einer Kommandozeile gibt man ein:

net stop remoteaccess

net Stop policyagent

net start policyagent.

net start remoteaccess.

Der IPSec-Dienst legt bei eingeschaltetem Logging im Ordner %systemroot%Debug eine Datei oakley.log an. Diese ist ASCII-Code und kann mit einem normalen Texteditor angeschaut werden. Bei jedem Start des IPSec-Dienstes  wird die Datei oakley.log neu angelegt und die alte Datei nach oakley.log.sav weggesichert.

In der Log-Datei kann man die einzelnen Schritte des Tunnelaushandlung für beide Phasen (Main Mode und Quick Mode) im Klartext verfolgen, man sieht welche gegenseitige Authentifizierungsmethode gewählt wurde,  welchen Verschlüsselungsalgorithmus, welchen Hash-Algorithmus und natürlich auch Fehlermeldungen. Ein Beispiel dafür schildere ich mit Praxisbezug im Teil 6: Abschnitt H – L2TP und Firewalls.

Ereignisanzeige

Die Ereignisanzeige kann natürlich insbesondere was Dienste angeht einige Informationen ausgeben, aber auch was die Tunnelaushandlung betrifft. Dazu muss man jedoch die Überwachung der Fehlgeschlagenen und Erfolgreichen Anmeldeereignisse überwachen.

Man erhält jetzt nicht die Masse von Informationen, aber möglicherweise Hinweise, die die Fehlersuche eingrenzen.

So besteht der in Teil 6 – Abschnitt F beschriebene erfolglose Tunnelaufbau aus drei Einträgen im Sicherheitsprotokoll:

1. Eintrag im Sicherheitsprotokoll (Erfolsüberwachung)

2. Eintrag im Sicherheitsprotokoll (Fehlerüberwachung)

3. Eintrag im Sicherheitsprotokoll (Erfolgsüberwachung)

Im ersten Eintrag (Erfolgsüberwachung) wird die erfolgreiche Aushandlung der Phase I (Main Mode) eingetragen, was man sowohl im Netzwerkmonitor, als auch im Oakley Log sehen kann. Der zweite Eintrag, der Fehlversuch, ist die fehlgeschlagene Aushandlung der Phase II (Quick Mode). Der angegebene Grund: keine Richtlinie definiert. Diese Aussage ist etwas irreführend, eine Richtlinie war definiert, der Grund für den Fehlschlag war eigentlich ein nicht stimmender Hashwert aufgrund eines zwischengeschalteten NT-Gerätes. Der dritte Eintrag (Erfolgsüberwachung) zeigt an, dass die erfolgreiche Sicherheitszuordnung der Phase I wieder gelöscht wurde.

IPSicherheitsmonitor

Der IPSicherheitsmonitor ist ein Tool, das man sich selber über eine leere Management-Konsole erstellen kann. Allerdings ist es für das Troubleshooting bei nicht erfolgreichen L2TP/IPSec Verbindungen aus meiner Sicht nur sehr begrenzt bis fast gar nicht geeignet, auch wenn es in allen möglichen Microsoft-Artikeln bei den Troubleshooting Tools mitaufgeführt wird.

Man kann sich zwar alle möglichen Parameter und Filtereinstellungen, Verschlüsselungs-, Hash- und Authentifizierungsverfahren bei einem erfolgreichen Verbindungsaufbau anzeigen lassen, bei Fehlern, wenn also keine Sicherheitszuordnung stattfindet, sind die Grenzen des Tools schon erreicht. Lediglich im Feld Statistik kann man sehen, wie viele Aushandlungsfehler es gegeben hat. Nicht sehr hilfreich …

Zur Installation des IPSicherheitsmonitors führt man folgende Schritte aus:

© MCSEboard.de, Claus Greck [MVP]