Update Proxy Template über VPN funktioniert nicht

In your language Deutsch (German)
1

Moin,

ich bin endlich von Linux Mint auf Qubes OS umgestiegen und erwartungsgemäß ergeben sich ein paar Probleme. Ich habe es gestern geschafft, meine VPN-Verbindung mittels eines eigenen Qubes einzurichten, funktioniert auch. Habe es mit der Anleitung auf Github gemacht (CLI Variante).

Nun wollte ich als nächsten Schritt die Updates für die Templates über den VPN laufen lassen. Das klappt leider nicht. Original sieht meine UpdatesProxy-Datei so aus:

$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:whonix-updatevm $anyvm deny

Das finde ich schon merkwürdig: Als ich recherchiert hatte, da haben die Leute den Inhalt ihrer UpdatesProxy-Dateien gezeigt und da war viel mehr drin. Nun gut, ich habe die Datei bearbeitet und sie sieht jetzt so aus:

$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:whonix-updatevm $anyvm deny

$type:TemplateVM $default allow,target=sys-vpn-de
$anyvm $anyvm deny

Also so, wie es in der Dokumentation steht (außer dass dort “@” am Anfang steht, nicht “$”, aber ich habe bei der Recherche beide Varianten gesehen…).
Wenn ich sys-vpn-de abschalte, das Template (Debian) starte und “sudo apt update” ausführe, dann wird sys-vpn-de auch gestartet, aber da kommen dann Fehlermeldungen (über sys-net, also Standard, funktioniert es einwandfrei):

Es kommen 3 Error-Meldungen, die im Prinzip sagen: “Invalid response from proxy: HTTP/1.0 500 Unable to connect Server: tinyproxy/1.10.0”
Danach kommen ganz normale Sachen wie “240 packages can be upgraded”. Dann kommen wieder 3 Zeilen:

“W: Failed to fetch [dann ein debian.org-Link] Invalid response from proxy” usw.

Das dann dreimal mit verschiedenen debian.org und qubes-os.org Links und ganz zum Schluss:

“W: Some index files failed to download. The have been ignored, or old ones used instead.”

Wenn ich in einer AppVM mit sys-vpn-de “sudo apt update” ausführe, wird das ganz normal ausgeführt. Nur im Template halt nicht. Was habe ich falsch gemacht?

Ich entschuldige mich für den langen Text und bedanke mich schonmal im Voraus, für die Zeit von euch.

Gruß

2

Dass ihr immer die in Qubes automatisch konfigurierten Sachen auskommentieren müsst und ein neues Rad zum schon bestehenden erfinden müsst… :smiley:
Reicht es (Dir) nicht die Updates über den schon geschützten Weg (sys-whonix) zu managen - das mag bisschen langsam sein, aber es läuft und es gibt so gut wie kaum Probleme.

Ich würde jetzt nochmal folgenden Vorschlag probieren:

Deine gemachten Änderungen in der Datei rückgängig machen (auskommentieren) und schauen, ob die Updates über sys-whonix (immer noch) laufen. Klappt das, dann würde ich unter:

Qubes Manager > Menu > Settings > UpdateVM = sys-vpn-de

setzen und schauen, ob das funzen würde.

1 Like
3

Danke für deine Antwort. Auskommentiert habe ich nichts, die Originaldatei besteht nur aus den ersten beiden Zeilen mit “whonix-updatevm” usw. Aber da steht ja nichts mit “type=Template”. Werden die Templates nicht standardmäßig über sys-net geupdatet?

Und bei Settings im Debian-Template (so wie auch bei allen anderen Qubes-Settings) finde ich den Punkt “UpdateVM” nicht, nur bei den Globalen Einstellungen kann ich für dom0 entsprechendes auswählen. Oder habe ich falsch geguckt?

Gruß

4

Nein ist schon so, für alle Templates wurde vom Qubes Team eine entsprechende UpdateVM geplant, die immer gleich für alle wäre. Bei der Installation des OS muss man quasi entscheiden, ob man die Updates über sys-whonix oder über sys-firewall (hier wird vorausgesetzt, dass sys-firewall an sys-net angebunden ist) beziehen möchte.
Was an der Stelle nicht gesagt, aber später in Foren oder der Qubes Dokumentation behandelt wird, ist die Tatsache, dass das Qubes Team eigentlich zwingend das Updaten über die eingebaute Salt Update Routine “Qubes Updates” vorschlägt. Es würde zwar auch funktionieren, dass man im Qubes Manager mit Rechtsklick auf das jeweilige Template und > Update (oder in Einzelfällen auch über die Terminals der Templates), die Update Prozedur auslöst. Das entspricht aber nicht den Sicherheitsrichtlinien und führt am Ende am Sicherheitskonzept von Qubes vorbei und kann wohl in Extremfällen zu Fehlern führen. Auf die Fragen nach diesen Extremfällen oder Fehlern schweigt sich Qubes allerdings aus. Ich lese nur immer die Warnungen “dass man doch ja die eingebaute Qubes Update Funktion nutzen soll!!!” und bin irgendwann dazu übergegangen diese Weisung zu befolgen … auch um mich innerhalb der Qubes Richtlinien zu bewegen. Weiß der Geier, wozu das irgendwann mal gut ist.

Hier im Forum wurde schon von den Qubes Cracks probiert das ganze Update Prozedere über einen Cacher zu organisieren (mit dem Effekt, dass man für eine Masse gleicher Templates [z.B. Debian] die Updates nur einmal runterläd [chached] und dann halt alle Debians [oder Fedoras] in einem Rutsch aktualisiert), aber der Rotz klappt auch (noch) nicht so, wie es soll und dann steht man wieder da und schwört sich, dass man doch besser die derzeit von Qubes vorgegebenen Weisungen und Funktionen benutzen sollte um halt (wie gewünscht/nach eigenem Befinden) privat und unauffällig durchs Netz wandeln kann.
Verbesserungen sind in Arbeit, aber vor Version 4.2 ist jetzt nichts Großes zu Erwarten.

5

Ok, danke für die ausführliche Antwort. Also man sollte keine “einzelnen” Updates machen, sondern über Qubes Updates. Gut zu wissen.

Bei der Geschichte mit “qubes.UpdatesProxy” verstehe ich aber immer noch nicht, wieso überall steht, man muss die Zeile mit “$type=Template” und am Ende halt die NetVM, die man dafür nutzen will, hinzufügen. Ich habe jetzt mal bei meinem hinzugefügten Text am Ende “sys-whonix” eingegeben und dann funktioniert es reibungslos. Er startet bei “apt Update” sys-whonix und es kommen dann keine Fehlermeldungen. Nur wenn ich es dann wieder mit sys-vpn-de probiere. Ich will verstehen, warum.
Was hat es denn mit den Diensten “qubes-updates-proxy” und “updates-proxy-setup” aufsich? Ich habe die Dienste bei sys-vpn-de bzw. im Debian-Template aktiviert, aber es hilft ja nichts (auch ohne nicht). Bei sys-whonix sind diese Dienste auch nicht drin, aber damit funktioniert es ja.

Was ich auch nicht verstehe ist: Als ich die sys-vpn-de eingerichtet habe und manuell OpenVPN gestartet habe, da kam dann oben, so wie es soll, auch die Meldung “LINK IS UP” und beim Abschalten “LINK IS DOWN!”. Aber beim automatischen Herstellen der VPN-Verbindung kommen die Meldungen nicht mehr. Würde mich auch interessieren, warum…

Gruß

6

Hmm, kann jetzt nur indirekt helfen, da ich mir des vollständigen Hintergrunds auch nicht vollens bewusst bin, um hier direkte Hilfe anbieten zu können. Fakt ist, dass den Templates die Internetverbindung weggenommen worden ist bzw. halt die Grundregel besteht, dass Templates niemals mit dem Internet direkt in Verbindung zu stehen haben.
Deshalb wird das Updaten quasi über einen Proxy Port gelöst (weiß die Nummer grade nicht) und darüber empfangen die Templates dann die Updates.

Eventuell mal hier noch einmal nachlesen, ich war zu faul…

7

@hannes

Konnten deine Fragen bereits vollumfänglich beantwortet werden oder benötigst du weitere Unterstützung? Falls es beantwortet sein sollte, bitte diesen Thread als “Erledigt” markieren. Danke.