VPN ohne Grenzen: Per Tunnel durch die Firewall

Alle Rechner erhalten eine IP-Adresse aus dem Subnetz 5.0.0.0/8. Diese Adressen sind keine offiziellen privaten IP-Adressen. Sie sind von der IANA allerdings zur Zeit nicht vergeben. Dadurch wird verhindert, dass ein Konflikt mit selbst genutzten privaten IP-Adressen auftritt.

Der Vermittlungsdienst macht es möglich, dass sich beliebige Rechner zu einem VPN über Firmen- und Netzwerkgrenzen hinweg zusammenschließen lassen, auch wenn sie sich hinter einem NAT-Router oder einer Firewall befinden. Dabei wird keineswegs der gesamte Datenverkehr über den Hamachi-Server geleitet.

Der Dienst vermittelt, wann immer möglich, tatsächlich nur eine direkte Verbindung zwischen gegenseitig erreichbaren IP-Adressen. In der Regel ist das die öffentliche IP-Adresse des Routers, siehe Bild 2. Die mit 256-Bit-AES-Verschlüsselung geschützten Daten werden auf dem direkten Weg versandt.

Als Protokoll wird normalerweise UDP verwendet. Daraus ergibt sich der konkrete Vorteil, dass typische Consumer-Internet-Router, beispielsweise eine Fritz-Box, nur geringer CPU-Last ausgesetzt werden. Im Falle von TCP könnte es zu Performanceproblemen kommen, wenn viele Hamachi-Clients hinter einem Router stehen.

Damit die einzelnen Teilnehmer per UDP kommunizieren können, bietet der Hamachi-Vermittlungsserver einen Dienst, der einem STUN-Server ähnelt, wie er oft bei VoIP-Verbindungen verwendet wird. Der ZDNet-Test mit fünf verschiedenen Netzen zeigt, dass die UDP-Vermittlung einwandfrei funktioniert. Auch Router, die aus Sicherheitsgründen kein UPnP oder NAT-PMP unterstützen, etwa von Lancom Systems, lassen alle Pakete ohne Konfigurationsänderungen an der NAT-Tabelle durch. Typische VoIP-Probleme, die sich zum Beispiel durch One-Way-Audio bemerkbar machen, treten nicht auf.

Doch der Hamachi-Dienst kann noch mehr: Befinden sich zwei Hamachi-Teilnehmer im selben physikalischen LAN, so erkennt der Dienst auch das, und die Kommunikation erfolgt, ohne dass Pakete über die in der Regel langsamere Internet-Verbindung geroutet werden, siehe Bild 3. Bild 4 zeigt, dass die Geschwindigkeit in diesem Fall nur geringfügig unter einer echten LAN-Verbindung liegt.

Falls UDP von der Firewall komplett geblockt wird, kann auch TCP verwendet werden. Zur Not reicht eine Verbindung über einen HTTP-Proxy-Server, siehe Bild 5. Scheitert eine direkte Verbindung zwischen zwei Teilnehmern, werden alle Pakete über den Hamachi-Server geroutet, was allerdings eine große Geschwindigkeitsbuße bedeutet. Im ZDNet-Test ist in keinem Fall ein Fallback auf TCP oder gar einen Proxy-Server erforderlich.