Lancom VPN-Client fuer Apple

[Koppelfeld]

Guten Tag !

Ein Kollege bemängelt die "Untauglichkeit" des Clients auf "Mac OS".

Bislang setzt das Unternehmen "Tunnelblick" ein, und wie der Name, so das Produkt.
Was die Anwender aber gewohnt sind - und ein Äppel-Anwender ist zu nichts anderem fähig - :

Eine Ein-Klick - Installation mit automatischer Konfiguration.

Es handelt sich um viele Außendienstler, es sind auch Frauen dabei. Es muß also wirklich einfach und zuverlässig funktionieren.

Das sei, so behauptet mein Kollege, nicht mit dem "Advanced VPN Client" möglich. Ich hoffe doch, er vertut sich ?

[uwe21]

, naja, geht nach KB ganz einfach und fix, sowohl mit PSK als auch mit Zertifikaten, ist schick und sicher.
Wo ist das Problem?

uwe21

[Koppelfeld]

, naja, geht nach KB ganz einfach und fix, sowohl mit PSK als auch mit Zertifikaten, ist schick und sicher.
Wo ist das Problem?

#pragma FEMALE
"KB ??? Hatte ich unter DOS. Mein Rechner hat MB und GB !"
"PSK ? Phase Shift Keying ? Prämenstruelles Sicherheits-Kit ? Ich habe immer Sicherheitstampons in der Handtasche".

Der Kollege will:
- dem Mitarbeiter per Mail einen Link schicken
- da soll er draufklicken (am besten man nennt ihn VRUS.exe, da drückt jeder drauf)
- das VPN soll sich installieren und
- automagisch konfigurieren sowie
- das VPN aufbauen.

Klar, daß das jemand in der Zentrale vorbereiten muß.

[GrandDixence]

Siehe:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795

Stichwort: Apple Configurator 2/MDM
https://www.windowspro.de/news/mdm-micr ... 02901.html

[_Lars_]

@Koppelfeld:

Wenn der Kollege es nicht schafft, bei »Tunnelblick« auf "Verbinden" zu klicken, würde ich ihn als untauglich bezeichnen.
Meinst Du, er lernt das mit einem anderen VPN-Client im Schlaf über Nacht?

[Koppelfeld]

Mit "Tunnelblick" können die Leute ja arbeiten, bloß "Tunnelblick" implementiert ja ein "OpenVPN".

Nun kenne ich wirklich jede Menge intelligente, erfahrene Leute, die "OpenVPN" einsetzen, aber ich persönlich habe noch nie einen funktionierenden "OpenVPN" - Tunnel erleben dürfen.

IPSec stinkt zwar auch, aber WENN es dann endlich funktioniert, dann funktioniert es dauerhaft.

Das tun die ganzen Open* - Produkte nicht. Jetzt vor zwei Tagen "OpenOffice" eingerichtet: Es ist nicht zu fassen, man kann nicht mehr damit drucken. Die LPR-Unterstützung wurde gestrichen. Die haben doch den Schuß nicht gehört.

Insofern ist ein bequem zu handhabender Client eigentlich das, was man erwarten darf.
Es mag ja sein, daß die selbsternannten "Digital Natives" das anders sehen, aber mittlerweile ist es unmöglich, eine passende Nahverkehrsfahrkarte aus einem Verbundautomaten zu ziehen. Unglaublich, was man da erlebt.
Unsere Anwender sollen Ihren Job erledigen und nicht am Computer basteln !
Aus diesem Grund arbeiten effektive Menschen übrigens am liebsten an einem 3270-Schirm.

Aber zurück zu meiner Frage:
Kann man den LANCOM-VPN-Client so vorkonfigurieren, daß der Benutzer lediglich einen Mailanhang ausführen muß ? Und dann noch ein Passwort eingibt ?

Es gibt doch auch die "MyVPN"-Anwendung, die freilich unbenutzbar kompliziert ist. So etwas hätte ich gern in einfach und funktionierend.

[GrandDixence]

Das tun die ganzen Open* - Produkte nicht. Jetzt vor zwei Tagen "OpenOffice" eingerichtet: Es ist nicht zu fassen, man kann nicht mehr damit drucken. Die LPR-Unterstützung wurde gestrichen. Die haben doch den Schuß nicht gehört.

Statt OpenOffice sollte LibreOffice eingesetzt werden:
https://de.wikipedia.org/wiki/LibreOffice

Und statt Line Printer Daemon Protocol (LPDP => Port TCP 515) sollte IPP eingesetzt werden. Aus Sicherheitsgründen sollte ausschliesslich "verschlüsseltes" IPP für den Versand von Druckjobs eingesetzt werden (mit TLS => https => Port TCP 443)! Eine moderne Druckumgebung in Apple-, Linux-, UNIX- oder *BSD-Umgebung setzt heute CUPS ein.

https://de.wikipedia.org/wiki/Berkeley_Printing_System

https://de.wikipedia.org/wiki/Internet_ ... g_Protocol

https://de.wikipedia.org/wiki/Common_Un ... ing_System

Aus Sicht "IT-Security" ist es ein guter Schritt, wenn OpenOffice die Unterstützung von LPDP entfernt. Die meisten Leute, die den Schritt von LPDP zu IPP "verschlafen" haben, haben auch den Wechsel von IKEv1 zu IKEv2 verschlafen...

lpr ist nur ein Kommandozeilenprogramm. lpr hat keinen Zusammenhang mit dem für die Übertragung der Druckjobs verwendeten Netzwerkprotokoll. Auf modernen UNIX-ähnliche Betriebssysteme wird das Kommandozeilenprogramm lpr, lp, lpq von CUPS bereitgestellt.

[Koppelfeld]

Das tun die ganzen Open* - Produkte nicht. Jetzt vor zwei Tagen "OpenOffice" eingerichtet: Es ist nicht zu fassen, man kann nicht mehr damit drucken. Die LPR-Unterstützung wurde gestrichen. Die haben doch den Schuß nicht gehört.

Statt OpenOffice sollte LibreOffice eingesetzt werden:

Nein, es sollte GAR NICHT eingesetzt werden, es funktionieren ja nicht 'mal Serienbriefe. Jede anständige Sekretärin haut Dir das um die Ohren.
Nein, entweder "Staroffice 5.2", das ist einfach und funktioniert. Oder LaTeX.

Und statt Line Printer Daemon Protocol (LPDP => Port TCP 515) sollte IPP eingesetzt werden.

Aus Gründen der Stabilität, der Wartbarkeit, der Vereinheitlichung und der Kosteneffizienz sollte ein Drucker möglichst wenige Protokolle beherrschen. Im Augenblick hast Du NetWare, IPP, LPR, JetDirect, SMB ... VIEL ZU VIEL. Dummerweise sind aber gerade manche schweineteuren Drucker (z.B. große Barcodedrucker) gar nicht in der Lage, mit "IPP" umzugehen.
Ich benutze kein Protokoll mit dem arrogant-irreführenden Namen "IPP", als ob LPR nicht auch ein Internetprotokoll wäre, soweit ich mich erinnere, 1069. Ich wäre eh dafür, alle RFCs ab 2.000 ersatzlos zu shreddern und gleichfalls alle neuen Gesetze, die unser "Bundestag" seit 1990 beschlossen hat. Das würde einiges erleichtern.
"IPP" ist im übrigen unbrauchbar, weil es nicht canceln kann. So richtig VON analfixierten Spinnern FÜR analfixierte Spinner gemacht. Man müßte jeden Informatiker zwangsweise ein Jahr auf den Bau und ein Jahr in ein Verwaltungsbüro schicken. Damit die überhaupt einmal sehen, wie gearbeitet wird.

Aus Sicherheitsgründen sollte ausschliesslich "verschlüsseltes" IPP für den Versand von Druckjobs eingesetzt werden (mit TLS => https => Port TCP 443)!

NEIN ! Denn die Drucker werden heute anders kompromittiert: Jedes Jahr mindestens einmal passiert es, daß ein Chef wichtige vertrauliche Nachrichten scannt und im Drucker beläßt, von wo aus diese von einer pfiffigen Sekretärin geborgen und per Flurfunk publiziert werden. Wir haben das Verfahren allerdings auch schon gezielt eingesetzt, um bewußt Falschinformation zu verbreiten, Gerücht plus Dementi ist bekanntlich Wahrscheinlichkeit im Quadrat.
Generell gilt: Wer "Windows" einsetzt, steht als Geschäftsführer sowieso mit einem Bein im Knast, denn selbst elementare, gesetzlich geforderte Sicherheit ist nicht erreichbar. Solange irgendwo eine Windows-Büchse steht, orientiert sich die "Härtung" bestimmter Protokolle an einer Heilpraxis, die gegen Beulenpest "Clerasil" verschreibt: "Schaut 'mal, die Pickel wären jetzt schonmal weg!".

Wenn Du es ordentlich machen willst: Die Drucker kommen in ein Netz, das nicht erreichbar ist für "Windows". Nur für den Druckserver, beispielsweise einen lprng. Auf Seiten Windows einen "LPR-Druckermonitor" installieren, einen neuen "lokalen Anschluß" erstellen mit LPR (Windows ist von Hause aus nicht netzwerkfähig), den Windows-Drucker darauf attachieren, "Bidirektionale Druckerunterstützung" abschalten und Option "Daten unter Umgehung des Windows-Spoolers direkt senden" aktivieren. Und den Scheiß NIE WIEDER anfassen.

Eine moderne Druckumgebung in Apple-, Linux-, UNIX- oder *BSD-Umgebung setzt heute CUPS ein.

GENAU. Und deswegen ist "Mein Drucker druckt nicht !!!" in den Supportabteilungen der meistgehörte Satz. CUPS ist ein stinkender Haufen Sondermüll und verfolgt den ideologisch völlig falschen Ansatz, für jedes Druckerli ein Treiberli oder PPDli zu erstellen.
DAFÜR wurden Seitenbeschreibungssprachen wie PostScript aber nicht erfunden.

https://de.wikipedia.org/wiki/Berkeley_Printing_System

Wikipedia. Da gibt es tolle Artikel wie zum Beispiel den über Gleichrichter. Die EDV-Themen entsprechen dem Niwo moderner Informatiker.

Aus Sicht "IT-Security" ist es ein guter Schritt, wenn OpenOffice die Unterstützung von LPDP entfernt. Die meisten Leute, die den Schritt von LPDP zu IPP "verschlafen" haben, haben auch den Wechsel von IKEv1 zu IKEv2 verschlafen...

Es geht hier um ein Programm zur Erstellung und Ausgabe von Texten und nicht um "betreutes Denken" für die Anwender. Mir reichen die Grünen.

lpr ist nur ein Kommandozeilenprogramm. lpr hat keinen Zusammenhang mit dem für die Übertragung der Druckjobs verwendeten Netzwerkprotokoll.

Geschenkt. Ich hätte 'lpd' schreiben sollen.

Auf modernen UNIX-ähnliche Betriebssysteme wird das Kommandozeilenprogramm lpr, lp, lpq von CUPS bereitgestellt.

Das ist das erste, was ich entferne. Teilweise 8-stufige Pipelines, übel kombiniertes Perl, C, Shell.


Was wir wieder brauchen, sind einfache Lösuungen. Das mit Abstand schönste Zitat Deines Landsmannes Wirth ist meiner Meinung nach:

"Herr Wirth, würden Sie sagen, 'small is beautiful' ?"
"Nein, aber ich sage deutlich, 'small is manageable'."

[steveurkel]

Hallo Koppelfeld,

MacOS bringt ja einen VPN-Client mit.

Und dann gibt noch ein Tool von Apple das dir ein sogenanntes Profil erstellt. Ich hab das bisher nur fürs Iphone genutzt, Mac OS sollte das Profil auch verstehen. Am Ende fällt da eine Datei heraus die man auf einem Mac importieren kann. Ab diesem Zeitpunkt hat man oben rechts ein Symbol das man anklickt, es geht ein Fenster auf, dort dann auf verbinden klicken-fertig. Eine Stoppuhr daneben zeigt dann die Dauer der Verbindung an.

Das Tool (Apple Configurator 2) gibts natürlich nur auf dem Mac, immerhin ist es kostenlos. Man muss es nicht nutzen, man könnte die Datei auch von Hand erstellen (XML) Diese Datei könnte man Passwortgeschützt als ZIP oä den Anwendern zusenden.

[Koppelfeld]

Ganz vielen lieben Dank für den Hinweis mit der Profildatei!
Genau das, was ich mir vorgestellt habe.

Schönes Restwochenende!

[steveurkel]

Gordon Shumway würde jetzt „Null Problemo“ sagen.

Man könnte „betreutes Wohnen“ noch auf die Spitze treiben: Mit einer (Achtung: Buzzword) EMM Solution kann man den Usern solche Profile von der Ferne aufs Gerät bügeln, ebenso wie das ein BES schon konnte. Bis 25 User gibts da auch was für lau, kann Mac, Iphone, Ipad und irgendwas mit Windows.

[Koppelfeld]

Oh, "null problemo" konnte sich bei Gordon Shumway aber auch schonmal als fataler Irrtum erweisen -- ich erinnere da an Maître Alf und seine "Ente a l'orange". "Zero problême", befand Alf lakonisch -- aber am Ende des Tages befand sich die Küche in einem beklageswerten Zustand...

Habe den Link natürlich sofort weitergeleitet. Der Kollege meint aber, es gebe zwei grundlegende Geratefamilien: Die Mobilgeräte hätten iOS (das kenne ich nur von Cisco und von IBMs i5/OS.
Die "stationären" Geräte haben Scheeleoparden, Bergkönige und jetzt Sierra Leone.

Er muß die "stationären" Geräte konfigurieren (wozu auch Notebooks gehören) und er meint, daß das Config-Tool hierfür keine kompatiblen Dateien erzeuge?

Ich selbst weiß nicht einmal, wo ich recherchieren soll. Ich bin mit KIENZLE u n d Nixdorf bestraft worden (in meinem früheren Leben war ich wohl Pol Pot und kassiere gerade die Strafe), da kann ich mir nicht auch noch Apple antun.

[steveurkel]

Also, ich hatte ja schon geschrieben das ich das bisher nur an mobilen Geräten getestet habe. Ich habe mir gerade das Tool genommen, ein IKEv2 Profil mit Fantasiewerten gefüllt und lokal gespeichert. Das Profil muss man dan auf dem Mac(book) anklicken, es erscheint eine Meldung ob man das Profil wirklich installieren will-Ja. Dann muss man das noch mit dem Passwort und Nutzernamen absegnen. (Windows UAC lässt grüßen)

Danach hat man oben neben dem WLAN-Icon ein Icon das so ein wenig an ein RSA-Token erinnert. Da draufklicken und dann bekommt man alle verfügbaren VPN angeboten die man per Klick aktivieren kann.

Ob OpenVPN zum Funktionsumfang des integrierten Clients gehört darf aber bezweifelt werden. Nicht unterschätzen sollte man das User solche Profile auch mal untereinander weitergeben oder mit nach Hause nehmen. Die Zugangsdaten stehen ja im Klartext drin. Daher würde ich sowas mit einem OTP-Token absichern. Oder gleich per EMM aufbügeln, so kommen auch keine WLAN-Passwörter abhanden bzw in private Geräte..