Dein Fernzugriff funktioniert — aber du hast es nicht bewiesen

Der ehrlichste Grund, von unterwegs in die eigene Wohnung zu sehen, ist bei mir kein technischer: Bruno bleibt da. Was er tut, wenn die Tür zufällt, wussten wir lange nicht — und genau das ist der Anlass gewesen, den Fernzugriff nicht nur einzurichten, sondern ihm auch zu trauen.

Denn eine Kamera, die man im Zweifel nicht erreicht, beruhigt niemanden.

Drei Wohnungen, drei Antworten auf dieselbe Frage:

	Fernzugriff
Kapfenberg	seit 29.08.2026 in Betrieb
Wien	seit 08.09.2026, nach einem Abend Fehlersuche
Meran	gar nicht dokumentiert

Der dritte Eintrag ist der ehrlichste, und ich komme am Schluss darauf zurück.

Der Aufbau, der in zwei Häusern steht

Internet --443--> Router --Freigabe--> Pi --> Proxy --> Home Assistant

Dazu ein dynamischer DNS-Name. Der ist kein Luxus: In Kapfenberg hat sich die öffentliche Adresse innerhalb von drei Wochen geändert. Genau dafür gibt es den Namen — und genau deshalb steht in der Dokumentation ab diesem Tag der Name und nicht mehr die Zahl.

Womit sich der Fernzugriff nicht nachweisen lässt

Das ist der Teil, der mir am meisten wert ist, weil ich beide Irrwege selbst gegangen bin.

Erster Irrweg: der Aufruf aus dem eigenen Haus. Ein Abruf des öffentlichen Namens aus dem Heimnetz liefert 200 OK. Sieht nach Beweis aus, ist keiner: Die Anfrage geht zum Router, der reicht sie über die eigene Freigabe zurück. Sie war nie im Internet. Das nennt sich NAT-Hairpin.

Zweiter Irrweg: der Abruf durch ein Werkzeug, das „in der Cloud“ läuft. Der Gedanke lag nahe — wenn der Abruf auf fremder Infrastruktur läuft, kommt er von außen.

Er lief lokal. Der Beweis stand im Sperrprotokoll: Als Absender war die eigene öffentliche Adresse eingetragen, samt Benutzerkennung des Werkzeugs. Wieder Hairpin, nur mit anderem Absenderschild.

Was beide immerhin zeigen: Die Weiterleitungsregel existiert und zeigt auf den richtigen Rechner. Was keiner zeigt: ob der Anbieter eingehende Verbindungen überhaupt durchlässt.

Gültig sind genau zwei Wege:

1. Vom Handy über Mobilfunk, WLAN ausgeschaltet.
2. Von einem Rechner außerhalb, etwa einem gemieteten Server.

Der Trick mit dem Fehlversuch

Die Gegenprobe im Protokoll funktioniert nur bei einem Fehlversuch — das Sperrprotokoll schreibt ausschließlich abgelehnte Anmeldungen. Also absichtlich einmal falsch anmelden; dann steht die echte Absenderadresse da.

Dabei mitzählen: Nach fünf Fehlversuchen landet die Adresse in der Sperrliste. Bei einer Mobilfunkadresse verschmerzbar, beim eigenen Anschluss lästig.

Sperren verfallen nicht von selbst

Nachgelesen im Quelltext: Die Sperrliste wird beim Start aus der Datei gelesen, danach liegt sie im Arbeitsspeicher und wird nur noch ergänzt. Eine Verfallszeit gibt es nicht.

Daraus folgt etwas, das man leicht übersieht: Die Datei aufzuräumen reicht nicht. Ohne Neustart bleibt die Sperre im Arbeitsspeicher aktiv.

Zwei Dinge gehören sauber auseinandergehalten:

	liegt wo	überdauert einen Neustart?
Zähler der Fehlversuche	Arbeitsspeicher	nein — nach jedem Start bei null
fertige Sperre (ab 5 Fehlversuchen)	Datei	ja, dauerhaft

Man kann sich also nicht über Tage hinweg in eine Sperre hineinstolpern. Es braucht fünf Fehlversuche in einem Lauf.

Die Aufräumung läuft täglich um vier Uhr früh: Einträge älter als 24 Stunden entfernen — und nur dann neu starten, wenn dabei etwas entfernt wurde. An den allermeisten Tagen passiert also gar nichts.

Geprüft habe ich sie mit einer künstlichen Liste aus dem Adressbereich, der für Dokumentation reserviert ist:

Eintrag	Alter	Ergebnis
erster	30 h	entfernt
zweiter	2 h	behalten
dritter	Datum unlesbar	behalten

Der dritte Fall ist Absicht. Eine Sperre aufzuheben, weil man ihr Datum nicht lesen kann, wäre die falsche Richtung zu irren.

Die Berichtigung, die eine Doku wertlos macht

In meiner eigenen Dokumentation stand acht Zeilen lang, nach außen zeige „nur der Proxy auf 443“.

Vom Büro aus nachgemessen, also wirklich von außen:

Port 22     antwortet   <- das SSH-Add-on
Port 443    antwortet   <- der Proxy
Port 2222   Zeitüberschreitung
Port 22222  Zeitüberschreitung

Port 22 ist ebenfalls freigegeben. Claude hatte sich auf diese Doku verlassen und daraufhin behauptet, von hier aus ließen sich keine Pakete ausspielen. Falsch — darauf gestoßen bin ich selbst.

Eine Doku, die eine Freigabe nicht kennt, ist schlimmer als keine: Sie klingt nach einer geprüften Aussage.

Wie das offene Tor gesichert ist, habe ich daraufhin nachgesehen:

Anmeldung mit Kennwort	aus
Tastatur-Abfrage	aus
Anmeldung als Hauptbenutzer	ja
hinterlegte Schlüssel	genau einer

Also: Hauptbenutzer ja, aber ausschließlich mit genau einem Schlüssel. Wer den nicht hat, kommt an Port 22 nicht weiter, egal wie oft er es versucht. Die Freigabe ist damit vertretbar — sie war nur nicht aufgeschrieben.

Zwei Faktoren und ein Einwand, der nicht trägt

Der Einwand gegen die Zwei-Faktor-Anmeldung lautete: Mit nur einem Handy sei es mühsam, bei jeder Anmeldung einen zweiten Faktor einzugeben.

Das trifft so nicht zu. Home Assistant vergibt pro Gerät und Browser ein Aktualisierungs-Token. Wer beim Anmelden „angemeldet bleiben“ ankreuzt, gibt den zweiten Faktor einmal je Gerät ein, nicht einmal je Sitzung.

Verworfen habe ich dagegen die naheliegende Abkürzung, das Heimnetz pauschal als vertrauenswürdig zu erklären und die Anmeldung dort zu überspringen. Sie verschiebt die Sicherheit auf die Annahme, dass im eigenen WLAN nur Befugte hängen — und die hält genau so lange, bis ein Gerät im Netz kompromittiert ist.

Und der dritte Ort

Für Meran gibt es keine Datei zum Fernzugriff. Nicht eine kurze, nicht eine unvollständige — keine.

Das ist kein Versäumnis dieses Artikels, das ist der Stand. Und es hängt ein zweiter offener Punkt daran: Dieselbe wirkungslose Konfigurationssektion, die mich in Wien einen Abend gekostet hat, liegt dort vermutlich auch. Geprüft ist das nicht.

Der ehrlichste Eintrag in einem Standortvergleich ist der, wo nichts steht.

Was ich dir rate

1. Prüf von außen, nicht von innen. Handy mit Mobilfunk, WLAN aus. Alles andere kann Hairpin sein und sieht trotzdem aus wie Erfolg.
2. Trau keinem Werkzeug, von dem du glaubst, es laufe woanders. Lies im Protokoll nach, welche Absenderadresse tatsächlich ankam.
3. Nimm einen Namen, nicht die Adresse. Sie ändert sich, und sie tut es ohne Ankündigung.
4. Schreib jede Freigabe auf, auch die bequeme. Eine unvollständige Liste offener Tore ist gefährlicher als gar keine.
5. Räum die Sperrliste auf — mit Neustart. Ohne den bleibt die Sperre im Arbeitsspeicher, egal was in der Datei steht.
6. Richte den zweiten Faktor ein, bevor du die Freigabe setzt. Danach ist er eine Aufgabe, die liegen bleibt.

Und was heißt das?

Fernzugriff ist der einzige Punkt in diesen drei Wohnungen, an dem ein Fehler nicht nur Unbequemlichkeit bedeutet. Alles andere kostet im schlimmsten Fall Daten oder Komfort. Hier steht eine Tür.

Umso unangenehmer ist, wie leicht man sich den Erfolg einredet. Zwei Mal habe ich geglaubt, den Zugang von außen nachgewiesen zu haben, und beide Male war die Anfrage nie aus dem Haus heraus. Es sah jedes Mal aus wie ein Beweis — grüner Status, 200 OK, alles gut.

Der Unterschied zwischen „es funktioniert“ und „ich habe es geprüft“ ist bei einem Fernzugriff kein akademischer. Im einen Fall weißt du, dass die Tür aufgeht. Im anderen weißt du nur, dass du auf der richtigen Seite stehst.