Ein Virtual Private Network (VPN) ist hinsichtlich seiner ureigensten Eigenschaft eine Möglichkeit, eine sichere und verschlüsselte Verbindung über ein weniger sicheres Netzwerk – typischerweise das Internet – herzustellen. Twingate hebt in seiner Eigendarstellung deutlich hervor, dass es sich gerade nicht um ein VPN handelt. Und bei genauer Betrachtung unterscheiden sich Twingate und traditionelle VPNs an einigen Punkten. So basiert Twingate auf dem Zero-Trust-Netzwerkmodell, bei dem jeder Zugriff individuell überprüft wird. Traditionelle VPNs indes gewähren oft Zugang zu einem gesamten Netzwerk, sobald eine Verbindung hergestellt ist. Mit Twingate kann der Administrator außerdem Zugriffe auf spezifische Anwendungen oder Ressourcen einschränken.

Twingate bietet, zumindest in der Theorie, auch eine bessere Performance, da es den Datenverkehr direkt zwischen dem Benutzer und der Ressource leitet, ohne über zentrale VPN-Server zu gehen, die oft Engpässe verursachen können. Der Dienst ist gleichzeitig einfacher zu verwalten und zu skalieren, da er keine komplexe Infrastruktur wie VPN-Server erfordert. Er lässt sich laut Anbieter leicht in bestehende Systeme integrieren. Auf der anderen Seite steht eine benutzerfreundlichere Erfahrung, da keine spezielle Softwareinstallation oder Konfiguration auf den Endgeräten erforderlich ist, was Benutzern das Leben wiederum erleichtert.

Um den Unterschied zwischen VPN und Twingate technisch nachzuvollziehen, ist ein Blick auf die Anatomie der Systeme erforderlich. In einer klassischen VPN-Umgebung ist eine statische IP-Adresse beziehungsweise ein DNS-Hilfskonstrukt erforderlich, damit der Client sein Ziel finden kann. DNAT/Port-Forwarding konfiguriert klassischerweise die Firewall so, dass sie den ein- und ausgehenden Verkehr auf den VPN-Server weiterleitet. Der externe Client wird dadurch zu einem Bestandteil des internen Netzwerks.

Twingate besteht strukturell aus mehreren Teilen. Eine wichtige Komponente in dem Konzept ist der Twingate Connector. Hierbei handelt es sich um eine kleine Software, die hinter der Firewall mit Zugriff auf die gewünschten internen Services zu positionieren ist. Anders jedoch als in klassischen VPN-Umgebungen ist es nicht nötig, hierzu spezielle Firewallregeln zu konfigurieren.

Ein weiterer Baustein ist der sogenannte "Twingate Controller", der sich außerhalb des Firmennetzwerks befindet. Dies ist ein vom Clouddienstleister bereitgestellter Service, mit dem sich der eigentliche Client, der von außerhalb auf interne Dienste zugreifen möchte, verbindet. Der Controller bildet so den statischen Anteil, den der Client im Internet findet. Der Controller liefert gleichzeitig die zentrale Administrationsoberfläche, führt die Benutzerauthentifizierung durch, registriert die Konnektoren und generiert die Zugriffskontrolllisten für Clients und Konnektoren.

Das Twingate Relay übernimmt eine weitere zentrale Rolle in der Architektur. Es dient dazu, eine sichere Verbindung zwischen Clients und Connector herzustellen, die für den Zugriff auf Ressourcen erforderlich ist. Diese Verbindung ist Ende-zu-Ende verschlüsselt und wird über einen zertifikatsgebundenen TLS-Tunnel aufgebaut. Der Anbieter betreibt weltweit ein Netzwerk von Relays und sorgt im Hintergrund selbstständig dafür, dass jeder Connector sich mit dem nächstgelegenen Relay verbindet, um die Latenz so gering wie möglich zu halten. Gleichzeitig sorgt das Vorhalten mehrerer Relays durch den Anbieter für eine höhere Betriebssicherheit. Fällt ein Relay aus, übernimmt automatisch ein anderes Relay dessen Aufgabe.

Eine Anpassung der eingehenden Firewallrichtlinien ist nicht erforderlich, da der Twingate-Connector von der Innenseite her die Verbindung initiiert. Letztendlich etabliert sich eine Peer-to-Peer-Connection zwischen dem Client und dem Twingate-Konnektor, der den Zugriff auf die gewünschte lokale Ressource, etwa einen Remote-Desktop-Server oder ein en internen Webdienst, bereitstellt. Steht diese UDP-artige Verbindung nicht zur Verfügung, da beispielsweise Netzwerk- oder Firewallregeln dies verhindern, bleibt noch die authentifizierte Verbindung über den Konnektor zum Controller, zum Client und zurück. Der Client selbst wird dabei weder bei Peer-to-Peer noch bei der Verbindung über den Controller zu einem Bestandteil des internen Netzwerks und kann folglich auch nicht auf andere Ressourcen zugreifen als die vom Admin bereitgestellten.

Twingate kommt als Software daher, somit steht einem recht einfachen und zügigen Test nicht viel im Weg. Über die Webseite des Herstellers kann sich der Interessent für eine eigene Betrachtung anmelden. Bereits wenige Augenblicke nach der Eingabe erhält der Administrator eine E-Mail mit der Anmeldung auf das Webinterface. Schon auf der Empfangsseite macht der Hersteller eine knackige Aussage: "It's time to ditch your VPN" – sprich, es wäre an der Zeit das VPN vor die Tür zu setzen.

Bei der Anmeldung verlässt sich Twingate auf die Authentifizierungs-Dienstleister Google, Microsoft, GitHub und LinkedIn. Ein Login mit einer klassischen Kombination von E-Mail-Adresse und Passwort sehen die Entwickler erst gar nicht vor. Für unsere Teststellung wählten wir unseren Microsoft-Account und meldeten uns erfolgreich an der Webseite an. Die Software begrüßte uns im Anschluss mit einem Assistenten, der über drei anstehende Schritte bei der Einrichtung behilflich ist. Zunächst gilt es, die erste Ressource einzurichten. Dies kann eine beliebige interne Netzwerkadresse sein in Form eines Endpunkts, eines Subnetzes oder einer ganzen Domäne. Aus den Hinweistexten ergibt sich, dass Admins später die Ressourcenerstellung mit Techniken wie Terraform oder Pulumi automatisieren oder auch erweiterte Konfigurationen wie DNS-Aliase und Port-Einschränkungen vornehmen können.

Das Dialogfenster erwartet nun entsprechend die Eingabe eines Subnetzes, einer Domäne oder einer IP-Adresse. In Abhängigkeit zur Auswahl verändert sich das Fenster und verlangt nach weiteren Details. In unserem Beispiel ging es uns darum, einen Windows-10-Client von außen über Twingate erreichbar zu machen. Bei der Auswahl von "An IP Address" benötigt Twingate noch die Informationen, ob es sich bei der IP-Adresse um einen Server, wie beispielsweise eine Windows- oder Linux-Maschine, eine private Webapplikation, eine Datenbank, ein NAS vom Typ Synology, QNAP & Co., um einen Dateiserver oder um einen Kubernetes-Cluster/Service handelt.

Im nächsten Schritt gilt es, die Deployment-Methode festzulegen. Hier zeigt sich Twingate wieder einmal überaus kontaktfreudig. Bei den skriptbasierten Deployments gibt es in der Auflistung Docker, Helm, AWS ECS, Azure, Linux, AWS AMI, Google Cloud, Terraform, Pulumi oder eine manuelle Bereitstellung. AWS-Benutzer können mit wenigen Klicks auch das "CloudFormation Template" nutzen. In einem YouTube-Videolink wird das Deployment mit Docker noch einmal kurz erklärt. Wer keine Lust auf ein Erklärvideo hat, findet alle erforderlichen Informationen auch in Textform: Der Connector muss lediglich das Recht haben, auf das Internet zuzugreifen, eine Inbound-Regel der Firewall ist nicht erforderlich. Sinnvollerweise muss der Connector die anvisierte interne Ressource netzwerkseitig erreichen und es empfiehlt sich, so der Infotext, eine geringe Anzahl von Hops zwischen Ressource und Connector zu bedenken.

Im nächsten Schritt erzeugt das Programm den Access-Token und den Refresh-Token und sollte, so ein zusätzlicher Hinweis, ausschließlich für diesen einen Connector zum Einsatz kommen. Bevor die Software die Tokens erzeugt, ist eine erneute Anmeldung erforderlich. Der Anbieter möchte wohl sicherstellen, dass keine "alte Websession" unerwünscht zum Einsatz kommt.

Der dritte Konfigurationsschritt erlaubt das Festlegen individueller DNS-Serverregeln und legt fest, ob der Connector optional auch für das interne Netz fungieren soll und ob die lokalen Verbindungen im Log zu protokollieren sind. Der vierte Konfigurationsschritt zeigt das generierte Docker-Kommando an, das auf dem Docker-Host-Server zur Ausführung zu bringen ist. In unserer Testumgebung handelte es sich hierbei um einen Windows-11-Rechner, auf dem wir Docker Desktop Personal in Version 4.36.0 installiert hatten. Die Ausführung des Befehls geschieht über die Kommandoeingabe und in gefühlter Echtzeit zeigt sich ein aktiver Container. In unserem Fall hieß dieser "twingate-funky-moose" in der Container-Auflistung von Docker und auch das Webinterface von Twingate zeigt an, dass die Verbindung wohl etabliert ist.

Im dritten und letzten Abschnitt des Einrichtungsassistenten steht der Download des Twingate-Clients an. Zur Auswahl stehen Windows, macOS, Linux, ChromeOS, iOS und Android. Je nach Auswahl öffnet sich ein Zusatzfenster, beispielsweise nach der Auswahl von iOS, da die Software für das iPhone und das iPad ausschließlich über den offiziellen Store von Apple zur Verfügung gestellt wird. Wir installierten im Rahmen dieses Tests die Windows-Version auf einem Windows-10-Laptop und nutzten die Variante für Apple iOS, um einen gesicherten Zugriff von außen auf eine Workstation im internen Netzwerk zur Verfügung zu stellen. Wichtig ist es dabei, stets den Namen des Netzwerks zu wissen – in unserem Fall "redaktionsgemeinscha.twingate.com".

Das Webinterface von Twingate ist insgesamt schlicht aufgebaut und wirkt nicht überfrachtet. Das obige Menü gliedert sich in die Arbeitsbereiche "Network", "Team", "Devices", "Policies", "Internet Security" und "Settings". Je nach Auswahl öffnet sich erwartungsgemäß ein weiterer Konfigurationsbereich mit den Details. Was uns im Test sehr gut gefiel: Neben dem "Setup Guide", der insgesamt gut formuliert die unterschiedlichen Bereiche abdeckt, gibt es auch den Bereich "Learn More About Twingate" als Schnellverlinkung zu Hilfetexten in den verschiedenen Konfigurationsbereichen. Ergänzend weist der Bereich "Next steps" auf weitere Arbeitsschritte hin, bis der Anwender mit "Dismiss" diese Infos abschaltet. An Hinweisen und Anleitungen mangelt es Twingate wahrlich nicht.

Unter "Network" legt der Admin die Remote-Netzwerke, Konnektoren und Ressourcen fest beziehungsweise passt diese an. Grafische Elemente wie die "Connection History" lockern das Gesamtbild informativ auf. Das Farbschema ist selbsterklärend: Rote Einträge weisen auf Fehler hin, eine Darstellung in grüner Farbe steht für erfolgreiche Verbindungen.

Im Abschnitt "Team" kann der Anwender weitere Benutzer per E-Mail für die Zusammenarbeit mit Twingate einladen. In der Auflistung ist ersichtlich, ob eine Einladung bereits angenommen wurde und wie viele Geräte der jeweilige Benutzer bereits mit Twingate genutzt hat. In der Standardauslieferung gibt es eine einzige Gruppe mit der Bezeichnung "Everyone". Durch das Anlegen weiterer Gruppen ist der Admin in der Lage, die Zugriffsrechte mit Gruppen zu organisieren, die wiederum verschiedene Ressourcen und Members (Benutzer) enthalten können. Das Schachteln von Gruppen ist jedoch nicht vorgesehen. Spannend indes ist die Funktion, eine Zusammenfassung in Form von CSV-Dateien herunterzuladen, die eine Dokumentation von Token, Geräten und Benutzern enthält.

Im Abschnitt "Devices" sind die Geräte zu finden, die bereits über Twingate mit dem eigenen Netzwerk in Kontakt geraten sind. Bei Bedarf lässt sich eine Verifikation der Seriennummer einrichten, die dafür sorgt, dass ein Austausch von Geräten erschwert ist. Je nach Konfiguration sind Betriebsvarianten möglich, bei denen unbekannte Geräte niemals Verbindungen eingehen können. Die Software liest einige Eckdaten der Geräte aus, beispielsweise den Antivirus- oder Firewallzustand, die OS-Version oder den Hostnamen. Während eines unserer iOS-Geräte zielsicher als "Apple" identifiziert wurde, erschien bei einem Dell-Laptop unter Windows der Hersteller nicht.

In den Einstellungen zu "Device Security" kann der Administrator "Trusted Profiles" aktivieren, bei der es Vorgaben gibt, ob beispielsweise die Firewall-Funktion eines Windows- oder Mac-Computers aktiviert sein muss, wenn eine Verbindung zulässig sein soll. Ein gezielter Ausschluss von Geräten, beispielsweise wenn Android-Systeme sich niemals verbinden dürfen, sind mit wenigen Mausklicks in den Policies realisierbar. Der Abschnitt "Internet Security" erlaubt die Aktivierung von verbindlichem Secure DNS und die Hinterlegung von Machine Key für die DNS-Sicherheit.

Wer bereits eine vollumfängliche und gut verwaltete VPN-Struktur hat, dürfte sich durch einen Blick auf Twingate nicht sofort überzeugen lassen. Vielmehr eröffnet Twingate eine spannende Alternative für besondere Einsatzgebiete, beispielsweise der schnelleren und einfacheren Bereitstellung von Verbindungen für Remotemitarbeiter. Besonders interessant erscheint Twingate im Zusammenspiel von verschiedenen Ressourcen, die sowohl in der Cloud als auch lokal vorgehalten werden. Twingate zeigte sich im Test flexibel, modern und überaus praktisch.

Schlussendlich stellt sich dem kritischen IT-Profi, der am liebsten alles selbst aufbaut und betreibt, die Frage, inwiefern es sinnvoll ist, sich bei einem Thema wie dem sicheren Fernzugriff auf einen in den USA beheimateten Clouddienstleister wie Twingate zu verlassen. Auf ihrer Homepage stellt sich die Firma äußerst transparent dar und zeigt detailliert auf, wie sie es mit Technik und Compliance hält. Sie versucht also zumindest, ein gewisses Vertrauen aufzubauen und der Blick in die Kundenreferenz reicht aus, um festzustellen, dass viele große und mitunter schnell wachsende Firmen auf Dienste von Twingate setzen.