CT 102 — Management-Desktop (Browser-VNC) — Rebuild-Runbook

Zweck: gemeinsamer grafischer Zugang (für Nutzer + Ehefrau) zu allen Web-Oberflächen, ohne die RDP-Session von PC1 zu belegen (Windows Pro erlaubt nur eine aktive Sitzung).

1. Container erstellen

pct create 102 local:vztmpl/debian-13-standard_13.6-1_amd64.tar.zst \
  --hostname browser \
  --unprivileged 1 \
  --cores 2 \
  --memory 1536 \
  --swap 512 \
  --rootfs local-lvm:6 \
  --net0 name=eth0,bridge=vmbr0,ip=<LAN_IP_DESKTOP>/24,gw=<LAN_IP_ROUTER> \
  --features nesting=1 \
  --timezone Europe/Berlin \
  --onboot 1 \
  --nameserver <LAN_IP_ADGUARD>
pct start 102

2. TUN-Device für Tailscale (siehe `01-pve-host.md`, Abschnitt 8)

pct stop 102
cat >> /etc/pve/lxc/102.conf <<'EOF'
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file 0 0
EOF
pct start 102

3. Desktop-Umgebung + Browser + VNC

pct exec 102 -- apt-get update
pct exec 102 -- apt-get install -y curl ca-certificates
pct exec 102 -- apt-get install -y xfce4 xfce4-terminal firefox-esr tigervnc-standalone-server tigervnc-common dbus-x11 fonts-liberation

VNC-Konfiguration:

pct exec 102 -- mkdir -p /root/.config/tigervnc
VNCPASS="<VNC-Passwort>"
pct exec 102 -- bash -c "printf '%s\n%s\nn\n' '$VNCPASS' '$VNCPASS' | vncpasswd -f > /root/.config/tigervnc/passwd && chmod 600 /root/.config/tigervnc/passwd"

pct exec 102 -- bash -c "cat > /root/.config/tigervnc/xstartup <<'EOF'
#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
exec startxfce4
EOF
chmod +x /root/.config/tigervnc/xstartup"

⚠️ NICHT TUN: Config unter ~/.vnc/ anlegen. Neuere TigerVNC-Versionen erwarten ~/.config/tigervnc/ (XDG-Standard) und versuchen beim Start eine automatische Migration von ~/.vnc/, die zuverlässig fehlschlägt ("Could not migrate ... to ... tigervnc", Dienst crasht in einer Neustart-Schleife). Config direkt im neuen Pfad anlegen, ~/.vnc/ gar nicht erst befüllen.

Systemd-Service:

cat > /etc/systemd/system/vncserver.service <<'EOF'
[Unit]
Description=TigerVNC Server
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/root
ExecStartPre=-/usr/bin/vncserver -kill :1
ExecStart=/usr/bin/vncserver -fg -localhost no -geometry 1600x900 -depth 24 :1
ExecStop=/usr/bin/vncserver -kill :1
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable --now vncserver

-localhost no ist Pflicht — sonst nimmt TigerVNC nur lokale Verbindungen an, Guacamole (auf einer anderen Maschine) käme nicht durch.

4. Firefox-Profil + Startseiten

pct exec 102 -- bash -c "DISPLAY=:1 firefox-esr -CreateProfile 'default /root/.mozilla/firefox/default'"

pct exec 102 -- bash -c "cat > /root/.mozilla/firefox/default/user.js <<'EOF'
user_pref(\"browser.startup.homepage\", \"http://adguard.pve|https://<PVE_HOSTNAME>.<TAILNET>|http://nas.pve:8080|https://guac.<DOMAIN>|https://vaultwarden.<TAILNET>\");
user_pref(\"browser.startup.page\", 1);
user_pref(\"browser.tabs.warnOnClose\", false);
EOF
"

⚠️ NICHT TUN: sich darauf verlassen, dass dieses manuell erstellte default-Profil auch tatsächlich benutzt wird. firefox-esr legt beim allerersten echten Start (nicht beim -CreateProfile-Aufruf, sondern beim ersten normalen Öffnen über die GUI) automatisch ein zusätzliches Profil an (Name-Muster <zufallsstring>.default-esr) und trägt es in profiles.ini unter einem [InstallXXXX]-Block mit Locked=1 als tatsächlichen Standard ein — das überschreibt die klassische Default=1-Markierung des manuell erstellten Profils. Ergebnis: die user.js im manuellen Profil wird nie gelesen, Startseiten erscheinen einfach nicht, ohne Fehlermeldung.

Nach dem ersten echten GUI-Start prüfen und ggf. korrigieren:

cat /root/.mozilla/firefox/profiles.ini   # zeigt unter [InstallXXXX] den tatsächlich genutzten Profil-Pfad
cp /root/.mozilla/firefox/default/user.js /root/.mozilla/firefox/<echter-profil-ordner>/user.js

Öffnet beim Start automatisch: AdGuard, PVE-Weboberfläche, NAS-Filebrowser, Guacamole, Vaultwarden.

5. Tailscale-Mitgliedschaft

pct exec 102 -- bash -c "curl -fsSL https://tailscale.com/install.sh | sh"
pct exec 102 -- tailscale up --authkey=<AUTH_KEY> --hostname=browser --accept-routes=false

⚠️ NICHT TUN: --accept-routes (ohne =false) setzen. Siehe 01-pve-host.md, Abschnitt 9 — der Container sitzt selbst schon im <LAN_SUBNET>-LAN, das Akzeptieren der vom PVE-Host advertisten Subnet-Route erzeugt einen Policy-Routing-Konflikt (Tabelle 52), der die eigene LAN-Erreichbarkeit über Timeouts killt. Peer-zu-Peer zu anderen Tailnet-Mitgliedern (z.B. Vaultwarden) funktioniert auch ohne --accept-routes.

6. Guacamole-Verbindung (auf dem VPS, siehe `06-vps-strato.md`)

VNC-Verbindung "Management-Desktop (Browser)", Hostname zeigt auf die Tailscale-IP des Containers (<TS_IP_DESKTOP>), nicht die LAN-IP — damit läuft die Backend-Strecke Guacamole↔VNC-Server über den WireGuard-verschlüsselten Tailscale-Tunnel statt übers offene LAN.

⚠️ Bekannte Einschränkung: Guacamoles VNC-Protokoll-Implementierung unterstützt kein TLS/Zertifikat (anders als RDP mit security/ignore-cert-Parametern) — das ist eine echte Protokoll-Grenze, keine Fehlkonfiguration. Der Tailscale-Tunnel ist der bestmögliche Ersatz dafür.

7. Downloads aus der VNC-Sitzung aufs lokale Gerät übertragen

Ein Download in Firefox innerhalb der Guacamole-VNC-Sitzung landet zunächst nur auf CT 102 selbst (/root/Downloads), nicht automatisch auf dem tatsächlichen Endgerät des Nutzers. Fix: dedizierter, stark eingeschränkter SFTP-Only-User als Guacamole-Begleitverbindung.

useradd -M -s /usr/sbin/nologin transfer
echo 'transfer:<Passwort>' | chpasswd

cat >> /etc/ssh/sshd_config <<'EOF'

Match User transfer
    ChrootDirectory /root/Downloads
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no
EOF

mkdir -p /run/sshd
systemctl restart ssh

⚠️ NICHT TUN: nach einer sshd_config-Änderung systemctl reload ssh statt restart verwenden. Reload löst ein SIGHUP-getriggertes Re-Exec des laufenden sshd-Prozesses aus, ohne die vollständige systemd-Start-Sequenz zu durchlaufen — dabei fehlt /run/sshd (Privilege-Separation-Verzeichnis), Ergebnis: fatal: Cannot bind any address, Dienst stirbt komplett. Immer restart nutzen (oder mkdir -p /run/sshd vor einem Reload sicherstellen).

/root/Downloads erfüllt die OpenSSH-Chroot-Anforderungen bereits von selbst (root:root, kein Gruppen-/Other-Schreibrecht, Standard-Firefox-Download-Ziel für root).

In Guacamole die bestehende VNC-Verbindung um SFTP-Begleitparameter ergänzen (gleiche Tailscale-IP wie der Hostname-Parameter, aus Konsistenzgründen — sonst liefe der Dateiinhalt beim Download plaintext übers LAN, während die VNC-Steuerung schon verschlüsselt tunnelt):

enable-sftp = true
sftp-hostname = <TS_IP_DESKTOP>
sftp-port = 22
sftp-username = transfer
sftp-root-directory = /

Passwort nicht als Parameter setzen — wird beim ersten Datei-Transfer-Zugriff im Guacamole-Seitenpanel abgefragt.

Verifikation

nc -zv -w3 <TS_IP_DESKTOP> 5901   # sollte "open" zeigen (von einem Tailnet-Mitglied aus)
pct exec 102 -- systemctl is-active vncserver
pct exec 102 -- systemctl is-active ssh
sftp transfer@<LAN_IP_DESKTOP>   # sollte nach /root/Downloads chrooten (pwd zeigt "/")

7.4 KiB Raw Blame History