LogMeIn hat eine neue Version des kostenlosen VPN Hamachi herausgebracht. ZDNet erläutert die zusätzlichen Features und zeigt auf, wie man Probleme bei der Anbindung von Linux- und Mac-OS-Rechnern mit Hamachi² vermeidet.
Wer nach einer einfach aufzusetzenden und zu verwaltenden VPN-Lösung sucht, nutzt häufig Hamachi[1] von LogMeIn[2], das für eine private Nutzung mit bis zu 16 Rechnern pro VPN kostenlos ist. Hamachi ist ein sogenanntes End-to-End-VPN. Das unterscheidet es von Site-to-Site-VPNs, die mehrere Unternehmensstandorte verbinden, oder Site-to-End-VPNs, die die Einwahl von Benutzern in ein Intranet ermöglichen.
Bei einem End-to-End-VPN ist die VPN-Software auf den Rechnern aller Teilnehmer installiert. Alle Teilnehmer befinden sich bei aktivierter Software in einem virtuellen LAN. Notwendig ist dafür nur eine bestehende Internetverbindung.
Hamachi verwendet zur Tunnelung nach Möglichkeit das UDP-Protokoll. Das ermöglicht es, dass jeder VPN-Teilnehmer auch hinter einem NAT-Router sitzen kann. Falls eine NAT- oder Firewall-Einstellung eine UDP-Verbindung verhindert, nutzt die Hamachi-Software automatisch TCP.
Dabei fungiert der zentrale Hamachi-Server std.hamachi.logmein.com nur als Vermittler der öffentlichen IP-Adressen der einzelnen Rechner. Die eigentliche Kommunikation geschieht direkt von Teilnehmer zu Teilnehmer.
Nur wenn aufgrund einer sehr restriktiven Firewall-Policy keine direkte Kommunikation zu anderen Rechnern möglich ist, agiert der Hamachi-Server von LogMeIn als Router und kann sogar einen HTTP-Proxy-Server nutzen, der alle TCP-Ports außer 80 sperrt. Das ist in der Praxis jedoch nur selten der Fall. Auch in öffentlichen WLAN-Netzen und via UMTS ist meist eine direkte Kommunikation möglich.
All diese Features bieten auch andere bekannte VPN-Lösungen, etwa OpenVPN[3] oder tinc[4]. Sie sind jedoch nur mit einigem Aufwand aufzusetzen. Eine direkte Kommunikation zwischen Teilnehmern ist nur möglich, wenn man die öffentlichen Schlüssel aller Teilnehmer auf jedem Rechner pflegt.
Hamachi besticht vor allem durch seine Einfachheit. Man installiert die Software, erstellt ein Netzwerk oder tritt einem bestehenden bei. Das reicht aus, dass sich alle Rechner in einem Hamachi-Netzwerk sehen können, siehe Bild 1[5]. Ein Netzwerkbeitritt kann mit einem Kennwort geschützt werden. Ebenso lässt sich einstellen, dass ein Beitritt zu einem Netzwerk erst durch einen Administrator genehmigt werden muss. Beide Sicherheitsmaßnahmen können kombiniert werden.
Die Kommunikation erfolgt über virtuelle Netzwerkadapter. Sie erhalten IPv4-Adressen aus dem Bereich 5.0.0.0/8. Diese IP-Adressen gehören offiziell zum öffentlichen IPv4-Adressraum, sind aber bisher von der IANA nicht vergeben. Die Wahl dieses Adressraums stellt sicher, dass es keine Adresskonflikte mit privaten Adressen aus dem Bereich 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16 gibt. Wenn die IANA diesen Bereich irgendwann vergibt, muss sich LogMeIn allerdings etwas einfallen lassen.
Bildergalerie
So nutzt man die neuen Funktionen von Hamachi²[6]
» zur Bildergalerie ...[6]Wer seinen Hamachi-Client auf Hamachi² aufrüstet, wird unmittelbar feststellen, dass die Verbindung zu Rechnern unter Linux und Mac OS zunächst aufgebaut wird. Bereits nach etwa 30 Sekunden erscheint hinter dem Rechnernamen ein gelbes Dreieck, siehe Bild 2[9]. Kurze Zeit später ist die Verbindung vollends verschwunden, siehe Bild 3[10].
ZDNet konnte feststellen, dass das Default-keep-alive-Intervall der Unix-Versionen mit 90 Sekunden für Hamachi² zu hoch ist. Um das Problem zu beseitigen, kann man diesen Wert auf das Minimum von 10 Sekunden setzen. Dazu loggt man sich unter Linux als root ein. Mac-OS-Benutzer öffnen ein Terminal und verschaffen sich die nötigen Rechte mit sudo -s.
Im Hamachi-Konfigurationsverzeichnis, in der Regel ~/.hamachi oder ~root/.hamachi, muss die Datei config editiert oder angelegt werden. Dort trägt man die Zeile KeepAlive 10 ein, siehe Bild 4[11]. Nach einem Neustart von Hamachi oder einem Reboot des Rechners funktioniert Hamachi für Unix auch mit Hamachi² für Windows. Im Community-Forum[12] von LogMeIn ist eine Hamachi²-Version für Unix erst für einen späteren Zeitpunkt angekündigt.
Eine der wesentlichen Neurungen in Hamachi² ist die neue Web-Konfigurationsoberfläche[13], mit der sich Netze und Rechner administrieren lassen. Wenn man über diese Oberfläche Netzwerke anlegt, lassen sich zwei neue Hamachi-Topologien anlegen: Hub and Spoke und Gateway. Die aus Hamachi 1.0.x bekannte Topologie, dass sich alle Nutzer eines Netzwerks sehen, nennt sich nun Mesh.
Ein Hub-and-Spoke-Netzwerk ist einem Mesh-Netzwerk recht ähnlich. Über das Webinterface bestimmt der Netzwerk-Owner, welche Rechner Hub beziehungsweise Spoke sind, siehe Bild 5[14]. Die Hubs sind für alle Teilnehmer erreichbar. Die Spokes sehen sich jedoch untereinander nicht, siehe Bild 6[15]. Das ermöglicht in einer geschlossenen Benutzergruppe, einen oder mehrere Server freizugeben, während sich die Client-Rechner untereinander nicht sehen.
Ungewohnt ist bei allen Netzwerken, die über das Webinterface angelegt werden, dass LogMeIn die Netzwerk-ID automatisch generiert. Ein Mesh-Netzwerk, dass über den Hamachi-Client angelegt wird, kann man einen leicht zu merkenden Namen wie "Horsts Arbeitsgruppe" geben. Dieser Name ist gleichzeitig die Netzwerk-ID. In Bild 5[14] ist zu sehen, dass die Netzwerk-ID "031-292-571" lautet. Der Name "zdnet-labs" ist lediglich ein Kommentar.
Wer versucht, einem Netz unter diesem Namen beizutreten, erhält eine Fehlermeldung, siehe Bild 7[16]. Da die Merkfähigkeit des menschlichen Gehirns für Ziffernfolgen wie "031-292-571" sehr begrenzt ist, kann man nur feststellen, dass LogMeIn das hätte besser lösen können.
Die größte Neuerung stellen die Gateway-Netze dar. Sie erlauben ein echtes Site-to-End-VPN, sprich die Einwahl von einzelnen Rechnern in ein privates Intranet. Wer in einem Heim- oder kleinen Firmennetz mehrere Rechner betreibt, kann einen dieser Rechner als Gateway deklarieren. Alle anderen Teilnehmer des Hamachi-Netzes bekommen automatisch Zugriff auf das gesamte Intranet.
Das hört sich auf den ersten Blick gut an, zumal von den 16 Rechnern, die sich in einem kostenlosen Hamachi-Netzwerk tummeln dürfen, nur einer, nämlich der Gateway-Rechner gezählt wird. Aber ein Gateway-Netzwerk hat durchaus seine Tücken.
Gateway-Netze sind vielen Beschränkungen unterworfen. Die größte dürfte darin liegen, dass es Hamachi-1.0.x-Clients nicht möglich ist, einem Gateway-Netz beizutreten. Es gibt daher derzeit keine Möglichkeit, Unix-Clients mit Linux oder Mac OS in ein solches Netz zu nehmen, siehe Bild 8[17].
Eine weitere Beschränkung liegt darin, dass ein Rechner mit einem Client-Betriebssystem wie Windows 7, Vista oder XP nicht als Gateway dienen kann, wenn er Mitglied einer Active-Directory-Domäne ist. Das soll verhindern, dass Mitarbeiter ihren Arbeitsplatzrechner als Hintertür ins Firmennetz freigeben. Setzt jemand in einem Firmennetz einen Rechner ohne Domänenmitgliedschaft auf, kann er sich und anderen leicht eine Hintertür schaffen.
Ferner darf das Gateway nur Mitglied des Gateway-Netzes sein. Eine Mitgliedschaft in weiteren Hamachi Netzwerken ist nicht möglich. Außerdem darf es pro Hamachi-Netzwerk nur ein Gateway geben. Damit eignen sich nur Rechner, die ständig eingeschaltet sind, etwa ein Firmen- oder Homeserver. Fällt das Gateway aus, so lässt sich über das Webinterface ein neues Gateway bestimmen.
Die übrigen Rechner eines Gateway-Netzes dürfen auch in anderen Hamachi-Netzen Mitglied sein. Nicht möglich ist es hingegen, dass ein Rechner gleichzeitig in zwei Gateway-Netzen aktiv ist. Man kann sich mit einem Laptop von unterwegs nicht gleichzeitig zuhause und ins Firmennetz wählen.
Ein Gateway-Rechner bekommt von Hamachi eine Netzwerkbrücke eingerichtet. Zu dieser Bridge fügt Hamachi alle verbundenen lokalen physikalischen Adapter sowie einen virtuellen Hamachi-Adapter hinzu, siehe Bild 9[18]. Dabei ist zu beachten, dass Windows die Netzwerkbrücke als einen logischen Netzwerkadapter mit einer eigenen Mac-Adresse betrachtet.
Konkret bedeutet das, dass ein Rechner in dem Moment, in dem er Gateway wird, eine neue IP-Adresse in seinem lokalen Netz bekommt, sofern sie dynamisch per DHCP zugewiesen wird. Hatte der Gateway-Rechner eine statische IP-Adresse, so muss diese von Hand in der Netzwerkbrücke eingetragen werden.
Normalerweise konfiguriert sich der Gateway-Rechner automatisch. Wenn er dem Nutzer Zugang zu einem geroutetem Intranet verschafft, muss jedoch von Hand nachgeholfen werden, etwa wenn das Gateway in einem 10.x.y.z/24-Netz steht und weitere 10.x.y.z/24-Netze im Intranet verfügbar sind. Das geht nur lokal am Gateway, siehe Bilder 10 bis 12[19].
Im gezeigten Beispiel steht der Gateway-Rechner in einem Intranet mit dem Subnetz 192.168.0.0/24. Da der DSL-Router in diesem Netz DHCP anbietet, lässt man den Reiter "IP Parameters" auf "Obtain Settings automatically".
Bild 13[20] zeigt den Hamachi-Client des Gateway-Rechners. Man erkennt, dass sich zwei Rechner im Netzwerk ZDNetLabs-Gate eingewählt haben. Aus Sicht der Clients funktioniert das genauso einfach wie mit jedem anderen Hamachi-Netzwerk auch. Sie erhalten wie jeder andere Rechner, der mit diesem Intranet physisch verbunden ist, eine IP-Adresse vom DHCP-Server aus dem Bereich 192.168.0.0/24.
Hamachi versucht Intranet-Adresskonflikte zu lösen
Ein Rechner, der sich in dieses Gateway-Netz einwählt, hat aber möglicherweise ein Problem: Nämlich genau dann, wenn er sich ebenfalls in einem privaten Netzwerk mit dem Adressraum 192.168.0.0/24 befindet. Dann kommt es zu einem Adresskonflikt. Dieses Problem löst Hamachi durchaus kreativ mit einem 1:1-DNAT[21]. Dabei übersetzt Hamachi für den Client alle IP-Adressen des Gateway-Netzes durch einen anderen Adressraum, der nicht mit dem eigenen Netz des Clients in Konflikt steht.
Bild 14[22] zeigt, dass das Gateway-Netz für den Client-Computer auf das virtuelle Netz 10.8.0.0/24 abgebildet wird. Will der Client im Gateway-Netz den DSL-Router 192.168.0.1 erreichen, muss er stattdessen die IP-Adresse 10.8.0.1 benutzen. Wenn kein Adresskonflikt vorliegt, dann benutzt Hamachi die echten Adressen ohne 1:1-DNAT.
LogMeIn hat beim DNAT auch an höhere Protokollebenen gedacht. Wenn im Gateway-Netz ein eigener DNS-Server installiert ist, übersetzt Hamachi auch die DNS-Antworten, siehe Bild 15[23]. Trotzdem sollte man Adresskonflikte vermeiden. Bekommt man eine IP-Adresse aus dem Gateway-Netz über ein proprietäres Protokoll, dann kann Hamachi das nicht übersetzen. Wer sich etwa dauerhaft von zuhause in sein Firmennetz einwählen möchte und einen Adresskonflikt hat, sollte das Subnetz zuhause ändern, um nicht plötzlich vor Problemen zu stehen.
Mit Hamachi² ist LogMeIn kein großer technischer Sprung nach vorn geglückt. Die Funktionalität von Hub-and-Spoke-Netzwerken ließ sich bisher durch das Blocken einzelner Nutzer in einem Netzwerk erreichen.
Gateway-Netzwerke sind keineswegs so problemlos aufzusetzen, wie es Hamachi-Nutzer gewohnt sind. Ferner gibt es zahlreiche Beschränkungen. Gateway-Netze sind ein Feature, dass viele Anwender sicherlich nutzen würden, jedoch ist die technische Umsetzung nicht gut gelungen. Eine Routing-Lösung mit optionalem Proxy-ARP wäre dem Anspruch, ein konfigurationsfreies "Rundum-Sorglos-VPNs" zu liefern, gerechter geworden.
Man muss sich fragen, ob die Tunnellösung von Hamachi [24]zur Verbindung mehrerer Intranets oder einzelner Nutzer mit mehreren Intranets sinnvoller ist. Sie erfordert zwar gute Kenntnisse über IP-Routing und viel Konfigurationsaufwand, ist aber frei von Beschränkungen. Ferner ist keine Netzwerkbrücke notwendig, die mit Nachteilen verbunden ist.
Wer Hamachi für Linux oder Mac OS nutzt, muss erst Kompatibilitätsprobleme lösen, bevor Unix-Rechner mit Hamachi²-Clients reden können. Die Herabsetzung des Keep-alive-Intervalls auf 10 Sekunden schafft zwar Abhilfe, führt aber zu mehr Netzwerktraffic, der eigentlich vermeidbar wäre. Diese Lösung ist nur ein temporärer Workaround.
Wer aus Gateway-Netzen keinen Nutzen ziehen kann oder sie gerne nutzen würde, jedoch von den zahlreichen Beschränkungen betroffen ist, die einen Einsatz verhindert, sollte bei Hamachi 1.0.3.0[25] bleiben. Dann entfallen die Kompatibilitätsprobleme mit den Unix-Versionen. Zudem kommt Hamachi 1.0.x mit deutlich weniger Speicher aus.
URLs in diesem Artikel:
[1] = http:/
[2] = http:/
[3] = http:/
[4] = http:/
[5] = http:/
[6] = http:/
[7] = http:/
[8] = http:/
[9] = http:/
[10] = http:/
[11] = http:/
[12] = http:/
[13] = http:/
[14] = http:/
[15] = http:/
[16] = http:/
[17] = http:/
[18] = http:/
[19] = http:/
[20] = http:/
[21] = http:/
[22] = http:/
[23] = http:/
[24] = http:/
[25] = http:/