Update des VPN-Gateways schlägt fehl: erst die Stufe lesen, dann den Ausgang öffnen
Ein fehlgeschlagenes Update nennt eine Stufe, nicht einen fehlenden Port. Ordnen Sie die Meldung ihrem Eigentümer zu, lesen Sie den Proxy-Pfad und entscheiden Sie dann bewusst über die Wartungsrichtlinie.
Sich zu weigern, Sicherheitsupdates zu installieren, ist nur eine schlechte Woche davon entfernt, jemand anderes Problem zu werden, und ein Gateway, das Clients zulässt, ist der einfachste Ort, diese Gewohnheit zu entwickeln. Die übliche Ursache ist keine fehlende Route, sondern eine fehlende Entscheidung: Niemand hat gesagt, wie der Host selbst ein Repository erreichen soll, wenn die Client-Weiterleitung bewusst eng gefasst ist. Diese Entscheidung muss ausdrücklich getroffen werden, und sie muss enger sein, als die Ausgangsrichtlinie für einen Nachmittag abzuschalten.
Vier Stufen, vier verschiedene Eigentümer
Ein Update-Fehler ist eine benannte Stufe, ob die Meldung das sagt oder nicht, und jede Stufe gehört einem anderen Eigentümer. Ein Name, der sich nicht auflösen lässt, ist eine Frage an den Resolver. Eine Verbindung, die in einen Timeout läuft, ist eine Frage an Transport, Proxy oder Gegenstelle. Ein TLS-Identitätsfehler ist eine Vertrauensfrage, und zurückgewiesene Archiv-Metadaten sind eine Signaturfrage. Vier Stufen, vier Eigentümer, und eine Portregel beantwortet immer nur eine davon.
| The failure text mentions | Which component owns it | What you check first | What you must not change |
|---|---|---|---|
| a name that will not resolve | the resolver policy for this host | which resolver is used, and whether its path is permitted | nothing in the firewall: no repository packet has left yet |
| a connection that times out | routing, proxy or the far end | the destination, port and proxy the manager actually attempts | the egress policy, before you know that destination |
| a TLS identity mismatch | trust configuration and the server's identity | the chain the manager is presented with | verification settings, which only hide the mismatch |
| rejected archive metadata | the repository's signing metadata | whether the source carries valid, trusted metadata | the signature check, which is not a routing question |
Ping und Namensauflösung sind die beiden Tests, zu denen Menschen zuerst greifen, und beide beantworten Fragen, die niemand gestellt hat. Eine Echo-Antwort nutzt ein anderes Protokoll als die Repository-Verbindung, und eine erfolgreiche Namensauflösung endet bei der Namensauflösung, ohne den Abruf zu testen. Beides kann bestehen, während die eigentliche Transaktion scheitert, und beides kann aus Gründen scheitern, die mit dem Pfad nichts zu tun haben.
Lesen Sie den Pfad, den der Manager tatsächlich nimmt
Prüfen Sie die konfigurierten Quell-URIs und die tatsächlich wirksame Proxy-Regelung, statt eines von beiden anzunehmen. Eine Regel für reines HTTP ist keine Reparatur, wenn das Repository HTTPS spricht, und eine Organisation, die einen Proxy vorschreibt, hat den Pfad bereits gewählt. Paketmanager beachten Umgebungsvariablen und ihre eigene Konfiguration, und hostspezifische Einstellungen können eine globale überschreiben. Was ein interaktiver Browser tut, muss nicht das sein, was der Manager tut.
apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxyDie APT-Transportdokumentation beschreibt, welche Einstellungen für welches URI-Schema gelten und wie hostspezifische Entscheidungen geschrieben werden. Bewahren Sie die Ausgabe der Befehle beim Ticket auf, denn sie trennt ein Proxy-Problem schneller von einer fehlenden Route als jede Anzahl von Ping-Ergebnissen. Notieren Sie das genaue Ziel, den Port und das Protokoll, das der Manager versucht, und lassen Sie die Firewall-Änderung auf dieser Aufzeichnung beruhen statt auf einer geratenen Spiegeladresse, die innerhalb von Monaten veraltet.
Wählen Sie eine Wartungsrichtlinie, keine Ausnahme
Drei Richtlinien sind vertretbar: über den Tunnel warten, über einen verwalteten Update-Proxy warten oder über eine eng autorisierte direkte Route warten. Jede impliziert eine Resolver-Regelung, die dazu passt. Nicht vertretbar ist eine Ausnahme, die stillschweigend zu einem unbeschränkten Rückfallweg wird, sobald der Tunnel ausfällt.
Schreiben Sie die gewählte Richtlinie mit einem Eigentümer auf, denn der nächste Betreiber findet die Regel und nicht die Begründung dahinter. Erteilen Sie die Berechtigung über die bestehende Firewall und den Netzwerk-Eigentümer, statt Regeln zu leeren oder einen zweiten Policy-Manager für einen Host hinzuzufügen. Decken Sie die Adressfamilien und Dienstendpunkte ab, die die echte Quelle nutzt, und überprüfen Sie die Liste, wenn das Repository umzieht.
Prüfen, ohne das Vertrauen zu schwächen
Ein erfolgreicher Transport ist keine Erlaubnis, die Prüfung zu lockern: Archiv-Authentifizierung und TLS-Serveridentität sind zwei verschiedene Prüfungen, und das Abschalten einer von beiden lässt einen Fehler verschwinden, während sich ändert, was der Host akzeptiert. Ein abfangender Proxy ist eine Vertrauensentscheidung des Netzwerk-Eigentümers und kein Grund, die Prüfung lokal abzuschalten, und Repository-Anmeldedaten gehören nicht in geteilte Diagnosedaten, denn ein ausführliches Protokoll ist die einfachste Stelle, sie preiszugeben.
Akzeptieren Sie die Änderung mit einem kontrollierten Metadatenabruf, gefolgt von einer genehmigten Pakettransaktion, und testen Sie dann, was passiert, wenn der Tunnel wegbricht. Ein Wartungspfad, der sich während einer Störung stillschweigend erweitert, ist schlechter als einer, der geschlossen scheitert, und das Ergebnis sollte ein Update-Pfad mit einem benannten Eigentümer und einem begrenzten Umfang sein.