Ich habe Cloudflare Zero Trust Tunnels erst jetzt verstanden

• Erläuterung einer Architektur, die mit Cloudflare Zero Trust und Warp private Netzwerke verbindet und den Zugriff auf Dienste steuert, ohne Probleme mit NAT oder Firewalls
• Über Argo Tunnels lassen sich private Netzwerke oder lokale Dienste unter einer öffentlichen Domain verfügbar machen, oder es lässt sich ein privates Netzwerk aufbauen, das nur bei bestehender Warp-Verbindung erreichbar ist
• Tailscale ist dank P2P schnell, hat aber in NAT-Umgebungen Einschränkungen; Cloudflare routet den gesamten Traffic über das Edge-Netzwerk und bietet dadurch eine stabile Verbindung
• Cloudflared übernimmt die Erstellung von Tunnels, der Warp Client den Netzwerkzugang und die Anwendung von Richtlinien; mit Tunnels, Routes und Targets werden Traffic-Fluss und Zugriffskontrolle konfiguriert
• Mit fein abgestuften Access Policies über E-Mail- oder GitHub-Login lässt sich eine sichere Netzwerkumgebung aufbauen, in der der Login je nach bestehender Warp-Verbindung übersprungen oder erzwungen wird

---

Überblick über Cloudflare Zero Trust und Warp

• Das Lernen von Cloudflare Zero Trust + Warp begann, nachdem das NAT-Traversal von Tailscale fehlgeschlagen war
• Über Zero Trust Tunnels lassen sich private Netzwerke verbinden, Dienste veröffentlichen, private IP-Netzwerke aufbauen und lokale Dienste vorübergehend öffentlich machen
• Sämtlicher Traffic wird ohne NAT-Probleme über das Cloudflare-Netzwerk geleitet, und mit granularen Access Policies lässt sich der Zugriff zwischen Nutzern, Bots und Servern steuern
• Für SSH-Zugriffe wird Zero-Trust-authentifizierter Login ohne öffentliche Ports unterstützt

Cloudflare Zero Trust vs. Tailscale

• Tailscale versucht, NAT und Firewalls zu umgehen, um eine P2P-Verbindung herzustellen, und verwendet andernfalls einen Relay-Server
• Bei Cloudflare wird sämtlicher Traffic außer Warp-to-Warp über Cloudflare-Edge-Server geleitet; dadurch gibt es keine NAT-Probleme, aber eine geringe zusätzliche Latenz

Unterschied zwischen Cloudflared und Warp

• Warp Client: Werkzeug, das den Client mit dem Cloudflare-Netzwerk verbindet und Richtlinien anwendet
  • Läuft hauptsächlich auf Clients, kann aber auch auf Servern verwendet werden
  • Unterstützt P2P-Verbindungen über Warp-to-Warp-Routing
• Cloudflared: Werkzeug, das Tunnels erstellt und sie dem Zero-Trust-Netzwerk hinzufügt
  • Läuft auf Servern und stellt Einstiegspunkte ins Netzwerk bereit
  • Kann mit dem Befehl cloudflared access Verbindungen zu anderen Zero-Trust-Ressourcen herstellen
  • Kann Tunnels für einmalige Tests erzeugen

Struktur von Tunnels, Routes und Targets

• Tunnels: Mit cloudflared bereitgestellte Ausgangspunkte für Traffic
  • Beispiel: installiert auf einem ständig laufenden Gerät im Heimnetzwerk (192.168.1.1/24)
  • In der Konfigurationsdatei (/etc/cloudflared/config.yml) wird festgelegt, wohin Anfragen bei Eingang weitergeleitet werden
  • Beispiel: gitlab.widgetcorp.tech → localhost:80, gitlab-ssh → localhost:22
• Beispiel für öffentliche Freigabe:
  • homeassistant.mydomain.com → Weiterleitung an 192.168.1.3
  • Wenn in Cloudflare DNS ein CNAME auf die Tunnel-Adresse gesetzt wird, ist der Zugriff auch ohne Warp möglich
• Routes: Definieren, an welchen Tunnel ein bestimmter IP-Bereich gesendet wird
  • Beispiel: das gesamte 192.168.1.1/24 oder eine einzelne IP 192.168.1.3/32
  • Bei bestehender Warp-Verbindung werden Anfragen an diese IPs über das Cloudflare-Netzwerk an den Tunnel geleitet
  • Auch nicht existierende virtuelle IPs (z. B. 10.128.1.1) lassen sich routen
• Targets: Definieren die zu schützenden Infrastruktur-Einheiten
  • Beispiel: homeassistant.mydomain.com → 192.168.1.3/32
  • Targets können mit Access Policies versehen werden, sodass nur bestimmte Nutzer zugreifen dürfen

Access Policies: Zugriffskontrolle

• Nachdem Tunnel, Routes und Targets eingerichtet sind, werden mit Access Policies Zugriffsrechte definiert
• Bestandteile einer Richtlinie
  • Include: Bedingungen für erlaubten Zugriff (OR)
  • Require: Bedingungen, die zwingend erfüllt sein müssen (AND)
  • Action: Allow / Deny / Bypass / Service Auth
• Beispiel 1 – E-Mail-basierte Zugriffskontrolle
  • Nur bestimmte E-Mail-Adressen erhalten Zugriff
  • Die Authentifizierung kann auf GitHub-Login beschränkt werden
• Beispiel 2 – Login bei Warp-Verbindung überspringen
  • Mit dem Gateway-Selektor kann der Login-Bildschirm bei einer Zero-Trust-Warp-Verbindung übersprungen werden
  • Ohne Warp-Verbindung wird ein GitHub-Login verlangt

Bereitstellung und Registrierung des Warp-Clients

• Unter Settings → Warp Client wird die Registrierungsrichtlinie festgelegt
  • GitHub-Authentifizierung und Registrierung nur für bestimmte E-Mail-Adressen erlauben
  • Wenn eine WARP Authentication ID gesetzt ist, kann der Gateway-Selektor verwendet werden
• Unter Profile Settings wird das Client-Verhalten definiert
  • Protokoll (MASQUE/WireGuard), Service-Modus, von der Weiterleitung ausgeschlossene IPs usw. lassen sich festlegen
  • Automatische Installation der Cloudflare-CA, Zuweisung einer eindeutigen CGNAT-IP und Konfiguration von Device Posture sind möglich
• Nach dem Login des Warp-Clients ist die Verbindung zum Zero-Trust-Netzwerk abgeschlossen
  • Danach werden Anfragen an 192.168.1.3 über den Tunnel geroutet

Zusammenfassung des Aufbaus

• Registrierung des Warp-Clients mit GitHub- und E-Mail-basierten Login-Richtlinien
• Ein Tunnel im privaten Netzwerk leitet Anfragen an homeassistant.mydomain.com an 192.168.1.3 weiter
• Traffic zu 192.168.1.3 ist nur bei bestehender Warp-Verbindung über den Tunnel erreichbar
• Es werden zwei Zugriffsarten angeboten: öffentlicher Zugriff über DNS und privater Zugriff über Warp
• Bei Warp-Verbindung wird der Login übersprungen, ohne Verbindung ist GitHub-Authentifizierung erforderlich

Zusätzlich nicht behandelte Themen

• Warp-to-Warp-Routing
• Erstellung einer ausschließlich internen privaten IP innerhalb von Zero Trust
• Konfiguration von SSH-Authentifizierungsrichtlinien
• Andere Anwendungstypen außer Self-Hosted

Keine weiteren Informationen im Original vorhanden

[GN⁺]

Hacker-News-Kommentare

• Cloudflare ist für den privaten Einsatz nachteilig, weil es als TLS-Terminierungspunkt fungiert
  Bei Tailscale Funnel wird das Zertifikat direkt auf meinem Endpoint installiert, während Cloudflare den Traffic dazwischen entschlüsselt und erneut verschlüsselt
  Wie hoch das Datenschutzniveau von WARP für private Netzwerke ist, weiß ich nicht genau, aber beim Internet-Tunneling halte ich den Verlust an Privatsphäre für erheblich
  Außerdem ist eine Struktur mit P2P-Verbindungen + Relay-Fallback deutlich wünschenswerter, weil sie auch ohne Vermittlung durch Dritte funktioniert

  • Ich habe vor Kurzem selbst ein Projekt namens TunnelBuddy gebaut
    Die Struktur nutzt den Rechner eines Freundes als WebRTC-basierten Exit-Node und unterstützt nur P2P ohne TURN-/Relay-Server
    Je nach NAT-Umgebung ist die Erfolgsquote beim Verbindungsaufbau gering, aber da der Traffic nicht über Server Dritter läuft, ist der Schutz der Privatsphäre zuverlässig gewährleistet
  • Es ist ironisch, dass man bei etwas, das sich „Zero Trust“ nennt, am Ende Cloudflare vollständig vertrauen muss
  • Persönlich vertraue ich Tailscale mehr, aber die Funktionen von Cloudflare für benutzerdefinierte Domains und clientlosen Zugriff sind attraktiv
    Man kann etwas Ähnliches auch mit Caddy aufbauen, braucht dann aber weiterhin Port-Forwarding
  • NetFoundry aus der awesome-tunneling-Liste ist ebenfalls eine gute Alternative
    Vorteile sind die Performance und Zuverlässigkeit durch Ende-zu-Ende-Verschlüsselung und mehr als 100 PoPs
  • connet zielt auf eine Struktur mit P2P + Relay-Fallback ab
    Da nur teilnehmende Peers Endpoints offenlegen, ist das in Bezug auf Sicherheit und Privatsphäre vorteilhaft
    Man kann es selbst hosten oder den offiziellen Dienst nutzen

• Ich nutze Netbird zu Hause und privat
  Es ist auf meinem Synology NAS sowie auf allen Laptops, Desktops und Mobilgeräten meiner Familie installiert, und in einer Tmux-Umgebung lässt es sich bequem wie ein Remote-Desktop verwenden

• Bei dem Satz „Der gesamte Traffic läuft über das Cloudflare-Netzwerk“ habe ich aufgehört zu lesen
  Hyprspace hat sich durch jede NAT-Umgebung gebohrt, die ich bisher gesehen habe, und funktioniert auch ohne die Infrastruktur eines Großkonzerns gut

• Der Beitrag wirkt wie ein wirklich hervorragender Einrichtungsleitfaden
  Cloudflare könnte das dokumentieren und als offiziellen Guide verwenden

• Ich habe einen Beitrag gelesen, in dem jemand aus Frust darüber, dass Tailscale in NAT-Umgebungen keine P2P-Verbindung herstellen konnte, Cloudflare Zero Trust + Warp ausprobiert hat
  Aber Cloudflare versucht von vornherein nicht einmal P2P und wechselt letztlich einfach zum Cloudflare-Vertrauensmodell
  Die Motivation ist schwer nachzuvollziehen, aber der Beitrag selbst ist gut strukturiert

  • Cloudflare verfügt weltweit über ein hochwertiges PoP-Netzwerk, sodass die Qualität in der Praxis sogar besser als bei P2P war
    Unser Unternehmen arbeitet ebenfalls komplett remote, und nach dem Wechsel von Tailscale zu Cloudflare hat sich die Performance verbessert
  • Entscheidend ist, ob die Verschlüsselung zwischen den Peers auch über Cloudflare hinweg erhalten bleibt
    Falls ja, ist der Unterschied im Vertrauensmodell nicht so groß, aber Cloudflare ist bei der Relay-Performance stark und damit bei der Geschwindigkeit im Vorteil
    Trotzdem ist Tailscale beim NAT-Hole-Punching hervorragend, daher bevorzuge ich nach Möglichkeit direkte Verbindungen

• Ich nutze tuns.sh, um private Dienste öffentlich erreichbar zu machen
  Mir gefällt, dass es auf SSH-Tunneln basiert und ohne Installation sofort nutzbar ist

• Sowohl der Beitrag als auch die Kommentare waren hilfreich
  Allerdings sind die Bilder im Haupttext kaputt und erzeugen 404-Fehler — zum Beispiel: targets-config-screen.png

• Ich freue mich, dass endlich Kritik an CFs goldenem Käfig aufkommt
  Ich finde, es braucht eine Diskussion, die die Probleme des Zero-Trust-Modells klar benennt

• Dass man mit einem kostenlosen Cloudflare-Konto keinen Plex-Server betreiben kann, ist ein schwerwiegender Nachteil
  Die entsprechenden Nutzungsbedingungen stehen hier

  • Bekommst du von deinem ISP vielleicht IPv6?
    Ich nutze auf IPv6-Basis Emby und Jellyfin problemlos mit Freunden
  • Wer würde schon erwarten, dass jemand kostenlos Video-Streaming-Traffic bereitstellt?
    Anders als normaler Web-Traffic verursacht schon ein einzelner Film hunderte Male höhere Bandbreitenkosten
  • In meinem kostenlosen Konto funktioniert Jellyfin über einen cloudflared tunnel problemlos
    Auf dem Arbeitslaptop meiner Freundin ließ sich Tailscale nicht installieren, daher war diese Methode nützlich
  • In der Praxis werden die Nutzungsbedingungen nicht streng durchgesetzt, solange der Traffic nicht hoch ist
  • Ich nutze es ebenfalls für Jellyfin, und es läuft seit Monaten ohne Probleme

• Ich frage mich, ob die Nutzung von Cloudflare nicht Vendor Lock-in ist
  Ich denke, Tailscale hat zumindest keine solche Abhängigkeit

  • Ich war allerdings überrascht zu erfahren, dass Tailscale am Ende doch ein kommerzieller Anbieter ist
    Ich dachte, es sei ein Open-Source-Projekt, aber das ist es nicht