Raspberry Pi Web Anwendung: Pfad sicher über Cloudflare Tunnel bereitstellen?

[TomLee]

Hallo zusammen,

hier sind doch die Spezis, vertrauen tu ich mangels Basiswissen dem erarbeiteten "KI"-Vorschlag mit Cloudflare nicht ganz 😅

Ich habe eine Web-App, die in einem Docker-Container auf meinem Raspberry Pi läuft, und möchte sie öffentlich zugänglich machen.
Ich will nur einen bestimmten Pfad freigeben, z. B. https://pi/hier .

Bevor ich mich jetzt lange mit der Einrichtung beschäftige, nur um später irgendwann festzustellen, dass es doch nicht der sicherste Weg war, frage ich lieber vorher:

Wie setzt man sowas korrekt und sicher um?

Ohne Hilfe hier würde ich es bisher mit cloudflared Ingress-Regeln versuchen einzurichten - aber ich bin mir unsicher, ob das alleine ausreicht oder ob ich zusätzlich z. B. Nginx als Reverse Proxy nutzen sollte.

Gruß
Thomas

[TomLee]

Wie gesagt hab ich nur sehr wenig Hintergrundwissen zu dem Thema.

Hab mich weiter mit beschäftigt und am Ende bin ich wieder ganz am Anfang.
Meine Domain hab ich bei der Telekom, dort lassen sich die Nameserver nicht ändern.

Ich müsste wie ich es verstehe die Domain zu Cloudflare umziehen, wegen dem DNS-Gedöhns, das trau ich mir erst mal nicht zu und gerne vermeiden.

Gibt es noch weitere sichere Möglichkeiten die Anwendung aus dem Internet erreichbar zu machen, ausser über die Portfreigabe mit bspw. nginx, ohne die Domain umzuziehen?

Ja, es muss sein. Die Anwendung muss öffentlich erreichbar sein, da führt kein Weg daran vorbei.

 

[passibe]

Kostenfreie Alternativen zu tunnels kenne ich nicht, außer du mietest dir halt irgendwo ein VPS. Schau vielleicht auch mal auf Reddit in r/selfhosted oder r/de_EDV, vielleicht findet sich da noch was.

Willst du dennoch tunnels nutzen:

Domain Registrierung nicht zu Cloudflare umziehen (ich rede hier nur über die Registrierung, nicht über die Nameserver):
a) Cloudflare unterstützt (glaube ich) keine .de-Domains
b) Nicht alle eggs in one basket, bedeutet: Registrar von Nameserver-Anbieter trennen.

Am besten, die Domain zu netcup oder hetzner umziehen (de-Domain kostet 5 EUR/Jahr) und dann die Nameserver (und nur die) zu Cloudflare ändern. Geht problemlos und ruckzuck mit dem AuthCode. Vorher natürlich aufschreiben, welche Records du bei der Telekom hattest. Wenn die gut sind, bieten die auch eine Option, dass du das als Zonendatei exportieren kannst, die kannst du dann bei Cloudflare direkt importieren.
Achso, und wenn dein Vertrag bei der Telekom noch weiter läuft, musst du den noch weiter zahlen, obwohl du dann keine Domain mehr dort hast ...

Von der Telekom würde ich allein schon deshalb weg, weil die es einem nicht erlauben, den Nameserver zu wechseln. Was soll das. Cloudflare macht das übrigens genauso, wenn man die als Registrar nutzt, das tritt noch zu den Gründen a) und b) oben dazu.

Ansonsten kann ich über Tunnels nicht so viel sagen, weil ich selbst nur das normale Proxying von Cloudflare nutze (orangene Wolke beim DNS-Eintrag). Dennoch Folgendes:

• Du kannst auch noch diese Firewallregeln da nutzen, also z.B. IPs aus bestimmten Ländern sperren oder nur manche Länder zulassen, das ist eigentlich auch ganz nett, um die Log-Dateien etwas sauberer zu halten.
• Da kann man auch Pfade angeben, die erlaubt sein sollen (vermutlich analog zu den Ingress-Regeln, oder ist das identisch?). Ich persönlich würde mir, einfach nur um ruhiger schlafen zu können, noch einen Reverse Proxy davor gönnen, der nur diesen Pfad freigibt, als zweite Sicherheitsebene. Am Ende ist das aber vermutlich egal und, wie gesagt, eher fürs Gefühl.

Auch hier für mehr Infos am besten auf Reddit lesen.

tl;dr:

• Backup aktuelle DNS-Einträge (z.B. Zonendatei exportieren)
• AuthCode anfordern bei Telekom
• Domain z.B. bei Hetzner/Netcup buchen, im Bestellprozess zuvor erhaltenen AuthCode angeben
• Cloudflare Domain-Onboarding starten
• Bei Hetzner/Netcup die Nameserver eintragen, die von Cloudflare mitgeteilt wurden
• Bisschen warten
• Sobald Cloudflare gemerkt hat, dass die Namserver geändert wurden, DNS-Records aus Backup importieren bzw. mit dem Backup neu anlegen
• Dann noch Tunnels einrichten
• ⁇⁇
• Profit

[TomLee]

Mit tailscale bekommt man eine kostenlose Domain, hab ich jetzt die letzten 2 Stunden festgestellt.
Mir wäre in dem Fall egal wie die lautet.

Eigentlich sollte es auch schon laufen:

Code Auswählen Erweitern

pi@fhempi:/opt/tailscale-test $ sudo docker exec tailscale-standalone tailscale funnel --bg 80
Available on the internet:

https://bliblablub.tailcab18f.ts.net/
|-- proxy http://192.168.188.26:80

Funnel started and running in the background.
To disable the proxy, run: tailscale funnel --https=443 off
Bis jetzt hab ich den Grund aber noch nicht gefunden, weshalb der Aufruf der URL nicht klappt.

[passibe]

Mir wäre in dem Fall egal wie die lautet.

Ah, ok! Dann ist ja gut mit dem Funnel.

Bis jetzt hab ich den Grund aber noch nicht gefunden, weshalb der Aufruf der URL nicht klappt.

Was gibt denn z.B. ein curl -v https://... von einem anderen System aus? Oder wie genau äußert sich "nicht klappt"? Welche WebApp ist das überhaupt?

[TomLee]

Code Auswählen Erweitern

pi@fhempi:/opt/tailscale-test $ curl -v https://bliblablub.tailcab18f.ts.net/
* Host bliblablub.tailcab18f.ts.net:443 was resolved.
* IPv6: xx 2a00:dd80:20::55
* IPv4: x, 185.40.234.55
*  Trying [x::a8e]:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256 / X25519MLKEM768 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=bliblablub.tailcab18f.ts.net
*  start date: Apr  4 13:30:25 2026 GMT
*  expire date: Jul  3 13:30:24 2026 GMT
*  subjectAltName: host "bliblablub.tailcab18f.ts.net" matched cert's "bliblablub.tailcab18f.ts.net"
*  issuer: C=US; O=Let's Encrypt; CN=E7
*  SSL certificate verify ok.
*  Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*  Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption
*  Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* Connected to fhempi-1.tailcab18f.ts.net (2a00:dd80:20::a8e) port 443
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://bliblablub.tailcab18f.ts.net/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: bliblablub.tailcab18f.ts.net]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.14.1]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: bliblablub.tailcab18f.ts.net
> User-Agent: curl/8.14.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Request completely sent off
< HTTP/2 302
< cache-control: max-age=0, must-revalidate, private
< content-type: text/html; charset=utf-8
< date: Sat, 04 Apr 2026 14:31:31 GMT
< expires: Sat, 04 Apr 2026 14:31:31 GMT
< location: http://bliblablub.tailcab18f.ts.net/login
< server: nginx
< set-cookie: PHPSESSID=8720b10c8013aa3a767b647f474656d7; path=/; httponly; samesite=lax
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-robots-tag: noindex
<
<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8" />
        <meta http-equiv="refresh" content="0;url='http://bliblablub.tailcab18f.ts.net/login'" />

        <title>Redirecting to http://bliblablub.tailcab18f.ts.net/login</title>
    </head>
    <body>
        Redirecting to <a href="bliblablub.tailcab18f.ts.net/login">http://bliblablub.tailcab18f.ts.net/login</a>.
    </body>
* Connection #0 to host bliblablub.tailcab18f.ts.net left intact

[passibe]

Sieht doch gut aus, wirst halt nach /login umgeleitet?
Deshalb meinte ich:

Oder wie genau äußert sich "nicht klappt"? Welche WebApp ist das überhaupt?

Und dass es vom Pi selbst aus gut aussieht, ist logisch. Deshalb meinte ich auch:

curl -v https://... von einem anderen System aus?

[TomLee]

Upps, ich habs jetzt mehrfach immer wieder von neuem versucht, das der Aufruf plötzlich klappt, hatte ich gar nicht bemerkt nachdem ich hier mit schreiben beschäftigt war. Vlt. war ich die ganze Zeit auch nur ungeduldig und es dauert einen Moment bis es klappt.