Tailscale VPN auf Access Gate konfigurieren

Schritt-für-Schritt-Anleitung zur Konfiguration des integrierten Tailscale VPN-Clients auf Access Gate. Richten Sie das Tailnet, den OAuth API-Zugang, IP-Bereiche, die automatische Routengenehmigung und die Asset-Synchronisierung zwischen Access Gate und Tailscale ein.

Access Gate wird mit einem integrierten Tailscale-Client ausgeliefert. Dies ist die dokumentierte Integration zum Verbinden von Access Gate mit einem Tailscale-Tailnet, sodass Remote-Benutzer, Remote-Standorte und Access Gate selbst ein sicheres Mesh-Overlay ohne Firewall-Änderungen oder Neuverkabelung nutzen.

Diese Anleitung beschreibt die vollständige Tailscale-Einrichtung auf Access Gate: Tailnet erstellen, IP-Pool konfigurieren, OAuth-API-Zugriff einrichten, damit Access Gate den Tailnet-Status lesen kann, Assets und Benutzer zurück zu Access Gate synchronisieren und Enclave-Zugriff über das Overlay gewähren.

Tailscale-Tailnet einrichten

Falls Sie noch kein Tailscale-Konto besitzen, gehen Sie zu tailscale.com, um eines zu erstellen. Das integrierte Menü führt Sie durch die Schritte zur Kontoerstellung. Sie können den Vorgang beenden, sobald der Bildschirm zur Geräteverbindung auffordert.

Tailnet-IP-Adressbereich(e) einrichten

Jede mit dem Tailnet verbundene Maschine erhält eine IP-Adresse. Um den Adresspool zu steuern, aus dem diese Adressen vergeben werden, fügen Sie der Access-Controls-Konfigurationsdatei Folgendes hinzu:

"nodeAttrs": [
  { "target": ["*"], "ipPool": ["100.100.0.0/16"] }
]

und klicken Sie auf Save, um die Einstellungen zu speichern und anzuwenden. Optional können Sie verschiedene Pools für unterschiedliche Benutzergruppen festlegen:

"nodeAttrs": [
  { "target": ["autogroup:member"], "ipPool": ["100.100.1.0/24"] },
  { "target": ["autogroup:admin"], "ipPool": ["100.100.2.0/24"] }
]

Um die IP-Adresse einer bereits verbundenen Maschine zu ändern, gehen Sie zu Machines section -> machine options (drei Punkte rechts neben der Maschinenzeile) -> Edit machine IPv4, geben Sie eine verfügbare IP aus dem gewünschten Bereich ein und klicken Sie auf Update IP.

In der Benutzeroberfläche erreichen Sie dies über Access Controls > Node Attributes.

Automatische Genehmigung für neu verbundene Maschinen einrichten

Standardmäßig wird jede neu hinzugefügte Maschine automatisch zur Teilnahme am Tailnet genehmigt. Es ist optional (und sicherer), diese Richtlinie zu ändern und für jede neue Maschine eine manuelle Genehmigung zu verlangen. Um dies zu aktivieren, gehen Sie zu Settings -> Device management und setzen Sie Device Approval auf On.

Danach erscheint jede neue Maschine, die dem Tailnet hinzugefügt wird, im Bereich Machines mit der Bezeichnung „Needs approval" und muss manuell genehmigt werden, indem Sie auf die Maschinenoptionen (drei Punkte rechts) klicken und Approve auswählen. In der Benutzeroberfläche erreichen Sie dies über Access Controls > Auto approvers.

Automatische Genehmigung für beworbene (geteilte) Routen einrichten

Wenn eine neu verbundene Maschine Routen bewirbt (teilt), die über das Tailnet zugänglich gemacht werden sollen, müssen diese Subnetze unter Machines section -> machine options (drei Punkte rechts) -> Edit route genehmigt werden, indem das Kontrollkästchen neben den jeweiligen Subnetzen aktiviert wird.

Der Subnetz-Genehmigungsprozess kann automatisiert werden, indem in der Access-Controls-Konfigurationsdatei eine automatische Genehmigung für bestimmte Benutzer und Subnetze konfiguriert wird:

"autoApprovers": {
  "routes": {
    "100.64.0.0/24": ["autogroup:member"],
    "100.64.0.0/10": ["autogroup:admin"]
  }
}

Ablauf des Maschinenschlüssels einrichten

Jede mit dem Tailnet verbundene Maschine erhält einen Schlüssel, der standardmäßig 180 Tage gültig ist. Danach läuft der Schlüssel ab und die Maschine muss erneut authentifiziert werden.

Der Schlüsselablauf kann pro Maschine für vertrauenswürdige Maschinen (einschließlich AccessGate) im Bereich Machines deaktiviert werden, indem Sie auf machine options (drei Punkte rechts) -> Disable key expiry klicken.

OAuth-API-Zugriff auf die Tailnet-Konfiguration einrichten

Damit Access Gate den Tailnet-Status (Geräte, Benutzer, DNS und Routen) lesen und Assets sowie Zugriff synchron halten kann, muss ein API-Zugriff konfiguriert und die erhaltene ID sowie das Secret in die Access Gate-Konfiguration eingetragen werden.

Um den OAuth-API-Zugriff auf das Tailnet zu aktivieren, gehen Sie in Tailscale wie folgt vor:

Gehen Sie in Tailscale zu Settings -> Trust Credentials -> OAuth clients
Geben Sie eine Beschreibung ein (z. B. AccessGate API client)
Erteilen Sie die folgenden Berechtigungen:
- DNS: Read and Write
- Policy File: Read
- Users: Read
- Services: Read
- Devices (Core): Read
- Posture Attributes: Read
- Routes: Read and Write
Klicken Sie auf Generate credential

Kopieren und speichern Sie die angezeigten OAuth-Client-Zugangsdaten (ID und Secret) sicher und tragen Sie diese in Access Gate über die Access Gate-Webverwaltung -> Settings -> Networking -> VPN Access -> API Credentials ein.

Ab v26.6 können Sie diese API-Zugangsdaten jederzeit über denselben Bildschirm aktualisieren oder ersetzen. Dies ist nützlich, wenn Sie den OAuth-Client rotieren oder die Integration neu konfigurieren müssen, ohne sie vollständig neu aufzubauen.

Assets und Benutzer aus Tailscale synchronisieren

Klicken Sie in Access Gate auf Authenticate.

Nach einer erfolgreichen Verbindung wird der folgende Bildschirm angezeigt.

Aktualisieren Sie auf der Tailscale-Seite Ihren Access Controls-Tab, um Mitgliedern (oder einer anderen Quelle Ihrer Wahl) Zugriff auf das vom Access Gate beworbene und geroutete Subnetz zu gewähren:

Beispiel:

// access Access Gate LAN
{
  "src": ["autogroup:member"],
  "dst": ["100.64.144.0/24"],
  "ip":  ["*"],
},

Lokale Assets aufrufen

Sie können nun zu Enclaves wechseln und den gewünschten Assets und Benutzern Zugriff gewähren. Um auf diese zuzugreifen, verwenden Sie einfach die im Tab Assets angezeigte IP oder URL. Die Magie geschieht im Hintergrund :)

Namen im Tailnet auflösen (DNS)

Ab v26.6 funktioniert die DNS-Auflösung in beide Richtungen: Eine Maschine im Tailnet kann Assets hinter Access Gate auflösen, und lokale Assets können Tailnet-Hosts auflösen. Um lokale Hostnamen von einem Tailscale-Client aufzulösen, fügen Sie Access Gate als Nameserver für die relevanten Domains in Tailscale unter DNS > Nameservers hinzu (Split DNS: Beschränken Sie es auf die Domains, die Access Gate bedient, damit der Rest Ihres DNS unberührt bleibt).

Routing: lokale Subnetze erreichen

Tailscale-Clients erreichen Assets in einem lokalen Netzwerk über die oben beschriebenen beworbenen Routen (siehe Automatische Genehmigung für beworbene (geteilte) Routen einrichten). Access Gate bewirbt seine lokalen Subnetze gegenüber dem Tailnet; sobald diese Routen genehmigt sind, erreichen Tailnet-Clients lokale Assets per IP oder Hostname. Welche Benutzer auf welche Assets zugreifen können, wird weiterhin pro Enclave durch Identität und ACL gesteuert. Dieses Zugriffsmodell wird unter Remote Zero Trust Access beschrieben, das auf diesem Overlay aufbaut. Für die meisten Deployments ist dieser routenbasierte Ansatz dem Konfigurieren von Access Gate als Tailscale-Exit-Node vorzuziehen, da Letzteres den gesamten Client-Datenverkehr darüber leiten würde.

Reverse-Path-Drop

Symptom, Ursache und Lösung

Symptom. Ein über Access Gate beworbenes Gerät (z. B. 100.64.144.50) ist über Tailscale nicht erreichbar: nc oder curl laufen in einen Timeout. Ein tcpdump auf der Gateway-Seite zeigt ausgehende SYNs ohne Antworten. Am Beispiel einer FortiGate-Firewall zeigt der Flow-Trace den Drop:

received a packet(proto=1, 100.127.0.34->172.31.144.50) from Trout Connect
func=ip_route_input_slow  msg="reverse path check fail, drop"
func=ip_session_handle_no_dst

Ursache. Pakete erreichen die FortiGate mit der rohen Tailscale-Quell-IP des Clients (100.127.0.0/24, innerhalb von 100.64.0.0/10). Access Gate führt Destination-NAT durch (100.64.144.0/24 auf 172.31.144.0/24), aber kein Source-NAT, sodass die FortiGate keine Rückroute zum Tailscale-Bereich hat. Die strikte Reverse-Path-Forwarding-(Anti-Spoof-)Prüfung verwirft das Paket dann, bevor es das OT-Gerät erreicht. Das Gerät selbst ist funktionsfähig: Es kommt nichts bei ihm an.

Dies liegt am Ende der Zugriffskette; schließen Sie daher zuerst die vorgelagerten Schichten aus. Alle vier müssen in Ordnung sein:

Tailscale-ACL-Freigabe. Eine Freigabe muss das Subnetz-CIDR als dst auflisten. Routen-Genehmigung (autoApprovers) ist von Routen-Zugriff (Freigaben) getrennt: Genehmigung allein verteilt die Route nicht an Clients.
Route in der Client-Netmap. Führen Sie tailscale status --json aus; die AllowedIPs des Gateways müssen das Subnetz enthalten.
Tunnel zum Gateway. tailscale ping <target> liefert einen Pong zurück.
FortiGate-Rückpfad. Der hier beschriebene Fehler.

Lösung (Identität bleibt erhalten). Geben Sie dem Router eine Rückroute zu Tailscale und eine passende Richtlinie, damit identitätsbasierte OT-Regeln weiterhin funktionieren. Beispiel auf einer FortiGate-Appliance:

config router static
  edit 0
    set dst 100.64.0.0 255.192.0.0
    set gateway <Access Gate 'Trout Connect' IP>
    set device "<Trout Connect interface>"
  next
end

Fügen Sie dann eine Firewall-Richtlinie von Trout Connect zu OT hinzu, mit Quelle 100.64.0.0/10 und dem Zielgerät als Ziel. Mit vorhandener Route besteht die strikte RPF-Prüfung, sodass strict-src-check nicht deaktiviert werden muss.

Zusammenfassung

Access Gate wurde mit einem Tailscale-Tailnet verbunden: Tailnet und IP-Pool erstellt, OAuth-API-Zugriff eingerichtet, Assets und Benutzer zurück zu Access Gate synchronisiert, bidirektionales DNS aktiviert und lokale Subnetze über genehmigte Routen erreicht. Nutzen Sie dies, um Remote-Benutzern und Remote-Standorten ein sicheres Mesh-Overlay zu lokalen Assets bereitzustellen – ohne Firewall-Änderungen, Neuverkabelung oder einen Tailscale-Exit-Node.