Ihr VPN-Gateway braucht weiterhin einen Weg, Updates zu installieren

Der Tunnel funktioniert für alle dahinter, das Gateway leitet ihren Datenverkehr weiter, und doch kann die Maschine selbst kein Sicherheitsupdate installieren. Das ist die übliche Form des Problems: Die Weiterleitungsberechtigung wurde den Clients erteilt, und die eigenen ausgehenden Verbindungen des Gateways wurden nie in den Plan aufgenommen. Der Paketmanager öffnet seine eigenen Sockets vom Gateway zu einem Repository, das Sie in der Firewall-Richtlinie wahrscheinlich nirgends benannt haben.

Ein Gateway abzuhärten ist richtig. Es so gründlich abzuhärten, dass es keine Patches mehr erhält, ist eine andere Entscheidung – und meistens eine versehentliche.

Lokaler Ausgang ist keine Client-Weiterleitung

Weiterleitungsregeln gelten für Pakete, die von anderswo ankommen und das Gateway verlassen. Der eigene Update-Verkehr des Gateways passt nie darauf; er entsteht lokal und nimmt den Ausgangspfad. Dieser Unterschied erklärt einen Fehler, der unmöglich wirkt, während der Client-Zugriff einwandfrei funktioniert.

Er erklärt auch eine Richtlinienlücke, die Tests übersteht, weil ein schneller Test von einem Laptop hinter dem Tunnel beweist, dass die Forward-Kette funktioniert, und nichts über die eigenen Verbindungen des Hosts aussagt. Betrachten Sie das Gateway als zwei Subjekte: einen Router mit einer Forward-Kette und einen Host mit einer Output-Kette. Beide brauchen eine Entscheidung, und nur eine davon wird normalerweise schriftlich festgehalten.

Benennen Sie die Stufe, die fehlgeschlagen ist

Update-Fehler benennen unterschiedliche Grenzen, und wer nach einer Portregel greift, bevor er liest, welche davon fehlgeschlagen ist, verliert einen Nachmittag. Ein Repository-Name, der sich nicht auflösen lässt, ist eine Resolver-Frage, keine Transportfrage.

getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update

Eine Zeitüberschreitung nach erfolgreicher Namensauflösung verschiebt die Frage auf den Transport: welche Adresse, welcher Port und welcher konfigurierte Proxy vom Paketmanager tatsächlich versucht wurden. Ein TLS-Verifikationsfehler ist etwas völlig anderes, und er bedeutet, dass die Verbindung gut genug funktionierte, um zu verhandeln. Eine Beschwerde über die Archivauthentifizierung ist die vierte Stufe, und sie betrifft signierte Metadaten statt Erreichbarkeit. Vier Stufen, vier verschiedene Reparaturen, und ein Ping beschreibt immer nur ein Protokoll, das kein Paketmanager verwendet.

Erst die Quellenliste lesen, dann eine Regel hinzufügen

Listen Sie die tatsächlichen Quell-URIs und die wirksame Proxy-Konfiguration auf, nicht die, an die Sie sich erinnern. Eine Regel für einfaches HTTP ist nutzlos, wenn die Quelle HTTPS ist, und ein Proxy, den die Shell kennt, kann für einen beim Start mit anderer Umgebung gestarteten Dienst unsichtbar sein.

Die Dokumentation des HTTP-Transports von APT behandelt Umgebungs- und APT-spezifische Proxy-Einstellungen, einschließlich Auswahl pro Host, und ihr HTTPS-Transport hat eigene Verifikationseinstellungen. Der Weg eines Browsers und der Weg des Paketmanagers sind getrennte Wege, selbst auf derselben Maschine.

Beachten Sie, auf welche Adressfamilien die Quellen auflösen. Eine Regel, die nur IPv4 erlaubt, wird auf einem Host weiterhin scheitern, dessen Quellen einen AAAA-Eintrag bevorzugen, und der Fehler wirkt sporadisch, weil er davon abhängt, welche Antwort zuerst eintrifft.

Einen Wartungspfad wählen und beibehalten

Es gibt drei vertretbare Optionen: Wartungsverkehr durch den Tunnel, durch einen verwalteten Update-Proxy oder durch eine schmale direkte Ausnahme. Wählen Sie eine bewusst und sorgen Sie dafür, dass der Resolver damit übereinstimmt, denn eine Trennung, bei der Namen in eine Richtung auflösen und Verbindungen in eine andere gehen, erzeugt Fehler, die niemand erklären kann.

Was Sie auch wählen, es darf nicht zu einem uneingeschränkten Auffangnetz werden. Wenn direkter ausgehender Verkehr verboten ist, während der Tunnel nicht läuft, ist eine Wartungsausnahme, die stillschweigend alles erlaubt, eine als Reparatur getarnte Richtlinienänderung. Halten Sie den eigenen Endpunkt des Tunnels und seinen Bootstrap-Bedarf in einer separaten Kategorie vom Repository-Zugriff, weil sie auf verschiedene Ziele zeigen und auf verschiedene Weise scheitern, sodass eine Ausnahme die andere nicht abdecken kann.

Prüfen, ohne die Kontrollen abzuschwächen

Setzen Sie den Geltungsbereich über die Firewall um, die die Richtlinie bereits führt, statt einen zweiten Manager hinzuzufügen, weil ein Leitfaden ihn verwendet hat. Führen Sie dann eine Metadaten-Aktualisierung und eine echte Pakettransaktion unter der gepflegten Richtlinie aus, und lesen Sie die Ausgabe, nicht nur den Exit-Status.

Ein erfolgreicher Transport ist keine Erlaubnis, die Verifikation zu lockern. Archivauthentifizierung und die Identität des TLS-Servers sind getrennte Garantien, und eine davon abzuschalten, um einen Fehler zum Schweigen zu bringen, ändert, was Sie vertrauen, nicht, was Sie erreichen können.

Testen Sie zum Schluss bewusst den Fall ohne Tunnel. Zu wissen, wie sich das Gateway ohne seinen Tunnel verhält, gehört zum Entwurf, es während einer Störung herauszufinden nicht. Fahren Sie den Tunnel herunter, führen Sie die Metadaten-Aktualisierung aus und bestätigen Sie, dass der Host auf die beabsichtigte Weise scheitert, statt stillschweigend auf einen offenen Pfad zurückzufallen. Halten Sie Repository- und Proxy-Anmeldedaten aus gemeinsam genutzten Diagnosen heraus und hinterlassen Sie eine Notiz, die benennt, wem der Update-Pfad gehört.