INTERNET_ZUGRIFF_EINRICHTEN.md: Sicherheits-Checkliste ergänzt, Cloudflared-Add-on konkretisiert
Neuer Schritt 6 mit den Cloudflare-/NPM-Sicherheitseinstellungen (SSL-Modus, HSTS, Bot Fight Mode, DNS-Aufräumen, Token pro Gerät, Router-Portcheck) und dem größten praktischen Stolperstein (Tunnel-Hostname zeigt versehentlich direkt auf HA statt auf den Reverse Proxy). Nachfolgende Schritte/Verweise umnummeriert, ein alter Nummerierungsfehler in der Einleitung mitkorrigiert. Cloudflared-Add-on jetzt namentlich mit Link genannt und geprüft (homeassistant-apps/app-cloudflared) - die frühere Bezeichnung "offizielles Add-on" war ungenau (Community-Add-on, kein Nabu-Casa-Produkt). Festgehalten, dass der dokumentierte Tunnel-Token-Weg keinen Cloudflare-API-Token braucht. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
@@ -5,7 +5,7 @@ Schritt-für-Schritt-Anleitung, damit die native Companion-App (iOS-Sideload, si
|
|||||||
im Heimnetz/über Tailscale. Home Assistant selbst bleibt dabei durchgehend **lokal, ohne offenen Port**;
|
im Heimnetz/über Tailscale. Home Assistant selbst bleibt dabei durchgehend **lokal, ohne offenen Port**;
|
||||||
nur ein eng begrenzter, pfad-gefilterter Ausschnitt der API wird über einen Cloudflare-Tunnel erreichbar
|
nur ein eng begrenzter, pfad-gefilterter Ausschnitt der API wird über einen Cloudflare-Tunnel erreichbar
|
||||||
gemacht. Architektur/Begründung: `../COMPANION_APP_ARCHITECTURE.md` §4. Die technische Pfad-Freigabeliste
|
gemacht. Architektur/Begründung: `../COMPANION_APP_ARCHITECTURE.md` §4. Die technische Pfad-Freigabeliste
|
||||||
selbst, die in Schritt 6 unten eingetragen wird: [`REVERSE_PROXY.md`](REVERSE_PROXY.md).
|
selbst, die in Schritt 4 unten eingetragen wird: [`REVERSE_PROXY.md`](REVERSE_PROXY.md).
|
||||||
|
|
||||||
**Wer was macht:** Kontoerstellung, Domain-/Nameserver-Verwaltung bei Cloudflare bzw. all-inkl und das
|
**Wer was macht:** Kontoerstellung, Domain-/Nameserver-Verwaltung bei Cloudflare bzw. all-inkl und das
|
||||||
Klicken durch die HA-Add-on-Oberfläche sind ausschließlich Sache des Fahrzeughalters selbst - dafür gibt
|
Klicken durch die HA-Add-on-Oberfläche sind ausschließlich Sache des Fahrzeughalters selbst - dafür gibt
|
||||||
@@ -49,13 +49,19 @@ veröffentlichen.
|
|||||||
## 3. Cloudflared-Add-on installieren und Tunnel einrichten
|
## 3. Cloudflared-Add-on installieren und Tunnel einrichten
|
||||||
|
|
||||||
1. In Home Assistant: *Einstellungen → Add-ons → Add-on Store* → nach "Cloudflared" suchen, installieren.
|
1. In Home Assistant: *Einstellungen → Add-ons → Add-on Store* → nach "Cloudflared" suchen, installieren.
|
||||||
(Offizielles Home Assistant Community Add-on - nicht die eigenständige `cloudflared`-CLI von Hand
|
Empfohlen und geprüft: [`homeassistant-apps/app-cloudflared`](https://github.com/homeassistant-apps/app-cloudflared)
|
||||||
einrichten.)
|
(Tobias Brenner, MIT-lizenziert, aktiv gepflegt, >1.500 GitHub-Stars) - kein offizielles
|
||||||
|
Home-Assistant-Add-on, aber das etablierte Community-Add-on für genau diesen Zweck; nicht die
|
||||||
|
eigenständige `cloudflared`-CLI von Hand einrichten.
|
||||||
2. Im Cloudflare-Dashboard: *Zero Trust → Networks → Tunnels* → *Create a tunnel* → Typ "Cloudflared" →
|
2. Im Cloudflare-Dashboard: *Zero Trust → Networks → Tunnels* → *Create a tunnel* → Typ "Cloudflared" →
|
||||||
Namen vergeben (z. B. `datametric360`).
|
Namen vergeben (z. B. `datametric360`).
|
||||||
3. Cloudflare zeigt einen Tunnel-Token an - diesen im HA-Add-on unter *Konfiguration* eintragen (Feld
|
3. Cloudflare zeigt einen Tunnel-Token an - diesen im HA-Add-on unter *Konfiguration* im Feld
|
||||||
`tunnel_token` bzw. je nach Add-on-Version über die angezeigte `cloudflared service install`-Zeile;
|
**`tunnel_token`** eintragen ("Remote Tunnel Setup" in den Add-on-Docs; alle anderen
|
||||||
das Add-on übernimmt das Token-Handling, kein manueller `cloudflared`-Aufruf per SSH nötig).
|
Konfigurationsfelder des Add-ons werden dann ignoriert). Kein manueller `cloudflared`-Aufruf per SSH
|
||||||
|
nötig, **und kein Cloudflare-API-Token nötig** - das Add-on hat neben diesem Weg auch einen zweiten,
|
||||||
|
browserbasierten Modus ("Local Tunnel Setup", legt den Tunnel selbst per Login-Link an), der hier
|
||||||
|
bewusst nicht verwendet wird: der manuelle Weg über den Tunnel-Token macht sichtbar und
|
||||||
|
nachvollziehbar, welcher Tunnel mit welchem Namen existiert, statt das dem Add-on zu überlassen.
|
||||||
4. Add-on starten. Im Cloudflare-Dashboard sollte der Tunnel danach als "Healthy"/verbunden angezeigt
|
4. Add-on starten. Im Cloudflare-Dashboard sollte der Tunnel danach als "Healthy"/verbunden angezeigt
|
||||||
werden - das bestätigt die **ausgehende** Verbindung vom HAOS-Host zu Cloudflares Edge (kein
|
werden - das bestätigt die **ausgehende** Verbindung vom HAOS-Host zu Cloudflares Edge (kein
|
||||||
Router-Port nötig, kein Port-Forward einzurichten).
|
Router-Port nötig, kein Port-Forward einzurichten).
|
||||||
@@ -96,9 +102,55 @@ veröffentlichen.
|
|||||||
5. **URL:** die interne Adresse des Nginx-Proxy-Manager-Add-ons, üblicherweise der Add-on-Hostname im
|
5. **URL:** die interne Adresse des Nginx-Proxy-Manager-Add-ons, üblicherweise der Add-on-Hostname im
|
||||||
Supervisor-Netz plus dessen konfigurierten Port (im Add-on selbst unter *Info* nachsehen, welcher
|
Supervisor-Netz plus dessen konfigurierten Port (im Add-on selbst unter *Info* nachsehen, welcher
|
||||||
interne Port/Hostname das ist - **nicht** Port 8123, das wäre HA direkt).
|
interne Port/Hostname das ist - **nicht** Port 8123, das wäre HA direkt).
|
||||||
6. Speichern.
|
6. Speichern. **Danach unbedingt gegenprüfen, welche URL hier tatsächlich hinterlegt ist** - zeigt sie
|
||||||
|
aus Versehen auf `homeassistant:8123` statt auf den NPM-Port, läuft die komplette HA-Oberfläche
|
||||||
|
samt Login öffentlich, ohne dass die Pfad-Freigabeliste aus Schritt 4 überhaupt greift. Das ist der
|
||||||
|
größte praktische Stolperstein dieser ganzen Einrichtung.
|
||||||
|
|
||||||
## 6. Prüfen
|
## 6. Sicherheitseinstellungen (Cloudflare + Nginx Proxy Manager)
|
||||||
|
|
||||||
|
Zusätzlich zur reinen Pfad-Freigabeliste (Schritt 4) - die eigentliche Sicherheit hängt an genau zwei
|
||||||
|
Dingen: dem Zugriffstoken und daran, dass wirklich nur die gelisteten Pfade durchkommen. Alles hier ist
|
||||||
|
zusätzliche Härtung, kein Ersatz dafür.
|
||||||
|
|
||||||
|
**Cloudflare, Tab *DNS*:**
|
||||||
|
- Prüfen, ob beim Domain-Import aus dem alten all-inkl-Bestand zusätzliche DNS-Einträge übernommen
|
||||||
|
wurden (z. B. eine Parkseiten-A-Eintragung) - außer dem vom Tunnel selbst angelegten Eintrag soll
|
||||||
|
nichts auf der Domain liegen.
|
||||||
|
- Der vom Tunnel angelegte Eintrag muss **"Proxied"** (orange Wolke) sein, nicht "DNS only" (grau).
|
||||||
|
|
||||||
|
**Cloudflare, Tab *SSL/TLS*:**
|
||||||
|
- Verschlüsselungsmodus **"Full"**, nicht "Flexible".
|
||||||
|
- **"Always Use HTTPS"** aktivieren.
|
||||||
|
- Unter *Edge Certificates*: **HSTS aktivieren** (moderate `max-age`, z. B. 6 Monate) - gleicht aus,
|
||||||
|
dass `.de` (anders als das ursprünglich erwogene `.app`) nicht auf der HSTS-Preload-Liste steht,
|
||||||
|
siehe `COMPANION_APP_ARCHITECTURE.md` §5 Punkt 4.
|
||||||
|
|
||||||
|
**Cloudflare, Tab *Security*:**
|
||||||
|
- **Bot Fight Mode NICHT aktivieren** - die native App ist kein Browser und würde von den
|
||||||
|
Bot-Heuristiken vermutlich mitblockiert.
|
||||||
|
- Optional: eine Rate-Limiting-Regel auf `/api/*` (im Free-Plan in Grenzen enthalten) bremst reines
|
||||||
|
Durchprobieren, ersetzt aber nicht den Token.
|
||||||
|
|
||||||
|
**Nginx Proxy Manager, Proxy Host:**
|
||||||
|
- **"Force SSL"** und **"Block Common Exploits"** aktivieren.
|
||||||
|
- Nach dem Einfügen des Codeblocks aus `REVERSE_PROXY.md` in *Advanced*: prüfen, ob NPM die
|
||||||
|
Konfiguration ohne Fehler übernimmt. NPM erzeugt aus dem *Details*-Tab selbst schon einen
|
||||||
|
`location /`-Block - der kann sich mit dem abschließenden `location / { return 404; }` aus der
|
||||||
|
eingefügten Freigabeliste überschneiden. Meldet NPM beim Speichern einen Konfigurationsfehler, diesen
|
||||||
|
letzten Block aus dem eingefügten Code weglassen (NPMs eigener Standard-Block fängt dann alles
|
||||||
|
Nicht-Gematchte ab, sofern die vorderen `location`-Blöcke wie vorgesehen zuerst greifen).
|
||||||
|
|
||||||
|
**Zugriffstoken:**
|
||||||
|
- **Pro Gerät ein eigener Token**, nicht denselben auf mehreren Handys - dann lässt sich ein verlorenes
|
||||||
|
Gerät gezielt aussperren (*Profil → Sicherheit → Zugriffstoken*), ohne das andere neu einzurichten.
|
||||||
|
- Ausschließlich als `Authorization: Bearer`-Header, nie in der URL/Query-String.
|
||||||
|
|
||||||
|
**Router:**
|
||||||
|
- Sicherstellen, dass **kein Port-Forward auf 8123** existiert (auch keiner mehr aus früheren
|
||||||
|
Versuchen anderer Ports/Zwecke).
|
||||||
|
|
||||||
|
## 7. Prüfen
|
||||||
|
|
||||||
Von einem Netz **ohne** VPN/Tailscale (z. B. Mobilfunk, WLAN-Tethering vom Handy) die Prüfbefehle aus
|
Von einem Netz **ohne** VPN/Tailscale (z. B. Mobilfunk, WLAN-Tethering vom Handy) die Prüfbefehle aus
|
||||||
[`REVERSE_PROXY.md`](REVERSE_PROXY.md) (Abschnitt "Nach der Einrichtung prüfen") ausführen. Kurzfassung:
|
[`REVERSE_PROXY.md`](REVERSE_PROXY.md) (Abschnitt "Nach der Einrichtung prüfen") ausführen. Kurzfassung:
|
||||||
@@ -108,7 +160,7 @@ funktionieren; `GET /auth/authorize` und `GET /api/config` müssen `404`/`403` l
|
|||||||
(z. B. über einen externen Port-Checker prüfen, oder `curl` gegen `http://<öffentliche-WAN-IP>:8123`,
|
(z. B. über einen externen Port-Checker prüfen, oder `curl` gegen `http://<öffentliche-WAN-IP>:8123`,
|
||||||
das muss ins Leere laufen).
|
das muss ins Leere laufen).
|
||||||
|
|
||||||
## 7. Server-Adresse in der App eintragen
|
## 8. Server-Adresse in der App eintragen
|
||||||
|
|
||||||
Auf jedem Gerät, auf dem die companion-app sideload-installiert ist: beim (erneuten) Einrichten
|
Auf jedem Gerät, auf dem die companion-app sideload-installiert ist: beim (erneuten) Einrichten
|
||||||
`https://datametric360.de` als Server-Adresse eintragen, den bestehenden Zugriffstoken wiederverwenden
|
`https://datametric360.de` als Server-Adresse eintragen, den bestehenden Zugriffstoken wiederverwenden
|
||||||
@@ -119,7 +171,7 @@ ohnehin dieselbe Server-Adresse für beide Fälle verwendet.
|
|||||||
|
|
||||||
## Was danach noch offen bleibt
|
## Was danach noch offen bleibt
|
||||||
|
|
||||||
- Ein Fehlschlag in Schritt 6 zuerst hier prüfen, in dieser Reihenfolge: Ist die Domain in Cloudflare
|
- Ein Fehlschlag in Schritt 7 zuerst hier prüfen, in dieser Reihenfolge: Ist die Domain in Cloudflare
|
||||||
"Active" (Schritt 2)? Zeigt der Tunnel "Healthy" (Schritt 3.4)? Antwortet der Nginx-Proxy-Manager-Host
|
"Active" (Schritt 2)? Zeigt der Tunnel "Healthy" (Schritt 3.4)? Antwortet der Nginx-Proxy-Manager-Host
|
||||||
lokal überhaupt (`curl` von der HA-Konsole gegen die in Schritt 5.5 eingetragene interne Adresse)?
|
lokal überhaupt (`curl` von der HA-Konsole gegen die in Schritt 5.5 eingetragene interne Adresse)?
|
||||||
Erst danach die Pfad-Regeln selbst (Schritt 4) noch einmal gegen `REVERSE_PROXY.md` vergleichen.
|
Erst danach die Pfad-Regeln selbst (Schritt 4) noch einmal gegen `REVERSE_PROXY.md` vergleichen.
|
||||||
|
|||||||
Reference in New Issue
Block a user