Geräte öffnen
Die Anlagen, für die dieses Konto freigegeben ist. Ein Klick löst ein Einmal-Ticket und wechselt auf den Gerätenamen — die Adresse lässt sich nicht als Lesezeichen aufbewahren, jeder Zugang beginnt hier.
Ihre Anlage. Der Link öffnet sie in diesem Fenster; danach bleibt sie acht Stunden offen und fragt erst dann wieder nach dem Passwort.
| Gerät | Kennung | Verbindung | |
|---|---|---|---|
|
„Tunnel still“ heißt, dass der letzte Handschlag zu lange zurückliegt. Der Versuch lohnt trotzdem — der Router meldet sich alle 25 Sekunden.
Übersicht
Was fehlt, steht oben. Bestände zählt jede Liste selbst — hier zählt, welcher Standort keinen Schlüssel hat, welcher Peer abgelaufen ist und ob der Kernel noch dem entspricht, was zuletzt angewandt wurde.
Die Übersicht ließ sich nicht laden.
Der Hostdienst ist nicht erreichbar.
Über den Kernel lässt sich von hier aus nichts sagen: die Angaben zu Isolation und Peers sind aus dieser Antwort nicht zu haben.
Die Isolationstabelle ist nicht aktiv.
Ohne sie sehen alle Standorte einander — jedes Kundennetz liegt für jedes andere offen. Das ist kein Schönheitsfehler, sondern ein Grund, den Tunnel bis zur Klärung nicht zu benutzen.
Der Kernel weicht von der angewandten Generation ab. Jemand hat ihn von Hand verändert; die nächste Generation überschreibt das kommentarlos.
Standorte ohne öffentlichen Schlüssel. Der Router hat sich noch nicht zurückgemeldet — bis dahin gibt es dort keinen Tunnel, gleich wie vollständig die Stammdaten sind.
Standorte mit gesperrtem Peer. Schlüssel vorhanden, Peer abgeschaltet. Entweder war das Absicht — dann gehört ein Wort in die Notiz — oder es ist von einer Archivierung übriggeblieben.
Abgelaufene Personen-Peers. Verlängern oder entfernen; aus dem Kernel verschwinden sie erst mit der nächsten angewandten Generation.
Tunnelzustand
Älteste Rückmeldung zuerst| Standort | Kunde | Tunneladresse | Gerätenetz | Letzte Rückmeldung | Peer |
|---|---|---|---|---|---|
| Kein Standort erfasst Erst einen Kunden anlegen, dann darunter den Standort — der Tunnel kommt danach. | |||||
Öffentlicher Schlüssel des Hubs
Gehört in jede Standort- und PersonenkonfigurationKunden
Der Mandant. Jeder Standort, jedes Kundenkonto und jedes Zertifikat hängt daran. Die Kennung ist unveränderlich — sie steckt im Peer-Namen des Hostdienstes und in den Zertifikatslisten.
| Name | Kennung | Ansprechpartner | Kontakt | Standorte | Status | |
|---|---|---|---|---|---|---|
| · | 2FA immer | |||||
| Kein Kunde vorhanden Ohne Kunden gibt es keine Standorte — hier fängt die Erfassung an. | ||||||
Die Kennung lässt sich später nicht mehr ändern.
Kunde archivieren
Archivieren nimmt alles darunter mit und sperrt die Peers. Wirksam wird das im Overlay erst mit der nächsten angewandten Generation — bis dahin steht der Router weiter im Kernel.
Relays, die gesperrt werden:
System-Ziele, die wegfallen:
Standorte
Ein Standort ist ein Router und das Netz dahinter. Die Tunneladresse vergibt der Server aus dem Standortpool; das Gerätenetz kommt vom Kunden und darf sich mit keinem anderen überschneiden — WireGuard ordnet Verkehr über AllowedIPs zu, doppelte Netze führen still ins falsche Kundennetz.
| Name | Kunde | Kennung | Uplink / Geräte | Gerätenetz | Tunneladresse | Peer | Handshake | Geräte | |
|---|---|---|---|---|---|---|---|---|---|
| ruhend | ohne PSK | ||||||||
| Kein Standort in dieser Auswahl Erst den Standort anlegen, dann den öffentlichen Schlüssel des Routers eintragen, dann die Geräte erfassen. | |||||||||
Kunde und Kennung stehen danach fest. Die Tunneladresse vergibt der Server — dafür gibt es hier kein Feld.
— nutzbare Adressen
Inventar
Was am Gerät aufgedruckt ist. Ohne diese Angaben wird jeder Austausch zum Ortstermin.
Schlüssel des Standorts
Der private Schlüssel entsteht auf dem Router
(wg genkey | wg pubkey) und gehört nicht
hierher. Eingetragen wird allein der öffentliche Teil, den das
Staging-Skript zurückmeldet.
Ohne Haken bleibt ein hinterlegter PresharedKey bestehen. Ist keiner hinterlegt, erzeugt der Server in jedem Fall einen.
Jetzt nicht noch einmal „Eintragen“. Ein zweiter Eintrag erzeugt einen neuen PresharedKey und macht den oben angezeigten im selben Moment wertlos — sichtbar wird das erst daran, dass der Tunnel später nicht zustande kommt. Zum Verlassen „Schließen“.
Standort archivieren
Archivieren nimmt die Geräte mit und sperrt den Peer; die Tunneladresse geht in Quarantäne, damit sie nicht sofort an einen anderen Standort fällt. Im Overlay wirksam wird das erst mit der nächsten angewandten Generation.
Geräte
Jedes Gerät bekommt eine eigene Herkunft — die Kennung ist zugleich der Hostname und deshalb global eindeutig und unveränderlich. Das Ziel wird als IP-Adresse im Gerätenetz des Standorts eingetragen, niemals als Name.
Kennung und Standort stehen mit dem Anlegen fest.
Gerät archivieren
Laufende Sitzungen auf dieses Gerät enden sofort, der Hostname wird nicht mehr bedient. Der Standort und sein Tunnel bleiben unberührt.
Personen-Peers
WireGuard-Zugänge von Menschen. Am Tunnel gibt es keinen zweiten Faktor — dafür endet jeder Zugang von allein. Der private Schlüssel erscheint in genau einer Antwort und wird nirgends gespeichert.
Frist verstrichen, aber noch im Kernel
Diese Peers gelten als abgelaufen, stehen auf dem Hub aber weiterhin im Kernel. Entfernt sind sie erst mit der nächsten angewandten Generation.
| Bezeichnung | Konto | Tunneladresse | Standorte | Gültig bis | Letzte Rückmeldung | Status | |
|---|---|---|---|---|---|---|---|
| Kein Personen-Peer vorhanden Zugriff läuft bis dahin ausschließlich über das Portal. Ein Peer wird angelegt, wenn jemand ein Werkzeug braucht, das der Browser nicht spricht. | |||||||
Personen-Peer anlegen
Das Schlüsselpaar entsteht auf dem Server, weil der WireGuard-Client keinen Rückkanal hat. Die Ausgabe erfolgt einmal.
Freigaben werden geladen…
Für dieses Konto ist in der Zuordnungsmatrix nirgends Netzzugang gesetzt. Erst unter „Nutzer & Rechte" freigeben — ein Peer darf nicht mehr können als die Zugriffssteuerung hergibt.
Erst ein Konto wählen.
Zugang ausliefern
Anleitung für Windows — was der Empfänger tun muss
Einrichtung unter Windows
Wird aus dem Datenbestand erzeugt…
Frist verlängern
Gerechnet ab jetzt, nicht ab dem bisherigen Ablauf — ein seit Wochen abgelaufener Peer soll nicht rückwirkend gültig werden.
Peer löschen
Der Eintrag verschwindet aus der Datenbank, die Tunneladresse geht in Quarantäne. Aus dem Kernel des Hubs fällt der Peer erst mit der nächsten angewandten Generation. Wer ihn sofort aussperren will, sperrt ihn und erzeugt danach eine Generation.
Relays
Protokoll-Relays auf dem Hub-Server: Sie lesen einzelne Geräte an einem Standort (etwa einen EAP B02 per Modbus) und stellen die Werte einer Leittechnik bereit. Jeder Weg ist eine einzelne Adresse. Der private Schlüssel entsteht auf dem Relay-Rechner, der PresharedKey erscheint einmal.
| Instanz | Kunde | Tunneladresse | Liest | Leittechnik | Letzte Rückmeldung | Status | |
|---|---|---|---|---|---|---|---|
| Kein Relay vorhanden Ein Relay wird angelegt, wenn Werte eines Geräts in einem anderen Protokoll oder einem anderen Netz gebraucht werden. | |||||||
Den öffentlichen Schlüssel auf dem Hub-Server abfragen:
umask 077; [ -e /etc/hartek-relay/<instanz>.key ] || wg genkey > /etc/hartek-relay/<instanz>.key; wg pubkey < /etc/hartek-relay/<instanz>.key
— ein vorhandener Schlüssel bleibt (beim Umzug einer Instanz von einem
eigenen Tunnel ist es der, den der Router für den Rückweg kennt).
Eingetragen wird die Ausgabe, nicht der Schlüssel des Hubs aus der Env-Datei.
wg-<instanz>, relay-netns@<instanz>
und ist danach nicht mehr änderbar.
Nicht abschreiben: Nach dem Anwenden der Generation holt
auf dem Hub-Server ihn ungesehen aus dem Portal und startet den Namensraum neu.
Nur ohne das Skript: in
ablegen (umask 077), dann den Namensraum neu starten — nie in eine
Nachricht.
Wird aus dem Datenbestand erzeugt…
Schlüssel des Relays
Relay löschen
Der Eintrag verschwindet samt Wegen, die Tunneladresse geht in Quarantäne. Aus dem Kernel des Hubs fällt das Relay erst mit der nächsten angewandten Generation.
Systeme
Maschinen, die selbst Geräte abfragen — heute der bacnet-monitor. Ein System erreicht einzelne Adressen an Standorten beliebiger Kunden und baut jede Verbindung selbst auf; zu ihm verbindet sich niemand. Der private Schlüssel entsteht auf der Maschine.
Der PresharedKey wird nie im Browser angezeigt. Er geht direkt vom Hub auf
die Maschine: docker exec fw-portal python -m tools.psk system <name>
— per Pipe über SSH, ohne Zwischendatei auf dem eigenen Rechner. Die
vollständige Pipe steht im Dialog „Env-Datei“ jedes Systems; auf Seiten
des bacnet-monitor beschreibt sie dessen BETRIEB.md (Fernwartungs-Tunnel
→ Einrichten, Schritt 3).
Nicht alles kommt in die nächste Generation
- —
| Name | Tunneladresse | Ziele | Letzte Rückmeldung | PresharedKey | Status | |
|---|---|---|---|---|---|---|
|
|
||||||
| Kein System vorhanden Ein System wird angelegt, wenn eine Maschine wie der bacnet-monitor Geräte an Standorten über den Hub abfragen soll. | ||||||
Den Schlüssel auf der Maschine erzeugen, im Konfigurationsverzeichnis
des Tunnel-Containers (ein vorhandener bleibt stehen):
install -d -m 700 /etc/hartek-fernwartung; (umask 077; [ -e /etc/hartek-fernwartung/private.key ] || wg genkey > /etc/hartek-fernwartung/private.key); wg pubkey < /etc/hartek-fernwartung/private.key
— eingetragen wird die Ausgabe, der öffentliche Schlüssel. Der private
bleibt auf der Maschine.
<bezeichnung>-<id>, ein
Bindestrich könnte einen Namen doppelt vergeben. Er wird zu
system.<name> und ist danach nicht mehr änderbar.
Auf der Maschine:
Wird aus dem Datenbestand erzeugt…
Der PresharedKey steht nicht darin. Er kommt per Pipe vom Hub auf die
Maschine, ohne Zwischendatei auf dem eigenen Rechner (hub
und maschine sind die SSH-Namen der beiden Rechner):
Schlüssel des Systems
Setzen erzeugt immer einen neuen PresharedKey, auch bei unverändertem öffentlichem Schlüssel. Der alte gilt auf dem Hub bis zur nächsten angewandten Generation; der neue gehört vorher per Pipe auf die Maschine — im Browser erscheint er nicht.
Neuer PresharedKey erzeugt — jetzt zuerst auf die Maschine.
Die nächste angewandte Generation trägt ihn auf dem Hub ein. Liegt er dann nicht auf der Maschine, trennt genau diese Generation das System vom Hub. Also: Pipe ausführen, dann die Generation anwenden, dann den Tunnel-Container auf der Maschine neu starten — er liest seine Schlüssel nur beim Start.
System löschen
Der Eintrag verschwindet samt Zielen, die Tunneladresse geht in Quarantäne. Aus dem Kernel des Hubs fällt das System erst mit der nächsten angewandten Generation.
Nutzer & Rechte
Konten, Rollen und die Zuordnung zu Standorten und Geräten. Interne Konten kommen an alles, was ihnen freigegeben ist; ein Kundenkonto kommt nie über den eigenen Mandanten hinaus — auch dann nicht, wenn versehentlich eine Einzelfreigabe eingetragen wurde. Ein Direktlink-Konto kommt an genau die Geräte, die in seiner Liste stehen, und an nichts sonst.
| Name | Klarname | Rolle | Kunde | Zweiter Faktor | Gültig bis | Letzter Login | Status | |
|---|---|---|---|---|---|---|---|---|
| intern | gesperrt | abgelaufen | Startpasswort | |||||
| Kein Konto sichtbar Entweder greift der Filter, oder es ist noch keines angelegt — „Konto anlegen“ ist der nächste Schritt. | ||||||||
Der Benutzername ist der Schlüssel des Kontos und lässt sich nicht ändern.
Dieses Konto trägt noch die Zuordnung zu . Über diesen Weg lässt sich eine bestehende Zuordnung nicht aufheben — die Mandantengrenze bleibt bis auf Weiteres bestehen.
Rechte
Mit dieser Auswahl berührt das Konto Liegenschaften. Der zweite Faktor wird damit Pflicht — ab sofort, für alle Geräte dieses Kontos. Beim Speichern enden alle laufenden Sitzungen; angemeldet wird danach nur noch mit einem Code aus einer Authenticator-App.
Der zweite Faktor ist jetzt Pflicht — ab sofort, für alle Geräte dieses Kontos. Alle Sitzungen sind beendet.
Zum Einrichten braucht das Konto einen Einrichtungscode von Hartek: 72 Stunden gültig, einmal verwendbar.
Die Auswertung lautet: deny schlägt allow schlägt Standortfreigabe schlägt implizites Nein. Eine leere Zuordnung heißt „nichts“, nicht „alles“ — ein Konto ohne Eintrag sieht kein einziges Gerät.
Für ein Direktlink-Konto gilt nur deny schlägt allow schlägt Nein. Die Standortfreigabe wird für diese Rolle nicht ausgewertet — sie ist deshalb unten gar nicht erst zu setzen. Was das Konto erreichen soll, steht einzeln unter „Geräte“.
Zugriff braucht ein Adminkonto hier nicht: es kommt ohnehin an jedes Gerät, der Haken ist gespeichert, wird für diese Rolle aber nicht ausgewertet.
Netzzugang ist etwas anderes. Ihn liest das Portal beim Anlegen und Ändern eines Personen-Peers unmittelbar aus dieser Zuordnung — ohne Ausnahme für die Rolle. Fehlt er für einen Standort, lehnt es den Peer ab, auch für dieses Konto.
Zuordnung wird geladen…
Standorte
„Zugriff“ öffnet die Weboberflächen der Geräte dieses Standorts. „Netzzugang“ ist mehr: er ist die Voraussetzung für einen Personen-Peer, also für WireGuard ins Standortnetz.
Ein Personen-Peer legt diesen Kunden direkt ins Overlay-Netz und umgeht damit Protokollierung und Sitzungsentzug des Portals. Für die Weboberflächen wird er nicht gebraucht.
Heutige Geräte einer Liegenschaft
Gibt die Geräte, die heute an einer Liegenschaft stehen und aktiv sind, einzeln frei — sofort, ohne „Speichern“. Was später dazukommt, bleibt zu, und ein deny bleibt stehen. Routeroberflächen bleiben aus, solange der Haken fehlt: wer sie bedient, bedient den Tunnel.
Nur für Abweichungen von der Standortfreigabe. „allow“ öffnet ein einzelnes Gerät ohne den Standort, „deny“ sperrt es trotz Standort.
Hier steht, was dieses Konto öffnen darf — nicht eine Ausnahme, sondern die Freigabe selbst. „allow“ je Anlage, die es erreichen soll; alles Übrige bleibt zu.
Einrichtungscode
Code wird erzeugt…
Konto löschen
Das Konto und seine Zuordnungen verschwinden. Die Protokolleinträge bleiben — sie tragen den Benutzernamen im Klartext und überleben die Löschung. Vorhandene Personen-Peers werden dadurch nicht aus dem Overlay entfernt; das braucht eine neue Generation.
Konfiguration
Der Weg vom Datenbestand in den Kernel führt über drei Stufen: die Vorschau rechnet rein lokal, der Trockenlauf lässt den Hostdienst rendern und prüfen, erst das Anwenden fasst den Kernel an. Was hier ausgelöst wird, gilt für alle Standorte gleichzeitig.
Bestätigung ausgeblieben
1 · Kernelzustand
Was tatsächlich im Kernel stehtDer Hostdienst ist nicht erreichbar.
Ohne Isolationstabelle sehen alle Standorte einander.
Die Trennung der Kundennetze hängt allein an dieser Tabelle. Solange sie fehlt, kann jedes Gerät jedes andere erreichen — hier gehört sofort eine Generation angewandt oder zurückgerollt.
Der Kernel enthält etwas anderes als die letzte Generation. Entweder wurde von Hand eingegriffen oder eine Anwendung ist unvollständig geblieben. Die folgenden Schlüssel stehen auf genau einer der beiden Seiten:
Zähler der Isolationstabelle
| Zähler | Pakete |
|---|---|
| Kein Zähler gemeldet Entweder steht die Isolationstabelle noch nicht oder sie hat bisher nichts verworfen — den Kernelzustand oben prüfen. | |
2 · Vorschau
Lokal gerechnet, ohne den HostdienstBeim Bauen der Generation aufgefallen:
Es ändert sich Schlüsselmaterial, sonst nichts. Unten steht deshalb kein Unterschied — der Bestand führt keine Schlüssel, ein PresharedKey taucht dort nie auf.
Anwenden ist trotzdem nötig: sonst behält der Kernel den alten Schlüssel, während das Gerät schon den neuen trägt. Der Tunnel käme dann nicht zustande, ohne dass irgendwo ein Fehler stünde.
Unterschied zur angewandten Generation
Kein Unterschied. Bei der allerersten Generation ist das erwartbar: es gibt noch keinen Stand, gegen den gerechnet werden könnte.
Noch keine Vorschau berechnet.
Trockenlauf bestanden. Der Hostdienst hat gerendert und beide Ebenen gegen den Kernel geprüft, ohne etwas zu ändern.
Trockenlauf abgelehnt.
Zurückrollen
Setzt den Kernel auf den letzten gesicherten Stand zurück. Das ist der Weg heraus, wenn eine angewandte Generation den Zugang gekappt hat — und nicht Teil des normalen Ablaufs.
Generationen
Die letzten 50| ID | Erzeugt | Von | Anlass | Ergebnis | Prüfsumme | |
|---|---|---|---|---|---|---|
| Noch keine Generation erzeugt Die Vorschau oben prüfen und anwenden — erst dann steht der Datenbestand im Kernel. | ||||||
Adressquarantäne
Eine freigewordene Tunneladresse bleibt dreißig Tage gesperrt. Ein gelöschter Router läuft an seinem Standort oft noch wochenlang weiter und schickt unter der alten Adresse Pakete; würde sie sofort neu vergeben, landeten diese Pakete beim falschen Kunden.
| Adresse | Frei ab | Grund |
|---|---|---|
| Keine Adresse gesperrt Jede Adresse des Bereichs steht zur Vergabe bereit — hier ist nichts zu tun. | ||
Generation anwenden
Peers, Freigaben
Der Anlass wandert unverändert ins Protokoll. Die Frage, die im Zweifelsfall gestellt wird, lautet nicht „was stand im Kernel", sondern „warum stand es an dem Tag so".
Der Hostdienst rollt binnen zwei Minuten von selbst zurück, wenn die Bestätigung ausbleibt. Das greift genau dann, wenn diese Änderung den Weg kappt, über den sie bestätigt werden müsste.
Zurückrollen
Auf den letzten gesicherten Stand
Der Kernel bekommt wieder die Konfiguration der vorletzten Generation. Alles, was seither angewandt wurde, ist damit weg — auch neu aufgenommene Standorte.
Bestand der Generation
Wird geladen …
Ergebnis: — der Abzug wird bei jeder Generation mitgeschrieben, weil die Konfigurationsdateien selbst auf dem Host liegen.
Zugriffsprotokoll
Wer war wann auf welchem Gerät, was hat er dort getan, und wem wurde etwas verweigert. Festgehalten werden Seitenaufrufe, schreibende Zugriffe, Fehler und Ablehnungen — nicht jedes einzelne Asset einer Visualisierung.
Die Abfragezeichenkette steht bereits redigiert in der Datenbank, nicht erst in der Anzeige. Ein DEOS-Regler trägt sein Klartextpasswort im Query; eine Redaktion, die nur die Darstellung beträfe, ließe es trotzdem in der Tabelle und in jedem Backup liegen.
Einträge
| Zeitpunkt | Konto | Aktion | Gerät | Anfrage | Abfrage | Status | Dauer | Client-IP | Detail |
|---|---|---|---|---|---|---|---|---|---|
| Keine Einträge im gewählten Ausschnitt Zeitraum erweitern oder Aktion, Konto und Gerät auf „alle“ zurücksetzen. | |||||||||