Warum curl sich mit localhost statt mit der entfernten URL verbindet
Trennen Sie den geerbten Proxy, die Standard-curlrc und das eigentliche Ziel, bevor Sie das VPN verantwortlich machen. Drei kontrollierte Läufe lassen die TLS-Prüfung aktiv.
Wenn curl unabhängig von der angegebenen URL eine Verbindung zu localhost versucht, ist das VPN die falsche Stelle, um anzufangen. Ein lokaler HTTP- oder SOCKS-Proxy kann die beabsichtigte erste Verbindung sein, selbst wenn der gewünschte Dienst ganz woanders liegt. Läuft dieser Proxy nicht mehr, scheitert der localhost-Versuch, bevor curl das Ziel überhaupt erreicht. Eine Proxy-Antwort ist außerdem kein Beweis dafür, dass das Ziel geantwortet hat.
Arbeiten Sie diese Schritte der Reihe nach ab und halten Sie beim ersten an, der den ersten Verbindungsversuch ändert.
Lesen Sie zuerst die eigenen Proxy-Regeln von curl
curl liest protokollspezifische Proxy-Variablen wie https_proxy und HTTPS_PROXY, außerdem ALL_PROXY, wenn kein protokollspezifischer Wert gilt. Prüfen Sie die Umgebung der Shell, des Dienstes oder der Aufgabe, die curl tatsächlich startet, nicht die in Ihrem aktuellen Terminal. Ein CI-Job, eine systemd-Unit und eine interaktive Shell können drei verschiedene Sätze erben. Genau durch Raten anhand der sichtbaren Shell verliert diese Untersuchung einen ganzen Nachmittag.
Eine Ausnahme sollte man sich merken. curl akzeptiert http_proxy nur in Kleinbuchstaben; die Großschreibung HTTP_PROXY wird ignoriert, weshalb sich dieselbe Umgebung in anderen Werkzeugen anders verhält.
Lesen Sie die Werte vertraulich, denn eine Proxy-URL trägt oft Anmeldedaten.
Prüfen Sie dann die Standard-Konfigurationsdatei von curl auf Proxy- oder Verbindungsüberschreibungen und bestätigen Sie, welche ausführbare Datei Sie wirklich ausführen. Ein Shell-Alias, eine Funktion oder ein Wrapper-Skript kann Optionen hinzufügen, die nie auf Ihrer Kommandozeile erscheinen.
Vergleichen Sie drei Aufrufe mit aktivem TLS
Verwenden Sie ein genehmigtes Diagnoseziel und dieselbe Binärdatei für alle drei Läufe.
curl -v https://service.corp.example/status
curl -q -v https://service.corp.example/status
curl -q --proxy '' -v https://service.corp.example/status
-q unterdrückt die Standard-curlrc und muss der erste Parameter in der Zeile sein, um zu wirken. Es entfernt keine Proxy-Umgebungsvariablen, was Leute überrascht, die genau das erwarten. Die dritte Form fügt einen leeren --proxy-Wert hinzu und überschreibt einen von der Umgebung angeforderten Proxy nur für diesen Aufruf. Vergleichen Sie den ersten Verbindungsversuch in jeder Ausgabe, nicht den endgültigen Statuscode.
Ausführliche Ausgaben können Header, Tokens und Proxy-Anmeldedaten offenlegen, halten Sie sie daher lokal und lesen Sie Auszüge, bevor Sie sie teilen.
Was jedes Ergebnis ausschließt
Ändert das Weglassen der Standardkonfiguration die Verbindung, ist die Konfigurationsdatei die Ursache. Ändert das ausdrückliche Deaktivieren des geerbten Proxys sie, ist die Umgebungsvariable die Ursache. Ändert keines von beiden sie und erscheint localhost weiterhin, prüfen Sie Verbindungsüberschreibungen auf der Kommandozeile, die Namensauflösung und die gewählte ausführbare Datei. Jede davon hat eine andere Lösung, und keine davon ist eine Änderung des Routings.
Das Laden eigener Bibliotheken oder injiziertes Netzwerkverhalten ist eine spätere Ebene, und eine Umgebungsvariable allein ist kein Beweis dafür.
Halten Sie die Proxy-Entscheidung vom VPN getrennt
Sobald curl ein direktes Ziel wählt, leitet das Betriebssystem diese Verbindung weiterhin. Das Deaktivieren eines Anwendungsproxys deaktiviert nicht die Route des VPNs oder dessen Filterrichtlinie. Führen Sie Vergleiche für den Direktzugriff nur dort durch, wo diese Diagnose genehmigt ist. Ein Test, der die Richtlinie still umgeht, ist kein gültiges Ergebnis, sondern ein Vorfall.
Wenn ein lokaler Proxy erforderlich ist, stellen Sie seinen Dienst und seine Adresse wieder her, statt seine Einstellungen zu löschen.
Wenn nur ausgewählte private Ziele Direktzugriff brauchen, fügen Sie eine eng gefasste genehmigte Ausnahme hinzu und behalten Sie den Proxy für alles andere. Bewahren Sie den ersten Fehler des gewählten Weges auf, denn eine localhost-Ablehnung, eine Proxy-CONNECT-Ablehnung, ein Zertifikatsfehler und ein Autorisierungsfehler bezeichnen vier verschiedene Phasen.