Remote Development, reale Infrastruktur – Wie Tailscale uns das Testen im GIN-Netz ermöglichte


Moderne Softwareentwicklung steht oft zwischen zwei Welten: Einerseits entwickeln wir Anwendungen remote, flexibel, agil – andererseits müssen wir mit lokaler, regulierter Infrastruktur interagieren, die genau das Gegenteil davon ist.
Genau in diesem Spannungsfeld befanden wir uns kürzlich bei einem Kundenprojekt für die Medcom GmbH. Das Unternehmen betreibt eine Laboranforderungssoftware, für die wir eine Schnittstelle zur österreichischen e-card Infrastruktur realisiert haben. Technisch bedeutet das: Wir müssen aus der Software heraus Patienten- und Versicherungsdaten über das Gesundheitsinformationsnetz (GIN) abfragen – ein komplett abgeschottetes Netz mit eigener Hardware, IP-Range und strikten Zugriffsregeln.
Das Setup war klassisch lokal:
- LAN-Subnetz
192.168.100.0/24
- Ein GIN-Router mit IP
192.168.100.210
- Ein GINO-Kartenlesegerät mit IP
192.168.100.10
- Alles physisch installiert am Standort von Medcom
Und ganz wichtig: Jeder Standort eines Vertragspartners – ob Arztpraxis, Labor oder Softwarehersteller – benötigt physisch vorhandene, zertifizierte Hardware für eine direkte Verbindung ins GIN-Netz.
Für die Anwendung selbst war die Integration der e-card Schnittstelle kein Hexenwerk – dafür gibt es OpenAPI- und SOAP-Standards. Die eigentliche Herausforderung begann mit dem Testen. Denn wie testen unsere Entwickler die Integration, wenn sie nicht vor Ort sind – und nicht direkt auf die e-card Infrastruktur zugreifen können?
Kein VPN? Kein Problem.
Ein klassisches VPN? Wäre naheliegend, aber unpraktisch: Wir haben keinen Zugriff auf die Medcom-Netzwerkhardware für das Einrichten von Portweiterleitungen – Änderungen bedeuten Aufwand beim externen IT-Dienstleister. Eine einfache Lösung musste her, ohne Eingriffe in die Infrastruktur.
Unsere Lösung: Tailscale.
Tailscale nutzt das WireGuard-Protokoll, um ein sicheres, leichtgewichtiges Peer-to-Peer-VPN zwischen Geräten aufzubauen. Kein kompliziertes Setup, kein Port-Forwarding, kein Frickeln mit Zertifikaten. Wir konnten zwei Systeme in völlig verschiedenen Netzwerken verbinden – über das Internet, aber so, als wären sie im selben LAN. Tailscale ist mehr als nur „noch ein VPN“. Es ist ein modernes, sicheres Mesh-Netzwerk:
- Zero Config VPN – kein Portforwarding, keine statischen IPs, keine NAT-Probleme
- Ende-zu-Ende verschlüsselt via WireGuard
- SSO-Integration – Anmeldung via Google, Microsoft, GitHub etc.
- Automatische Peer-to-Peer-Verbindungen - für eine bessere Performance mit weniger Latenz und mehr Durchsatz
- ACLs, Tags und Zugriffssteuerung direkt über das Admin-Panel
- Kein zentraler VPN-Server nötig – jeder Client kann Relay oder Exit Node sein
- GitOps & Automatisierung mit Pulumi, Terraform, GitHub Actions, Bitbucket usw.
- Tailscale SSH - Automatisierte Zugriffskontrolle für SSH-Verbindungen im Tailnet
- Kubernetes Operator - Tailscale kann auch in Kubernetes betrieben werden, um den Zugriff auf private Services zu managen
Konkret:
- Auf einem Windows-Rechner im Medcom-Netz installierten wir einen Tailscale-Client.
- Dieser wurde zur Relay-Node für das Netzwerk (
192.168.100.0/24
). - Die Zielroute (
84.38.112.0/24
- e-card Testinstanz) wurde via GIN-Router192.168.100.210
geroutet. - Unsere Entwickler konnten von zu Hause aus ganz einfach auf die Testinstanz der e-card Schnittstelle zugreifen – sicher, performant, nachvollziehbar.
Komplexe Netze, einfache Lösungen
Gerade im medizinischen Umfeld stoßen moderne Entwicklungspraktiken oft auf starre Infrastrukturen. Anstatt Prozesse auf den Kopf zu stellen, setzen wir auf Tools, die sich elegant in bestehende Strukturen einfügen – wie Tailscale. Damit können unsere Entwickler effizient arbeiten, ohne dass der Kunde seine Umgebung aufwändig umbauen muss.
Pragmatisch denken, smart lösen – das ist unser Ansatz bei agsolutions.
🔧 Tailscale in 5 Schritten einrichten – So einfach geht’s
Ziel: Ein Entwickler soll aus der Ferne (z.B. Homeoffice) auf ein internes Netz zugreifen können.
🧩 Was benötigt wird
- Einen Rechner im Zielnetzwerk (z. B. Windows, Linux, macOS).
- Einen oder mehrere Clients, z. B. die Notebooks der Entwickler.
- Administrator-Zugriff auf die Geräte.
- Einen kostenlosen Tailscale-Account.
✅ Schritt 1: Tailscale auf beiden Seiten installieren
Im Ziel-Netzwerk (Relay-Node)
Tailscale-Client installieren:
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --advertise-routes=192.168.100.0/24
⚠️
--advertise-routes
erlaubt es, IPs bzw. ganze IP-Ranges im Tailnet erreichbar zu machen, ohne auf jedem Host einen Tailscale-Client installieren zu müssen (z. B. am GIN-Router192.168.100.210
).
Auf dem Entwickler-Laptop
Wird ebenfalls Tailscale installiert, der User eingeloggt und der Dienst gestartet:
sudo tailscale up
Oder einfach per GUI auf macOS/Windows.
✅ Schritt 2: Geräte im Tailscale Admin Panel freigeben
https://login.tailscale.com/admin
- Unter Machines → [Relay-Gerät] den Button „Enable exit node / subnet routing“ aktivieren
- Route
192.168.100.0/24
explizit genehmigen
✅ Schritt 3: Verbindung testen
Jetzt kann eine Verbindung zur internen IP 192.168.100.210
oder 84.38.112.X
getestet werden – z. B. per Ping
oder direktem Aufruf im Browser zur Testinstanz der e-card Test-Oberfläche.
ping 192.168.100.210
🎉 Fertig!
Tailscale ist damit aktiv, Subnet-Routing funktioniert, und das Team kann so arbeiten, als wäre er direkt vor Ort. Keine VPN-Gateways, kein Frickeln mit OpenVPN oder Zertifikaten – und das Ganze dauert keine 15 Minuten.