Test Of Tools: Nach Hause Telefonieren - VPN mit OSX / iPhone

info

date: 2016-05-30 15:27:29

tags: IT security VPN OSX and MacOS Howto

category: Test of Tools

Created by: Stephan Bösebeck

logged in

ADMIN


Test Of Tools: Nach Hause Telefonieren - VPN mit OSX / iPhone

no english version available yet

Eigentlich kein echtes "test of tools", weil nicht viele Tools vorkommen, aber dennoch hab ich es mal zu dieser Rubrik gepackt.

Folgendes Scenario: man ist unterwegs oder in der Arbeit oder sonst wo und möchte kurz daheim mal auf seinen Servern eine Datei holen oder mal schnell eine TV-Aufnahme mit der Dreambox Programmieren. Eine eigentlich lösbare Aufgabe sollte man meinen. Hier eine Aufstellung der von mir getesteten Möglichkeiten (und ein paar Tipps dazu):

"Eigenes" VPN mit SSH

Naja, so richtig als VPN kann man das nicht bezeichnen. Aber man kann per SSH ne Menge machen. Das einzige, was man tun muss, ist in seinem Router einen Port frei schalten. Bei der Fritz!Box ist das unter Internet->Freigaben:

Man kann Portfreigaben deaktivieren, aus Sicherheitsgründen hab ich hier mal ein paar versteckt. Der Dynamic DNS Eintrag ist wichtig (s.u.) und mit dem Button "Neue Portfreigabe" kann man eine Neue Freigabe einrichten - das sieht dann so aus:

Dabei gibt man an, welche externe also öffentliche port-Range (von-bis) auf den Computer im eigenen Netz geleitet werden sollen. Für SSH sollte der Zielport 22 sein (das ist der Standardport für ssh), Protokoll ist TCP. Leider gibt es in der Vorauswahl von Anwendungen SSH nicht, weshalb man auf "Andere Anwendung" gehen muss. Achtung: Nutzt nicht Exposed host! Dann wird der gesamte Traffic an den Rechner weitergeleitet und das will man normalerweise nicht.

Das ganze kann natürlich nur funktionieren, wenn man auch dyndns oder so was eingerichtet hat - sonst "findet" man seinen Router ja gar nicht und kommt somit auch nicht an die freigegebenen Ports.

Wobei man da schon beim nächsten Problem ist: Wohin sollte man den Port weiter leiten. Man benötigt da also irgendwas, was nen SSH-Server laufen lässt. Man kann das schon auf der FritzBox selbst machen, oder normalerweise auch auf den meisten anderen Routern, aber das erfordert doch ein wenig Geschick: Anleitung dafür gibt’s zum Beispiel hier.

Wenn man in der Firmware des Routers nicht rumfummeln will, dann benötigt man irgend einen anderen Rechner im Netz, der als SSH-Endpunkt dient. Da funktioniert z.B. auch die Qnap (wobei man evtl. den SSHD hier auch korrigieren muss: siehe hier). Ein Mac oder Linux Rechner wäre Ideal, ein Windows-PC geht auch - allerdings muss man sich dann nen SSHD installieren (mit cygwin z.B.).

Der Standard-Port des SSH ist Port 22. Man sollte allerdings vermeiden, den Port 22 nach außen frei zu schalten, sondern man sollte da irgend einen anderen nehmen, am besten was über 1024 oder sogar noch größer. Da alle ports < 1024 gerne mal gescannt werden und es ne Menge Scripts gibt, die versuchen mit "default"-Passwörtern einzubrechen (und sich ein paar MöchtegernHacker dann tierisch freuen, wenn sie "eigebrochen" sind... dann sind die total 1337).

Da sind wir dann auch schon beim nächsten Tipp: gute Passwörter verwenden! Oder, wenn man den Zugriff nur von wenigen Rechnern aus machen möchte, dann kann man auch eine Public-Key Authentifizierung verwenden und die Password-Auth Komplett ausschalten. Die Konfiguration dafür ist ein wenig abhängig vom Betriebssystem aber im Allgemeinen muss man im Home-Verzeichnis des Users, der sich anmelden soll (auf dem SSH-Server!), ein Verzeichnis namens .ssh anlegen. Dieses sollte nur für den Nutzer les- und schreibbar sein. In dem Verzeichnis legt man ein File an, names "authorized_keys". Das ist ein einfaches Textfile in dem man die PublicKeys aufnimmt.

Die Public-Keys muss man dann auf dem Client erstellen, also auf dem Notebook mit dem man unterwegs ist. Das funktioniert auch wieder recht unterschiedlich, unter Windows nutzen viele Putty, da gibt’s dafür nen Menüpunkt. In der Shell tippt man einfach ein

ssh-keygen -t rsa -b 2048
Damit wird ein neues Keypair erzeugt. Das liegt wieder in dem .ssh-Verzeichnis des Users und besteht aus 2 Dateien: id_rsa und id_rsa.pub. Die pub-Datei ist der Public key, dessen Inhalt müsst ihr einfach in das Authorized-Keys File auf dem Server einfügen. Dann sollte der Zugriff gehen.

Und wie geht das jetzt mit dem Tunnel? Dazu muss man im Client den Aufruf entsprechen Konfigurieren. Bei Putty unter Windows gibt es da Dialoge für die Einstellung der tunnel. Aber auch in der Kommandozeile geht das recht simpel:

ssh -l user meinserver.dyndns.de -L1234:192.168.22.1:80
so wird z.B. eine Verbindung zu meinserver.dyndns.de aufgebaut. Wenn man sich erfolgreich mit dem Benutzer "user" eingeloggt hat, wird ein Tunnel geöffnet: Alle Anfragen an den lokalen Port 1234 werden über SSH weitergeleitet an den Server, welcher seinerseits die Anfragen und Daten weiterleitet an in diesem Fall den Server mit der IP 192.168.22.1, Port 80.

D.h. wenn ich jetzt in meinen Browser die URL http://localhost:12345/ eingebe, lande ich auf dem Webserver mit der IP 192.168.22.1

Man kann zwar nahezu beliebig viele solche Tunnelangaben beim Aufruf von SSH machen, das ist aber wenig spassig, und man ist auch immer auf der Suche nach den richtigen Ports. Zum Glück gibt es auch dynamische Ports

ssh -l user meinserver.dyndns.de -D 1234
Damit wird ein dynamischer SOCKS-Proxy erzeugt. Dieser funktioniert quasi identisch zu dem manuellen Tunnel mit -L, aber er baut dynamische Tunnel zu beliebigen Zielen auf. Nachteil: die Anwendungen, die man nutzen will, müssen SOCKS unterstützten. Die gängigen Browser tun das alle, aber bei anderer Software wird es schnell eng...

Außerdem kommt man so auch nur schwer an die Freigaben von z.B. seinem NAS ran oder so.

Übrigens: das funktioniert auch mit dem iPhone - die SSH-Clients für das iPhone unterstützen alle auch Tunnel...

die Flexibilität ist natürlich extrem, ich kann jeden beliebigen Port weiterleiten. Allerdings muss ich das auch, wenn ich darauf zugreifen will.

Die Nachteile liegen somit ziemlich auf der Hand: man muss alle ports mehr oder minder manuell mappen und dann funktioniert es auch nicht immer reibungslos (AFP-Sharing z.B.). Namensauflösung darüber zu machen ist auch schwer, da man kein UDP-tunnel machen kann, sondern nur TCP. Deswegen ist das eine recht gute Lösung für den Notfall, aber für den mehr oder minder täglichen Zugriff ist das nix.

TestOfTools Rating: 4/10 Punkten

 

Pseudo VPN mit ShareTool

Im Endeffekt ist das eine grafische Oberfläche für die oben beschriebenen SSH-Methoden + noch mehr. Allerdings ist die Software nicht umsonst - dafür wirklich "Narrensicher";-)

Sharetool 2 bekommt ihr hier - probiert mal die Demo aus, das ist echt ok - die $20 sind gut investiert, wenn man auf "daheim" zugreifen möchte.

Sharetool benötigt allerdings einen Mac auf dem es laufen kann - Linux oder Windows läuft leider nicht. Was sicher einer der Nachteile von Sharetool ist. Allerdings ist die Einrichtung denkbar simpel und man benötigt nicht mal so was wie Dyndns - das erledigt der Sharetool Service. Auf dem Server, also dem Rechner im Heimnetz, startet man Sharetool und konfiguriert das sharing:

Dabei könnte man seine eigene Portfreigabe verwenden, oder sich von sharetool einen eigenen Port konfigurieren lassen - sofern euer Router UPNP versteht. Falls ihr das das erste Mal macht, müsst ihr noch einen Login anlegen. Der Server meldet sich dann unter dieser Kennung mit seiner öffentlichen IP-Adresse an. Clientseitig läuft das genaue "Gegenteil" - man loggt sich ein, erhält die IP Adressen der verschiedenen Netzwerke unter eurer Kennung und man kann sich aussuchen, wo man sich einloggen will:

Nach dem Login kann man aus den bekannten Netzen wählen und sich ggf. verbinden. Dafür ist zwingend ein User auf der anderen Seite nötig, als der ihr euch einloggen könnt. Ich würde aus Sicherheitsgründen dazu raten, einen eigenen User nur für diesen Zweck einzurichten, der sonst keine Rechte am System hat - Das kann man am Mac ja relativ simpel machen. Vergebt für diesen User aber bitte ein vernünftiges Passwort oder authentifiziert euch mit dem Public-Key des SSH (s.o.).

Auf dem Mac kann man das auch in /etc/sshd_config einstellen, genauso, wie unter Unix üblich. In der Systemsteuerung gibt’s das Häckchen "Entfernte Anmeldung". Das startet, bzw. stopped den SSHD. Wenn ihr also eine Änderung an der /etc/sshd_config gemacht habt, solltet ihr den Server kurzt neu starten. Hier die wichtigsten settings:

PubkeyAuthentication yes - ist per Default an, kann man aber explizit im File setzen, wenn man möchte AllowRootLogin no - sollte zwingend aus sein PasswordAuthentication no - aus, falls man sich nur per PublicKey authentifizieren möchte, ansonsten müssen ALLE user ein gutes Passwort haben ValidUsers USER1 - so kann man den Login auf nur einen User reduzieren, alle anderen dürfen nicht
Mit diesen Settings ist auch euer Mac einigermassen sicher für angriffe von außen - allerdings würde ich immer ein gutes Passwort vergeben.

Hat man es geschafft, sich anzumelden, bekommt man von ShareTool eine sehr praktische Auswahl aller Bonjour-Services:

 

Durch einen Doppelklick kann man sich dann mit dem entsprechenden Service verbinden - so als wäre man im eigenen Netz... Und möchte man dann noch "Anonym", also über seine eigene Home-Verbindung im Internet surfen (das ist manchmal ganz praktisch für sehr strikte firmenpolitik), dann kann man unter Options den Menüpunkt "Browse Web securely" wählen. Das öffnet den Firefox und surft dann über den SSH-Tunnel und seine eigene Leitung.

Nachteile von dieser Lösung: Man bekommt eigentlich nur relativ Problemlosen Zugriff auf Bonjour Services, alles was darüber raus geht, erreicht man nicht. Man kann zwar auch eigene Services registrieren, aber das ist ein gefummel und habe ich noch nicht hin bekommen - wenn Ihr da ne Idee habt, immer her damit ;-)

Aber für die Meisten sollte das gut reichen, da der Zugriff auf Shares, Web, Printer und Screen Sharing gut funktioniert.

Ist noch erschwinglich und ist eine solide 90% Lösung, sofern man einen MacServer hat - und das können nicht viele von sich behaupten.

TestOfTools Rating: 7/10 Punkten

OpenVPN

Das ist eine "echte" VPN Lösung, die den Netzwerktraffic auf einer der unteren OSI-Layern verschlüsselt. Das ganze funktioniert auch über SSL und verlangt keine besonderen Einstellungen oder Fähigkeiten vom Router oder Provider  - es gibt auch eine Implementierung für das iPhone oder Android, allerdings nicht nativ, muss gesondert installiert werden.

OpenVpn wird immer beliebter, hat aber leider noch nicht in viele Router einzug gehalten. Deswegen benötigt man auch hier einen eigenen Server, der als OpenVPN-Server fungiert. Hierfür muss im Router eine Portfreigabe eingerichtet werden - normalerweise UDP 1194. Ist aber frei wählbar.

Für den Zugriff vom Mac aus benötigt man einen Client, da auch hier keine native VPN-Implementierung verfügbar ist. Am besten bewährt hat sich bei mir das Tool Tunnelblick, obwohl es noch immer im Beta Stadium ist. Dennoch klappt das recht gut, auch wenn der einwahlvorgang immer recht lange dauert (im Vergleich zu den anderen hier vorgestellten lösungen).

Als OpenVPN-Server habe ich die Qnap gewählt, da geht das recht simpel:

hier kann man eigentlich nur den Haken bei "Server aktivieren" anschalten, dann läuft alles. Man muss nur noch die Konfigurationsdatei herunterladen und alles sollte einigemassen passen. Allerdings muss man da drin die Öffentliche IP Adresse vermutlich ändern. Da steht, wenn man nicht DynDns auch über die Qnap macht, die gerade aktuelle öffentliche IP drin. Das funktioniert dann für den Moment, aber morgen nicht mehr.

In Tunnelblick muss man nur ne neue Config anlegen, das erklärt sich mehr oder minder von selbst... auch wenn es einige Schritte sind.

Leider kann man hier das routing nicht einstellen, d.h. man surft immer komplett über die Leitung "daheim". Also ein Zugriff nur auf das Netz, ohne den ganzen Traffic darüber zu leiten ging nicht. Auch gibt es wohl einen Bug in der Qnap: Wenn man die Default-Route ausschaltet, geht gar nix mehr. War zumindest bei mir so...

Das ist allerdings auch erstaundlich simpel einzurichten und es funktioiniert recht solide, wenn man einen Brauchbaren Server hat. Dennoch gibt’s ein paar Punktabzüge, da die Konfiguration so etwas nervig ist. Im normalfall würde ich da 10/10 Punkten vergeben, aber da das ganze leider auf der Qnap ein wenig krankt bekommt das ganze weniger. auch ist schade, dass es keine Nativen Clients von Apple für OSX und/oder iOS gibt, so wie für IPSec Und leider auch keine Implementierung für die Fritz!Box.

TestOfTools rating: 8/10

 

IPSec VPN mit Fritz!Box OS6.0

Das ist eigentlich wäre das die optimale lösung. Allerdings war es bisher immer ein Graus, IPSec selbst zu konfigurieren. Vor allem, weil die Router spezielle Protokolle korrekt weitergeben mussten. Der Support für IPSec war da nicht so verbreitet. Obwohl es angeblich die sicherste VPN-Variante sein sollte.

Zum glück ist die konfiguration mittlerweile in der Fritz!Box so stark vereinfacht worden, dass man das in ein paar Mausklicks zusammengestellt hat. wichtig: Man muss für jeden VPN-Zugang einen User anlegen. Das Passwort dafür sollte entsprechend komplex sein.Die VPN-Einstellungen sind auch unter "Freigaben" zu finden, dort gibt es einen Reiter "VPN":

Dort kann man dann einen User für den Remote Zugriff einrichten, oder netz-zu-netz verbindunge (also Fritz-zu-Fritz) einrichten.  Das ist ganz sinnvoll, wenn man zwei Standorte verknüpfen will - die fungieren dann netzwerktechnisch als einer - was den Zugriff auf Fileserver etc. natürlich stark vereinfacht.

für uns hier wichtig, ist der erste Punkt: Fernzugang für einen Benutzer einrichten. Dort ist eigentich nur das Häckchen für VPN zu setzen, ein gutes Passwort zu vergeben und das war es schon. Bei Bedarf kann man dem User auch noch Zugriff auf andere Services der Fritzbox gewähren. Das ist ganz interessant: wenn man aus dem lokalen Netzwerk auf die Fritz!Box zugreifen möchte, muss man ein Passwort eingeben. Macht man das selbe über das VPN, dann kommt ein User/Passwort login - aus Sicherheitsgründen!

Die emailadresse kann übrigens auch als Login benutzt werden, wenn ich das richtig verstanden habe. Bisher hatte ich das aber noch nicht nutzen müssen. Am Ende der ganzen Prozedur, kann man sich noch die Einstellungen für iOS und Android anzeigen lassen:

Mit diesen Einstellungen kann man auch recht simpel den Zugriff von OSX aus einrichten. Dazu muss man eine Neue Netzwerkverbindung einrichten. Unter Systemeinstellungen->Netzwerk kann man durck klicken auf das "+" eine Neue Verbindung einrichten.

Nach dem man auf den + geklickt hat, muss man nur noch Cisco-VPN auswählen und die Einstellungen von der Fritz!Box eintragen. DAbei auch nicht die "Authentifzierungseinstellungen" vergessen, denn dahinter verbirgt sich die Gruppe und das Shared Secret. Und auch wichtig: Unter "Weitere Optionen" muss der für das Zielnetz gültige DNS angegeben werden - also die IP-Adresse der Fritz!Box - sowas wie 192.168.178.1 oder so.

Das alles funktioniert normalerweise recht gut - auch hier ist wieder eine Dyndns-Anmeldung nötig. Allerdings hat das ganze einen kleinen Haken - man kann nicht mehr einstellen (OSX 10.9 mavericks), dass nicht der gesamte Traffic über die Leitung gehen soll. Das konnte man früher mal einstellen, ist aber jetzt weg.

D.h. wenn ich eingewählt bin, geht der gesamte IP-Traffik über das VPN.

Korrigieren kann man das allerdings recht einfach: Es gibt eine Route, über die das geregelt wird. in der Shell kann man das recht einfach korrigieren. Allerdings ist da manuelles Eingreifen nötig. Für die meisten ist das vermutlich eh kein Problem, sondern eher ein vorteil.

Der einzige Nachteil dieser Lösung ist, dass man wenig einstellen kann. Aber sonst ist das doch eine der besseren Varianten. Leider funktioniert es aber nicht über 3G oder LTE - zumindest bei meinem Anbieter wird IPSec nicht unterstützt. Evtl. ist das bei anderen Anbietern anders, im Zweifel solltet ihr euch erkundigen. Im WLAN/LAN sollte es eigentlich funktionieren, aber auch hier ist man Abhängig vom WLAN/LAN Route. Wenn der IPSEc auch nicht unterstütz ist man .... angeschmiert. Deswegen auch hier nicht volle Punktzahl:

TestOfToolsRanking: 9/10

Fazit:

Irgendwie gibt es wohl keine 100%-Lösung, an der man nicht lange rumbasteln muss. 100% - zumindest was die Flexibilität und routing etc betrifft, könnte man vermutlich nur mit einem eigenen Linux-Server und viel Zeit erreichen. Wenn man sich da reinfuchsen will, ist das sicherlich die 100% Lösung.

für die allermeisten Zwecke sind die  hier vorgestellten Wege (abgesehen vom ersten vielleicht) völlig ausreichend. Wer spezielle Anforderungen hat, muss sich auch speziell darum kümmern.

Mein Favorit momentan ist das IPSec-VPN, da ich dafür nicht noch einen eigenen SSH oder OpenVPN-Server benötige. Ich konnte aber auch eine ganze Zeit lang ohne IPSec leben und das ganze mit ShareTool bzw. Openvpn erledigen, da ich hier (noch) einen MacMini rumstehen habe, der gerne auch mal was tun soll ;-)

Entscheiden müsst ihr wohl von Fall zu Fall, welche Lösung am besten auf eure Bedürfnisse passt, da alle Lösungen eigene Nachteile haben:

  • SSH manuell ist viel zu kompliziert und erfordert eine Menge Wissen über die Dienste, die man ansprechen will. Für Notfälle aber sicherlich sinnvoll
  • Sharetool zeigt nur Bonjour-Services, der zugriff auf andere ist schwierig
  • Sharetool kostet Geld
  • OpenVPN und ShareTool benötigen beide einen Server auf dem sie laufen können
  • IpSec natürlich auch, aber die Fritzbox unterstützt es mittlerweile
  • OpenVpn hat keine Native Implementierung in OSX oder der Fritzbox.
  • OpenVPN ist beim Verbindungsaufbau recht langsam