Proprietäre VPN-Architekturen
- Einfacher Klick für den Tunnelblick
- Proprietäre VPN-Architekturen
- Gleiche Device-Oberflächen
- Zentrale VPN-Konsolen
- Prüfpunkte für VPN-Management-Konsolen
Nach »so einfach wie ein Telefongespräch« klingt das wahrlich noch nicht, auch wenn man konzediert, dass Softwareinstallation und Einstellungen nur bei der Inbetriebnahme anfallen. Spätestens dann, wenn sich der Einwahltypus (WLAN statt UMTS, ISDN statt DSL) ändert, müssen doch wieder andere Einstellungen beherrscht werden. Die Konfiguration kann je nach VPN-Anbieter und Umfeld dann recht kompliziert werden. An der Goethe-Universität Frankfurt am Main, wo VPN auf der Basis eines Nortel Contivity Gateways und entsprechender Software zu 90 Prozent für den WLAN-Zugang genutzt wird und nur die restlichen zehn Prozent für die Einwahl von Heimarbeitern und Außendienstlern, muss der Windows-Nutzer beispielsweise einen vom Hochschulrechenzentrum konfektionierten Client installieren. »Da der VPN-Client tief in das System eingreift und sich mit den VPN-Clients anderer Hersteller beißt, ist die Installation als nicht unproblematisch zu bezeichnen«, bemerkt Michael Poser vom Hochschulrechenzentrum. Aber es gebe ja den Support. Da die VPN-Verbindung in erster Linie dem WLAN-Zugang diene, gehe die Tendenz am Uni-Rechenzentrum dahin, so Poser, »über Zugangs-Alternativen für Heimarbeiter und Außendienstler nachzudenken«. Das technische Ambiente eines Hochschulrechenzentrums ist sicher besonders delikat für den VPN-Betrieb. »Wir können unseren Nutzern schließlich nicht vorschreiben, welche Software sie auf ihren persönlichen Notebooks aufspielen sollen«, beschreibt Michael Poser die komplizierte Situation. Dass gleichzeitig bei der seinerzeit gewählten VPN-Lösung von Nortel »die IPSec-Verhandlungen sehr proprietär umgesetzt sind und darüber hinaus die Spezifikationen nicht offen zugänglich sind«, wie Jörg Hirschmann, Leiter Technik/Services beim Nürnberger VPN-Spezialisten NCP Engineering meint, macht die Situation nicht einfacher.