Websites laden über das VPN, aber apt erreicht das Repository nicht

Ein Browser, der über das VPN funktioniert, sagt nichts über die Proxy-Einstellungen von apt aus. Lesen Sie die fehlschlagende Stufe, geben Sie die wirksame Konfiguration aus und setzen Sie dann den Proxy, den apt liest.

Das VPN verbindet sich, das interne Wiki lädt im Browser, und apt update hängt weiter an einem Mirror, den es nicht erreichen kann. An diesem Bild ist nichts am Tunnel kaputt. Browser und Paketverwaltung haben zwei getrennte Proxy-Entscheidungen getroffen, und nur eine davon war konfiguriert.

Welche Entscheidung fehlgeschlagen ist, ist das Einzige, was sich zuerst klären lässt.

Lesen Sie den Fehler, bevor Sie eine Einstellung anfassen

Jede Stufe hinterlässt eine andere Meldung. Ein Name, der sich nie auflöst, ist DNS; eine Verbindung, die nie zustande kommt, ist Routing oder eine Firewall; ein sofortiger 407 ist Proxy-Authentifizierung; eine Beschwerde über das Zertifikat ist TLS-Prüfung; und eine Signaturwarnung sind Repository-Metadaten. Diese fünf Fehler brauchen fünf verschiedene Korrekturen, und eine Proxy-Zeile, die über ein DNS-Problem geklebt wird, verschiebt nur das Hängen.

Kopieren Sie die genaue Zeile und das Repository, das sie nennt, bevor Sie irgendetwas ändern. Eine vage Erinnerung an „es lief in ein Timeout“ ist das, was aus einer Zehn-Minuten-Diagnose einen ganzen Nachmittag macht.

APT pflegt eigene Proxy-Einstellungen

APT liest /etc/apt/apt.conf.d/, die Hauptdatei apt.conf und jede Datei, die APT_CONFIG nennt. Es liest kein Proxy-Profil des Desktops, keine Netzwerkeinstellung von GNOME und keine Browser-Erweiterung. Der Transport beachtet jedoch Proxy-Umgebungsvariablen, weshalb ein funktionierendes export https_proxy=... in Ihrer Shell nichts über einen Timer aussagt, der in einer anderen Umgebung läuft.

Geben Sie aus, was der fehlschlagende Prozess tatsächlich sieht: apt-config dump | grep -i proxy.

Führen Sie das als der Benutzer aus, unter dem der fehlschlagende Vorgang läuft. Wenn root einen anderen Satz Dateien liest oder ein systemd-Timer mit einer anderen Umgebung startet, wird die Ausgabe abweichen, und dieser Unterschied ist Ihre Antwort. Zwei Proxy-Werte, die sich widersprechen, sind schlimmer als ein fehlender Wert, weil der Transport der spezifischsten Übereinstimmung folgt, die er findet.

Setzen Sie den Proxy dort, wo der Eigentümer der Konfiguration ihn erwartet

Für einen vom Administrator genehmigten expliziten Proxy genügt ein kleines Fragment in einer neuen Datei:

Acquire::http::Proxy "http://proxy.corp.example:3128/";
Acquire::https::Proxy "http://proxy.corp.example:3128/";
Acquire::http::Proxy::archive.example.internal "DIRECT";

Die dritte Zeile ist der Teil, den die meisten Beispiele weglassen. Ein Schlüssel pro Host überschreibt den allgemeinen Wert, sodass ein interner Mirror, der über den Tunnel erreichbar ist, den Proxy überspringen kann, während alles andere weiterhin durch ihn läuft. DIRECT ist der dokumentierte Wert dafür, keine leere Zeichenkette.

Legen Sie das Fragment als neue nummerierte Datei an, etwa /etc/apt/apt.conf.d/95proxy. Eine Distributionsdatei zu überschreiben bedeutet, dass das nächste Paket-Update Ihre Änderung still zurücksetzt.

Zugangsdaten bleiben außerhalb des URI

Die Referenz zum APT-Transport verweist für die Authentifizierung auf apt_auth.conf, und dort gehören Benutzername und Passwort hin. Sie in den Proxy-URI einzubetten, bringt sie in Prozesslisten, in die Shell-Historie und in jede Konfigurationsausgabe, die in ein Ticket kopiert wird. Die Auth-Datei braucht restriktive Rechte, weil sie ein Zugangsdatenspeicher ist.

Prüfen Sie auch das Schema. Ein HTTPS-Repository lässt sich weiterhin über einen HTTP-Proxy erreichen; der Transport ist eine eigene Wahl, getrennt vom URI-Schema des Mirrors.

Ein grafisches Software-Center ist eine separate Oberfläche. Nutzt es PackageKit oder ein snap-Backend, ändert das APT-Fragment für es nichts, also prüfen Sie, welcher Prozess die fehlgeschlagene Anfrage gestellt hat.

Prüfen Sie den Weg, nicht nur den Exit-Code

Beobachten Sie mit gesetztem Fragment die Anfrage, statt einem grünen Ergebnis zu vertrauen. apt-get -o Debug::Acquire::http=true update gibt den Verbindungsversuch, den gewählten Proxy und den Antwortcode aus, was einen falschen Proxy von einem Proxy trennt, der Sie abgelehnt hat.

Dann testen Sie den Fall, der nicht funktionieren sollte. Trennen Sie das VPN und prüfen Sie, dass der interne Mirror aufhört zu antworten; lädt er weiter, leitet etwas am Tunnel vorbei oder ein veralteter Cache bedient Sie. Prüfen Sie, dass der erlaubte Weg weiterhin TLS verifiziert und weiterhin Repository-Signaturen prüft, denn ein Proxy, der den Verkehr inspiziert, ist kein Grund, beides abzuschalten. Prüfen Sie außerdem, dass ein nicht authentifizierter Client eine klare Ablehnung erhält statt eines stillen Timeouts.

Halten Sie das funktionierende Fragment und die fehlschlagende Ausgabe zusammen im Änderungsprotokoll fest. Der nächste Mensch, der auf dasselbe Hängen trifft, erkennt den Unterschied von zwei Zeilen schneller als jede Erklärung.

Ähnliche Artikel