Unternehmensproxy und Windows-Apps — Proxyauflösung in WinINET, WinHTTP und .NET

„Der Browser öffnet externe Sites, aber nur die Geschäftsanwendung erreicht die externe API nicht.“ „Es kommuniziert, wenn ich es von Hand starte, und scheitert, sobald ich daraus einen Windows-Dienst mache.“ In Umgebungen mit Unternehmensproxy treten solche Missverhältnisse häufig auf.

Der Ausgangspunkt der Untersuchung ist, welche Proxyeinstellungen diese App unter welchem Konto liest. Windows hat nicht eine einzige Proxyeinstellung. Browser, Dienst und HttpClient von .NET können jeweils andere Einstellungen konsultieren.

In den meisten Fällen ist die Ursache weder ein Ausfall des Proxyservers noch ein Fehler der App, sondern dieses Missverhältnis zwischen Einstellungsfamilien und Ausführungskonto. Dieser Artikel richtet sich an IT-Verantwortliche in kleinen und mittleren Unternehmen und an Entwickler von Windows-Apps. Er ordnet das Gesamtbild der Einstellungen, dann PAC, Authentifizierung und Zertifikate und schließlich das Eingrenzungsverfahren.

Erzeugungsmuster und Timeout-Entwurf von HttpClient selbst behandelt „HttpClient nicht mit using umschließen“. Der Schwerpunkt dieses Artikels ist, aus welchen Einstellungen der Proxy aufgelöst wird und wo die Kommunikation danach stehen bleibt.

1. Zuerst das Fazit

Zuerst sind drei Punkte festzuhalten.

• Bevor Sie die Einstellungen ansehen, identifizieren Sie die App und das Ausführungskonto. Welche der benutzerspezifischen WinINET-Einstellungen, der WinHTTP-Rechnereinstellungen und der Umgebungsvariablen gelesen wird, entscheidet die App. Die Einstellungen, die ein Administrator auf dem eigenen Bildschirm sieht, sind von einem Dienst aus nicht unbedingt sichtbar.¹²³
• Untersuchen Sie mit der problematischen URL, nicht mit einer, die funktioniert. PAC gibt je URL einen Proxy oder DIRECT zurück. Auch in .NET ändert sich der Pfad mit Runtime, Umgebungsvariablen und expliziter Handler-Angabe.⁴⁵⁶
• Untersuchen Sie Pfad, Authentifizierung und Zertifikate getrennt. 407 ist Proxyauthentifizierung und etwas anderes als 401 vom Ziel. Einen Zertifikatsfehler durch TLS-Inspektion beheben Sie durch Verteilung der internen CA und nötige Ausschlüsse, nicht durch Deaktivieren der Prüfung.⁷⁸³

flowchart TB
    accTitle: Informationen, die für die Proxyuntersuchung zusammengehören
    accDescr: HTTP-Stapel und Ausführungskonto der App identifizieren, die von diesem Konto sichtbaren Einstellungen und die problematische URL zusammenstellen und dann Pfad, Authentifizierung und Zertifikate untersuchen
    app["HTTP-Stapel und Konto"] --> settings["Einstellungen dieses Kontos prüfen"]
    settings --> url["Pfad mit der problematischen URL prüfen"]
    url --> error["Authentifizierung und Zertifikate getrennt untersuchen"]

Abbildung 1: Stellen Sie „welche Einstellungen“, „von welchem Konto aus gesehen“ und „welche URL“ zusammen, bevor Sie den Ort des Scheiterns untersuchen.

In einem Satz: Wenn Sie sagen „ich habe die Proxyeinstellungen geprüft“, müssen Sie sagen können, welche der drei Familien Sie geprüft haben und von welchem Konto aus.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (19 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Windows hat drei Familien von „Proxyeinstellungen“

Die Wege, auf denen eine App unter Windows einen Unternehmensproxy findet, fallen grob in drei Familien.

„Die Windows-Proxyeinstellungen“ meinen gewöhnlich (1)

Der „Proxy“, den Sie in der Einstellungen-App sehen, sind historisch die Internetoptionen von Internet Explorer, also die Konfiguration von WinINET. Standardmäßig wird sie je Benutzer gespeichert.³

(2) ist der rechnerweite Standard für Kontexte wie einen Dienst, in denen „kein angemeldeter Benutzer da ist“. (3) ist vor allem die Konvention von Tools aus der plattformübergreifenden Welt; unter Windows lesen sie auch .NET (Core und später) und curl.⁵

Welche Familie gelesen wird, entscheidet die App, nicht wer konfiguriert hat

Nutzt die App WinINET, liest sie (1); nutzt sie WinHTTP, (2) oder eine app-eigene Angabe; nutzt sie .NET (Core und später), (3) und dann (1). Die Bezugsquelle ist festgelegt.

Wenn es also „die Einstellungen stimmen, aber es verbindet nicht“, prüfen Sie zuerst, ob die geprüften Einstellungen und die von der App gelesenen derselben Familie angehören. Bevor Sie alle drei Familien auf denselben Wert drehen, ist es wichtig, den Eingang der Ziel-App zu identifizieren.

Es gibt auch eine Konfiguration je Gerät statt je Benutzer

Ist die Gruppenrichtlinie „Proxyeinstellungen computerbezogen statt benutzerbezogen festlegen“ aktiv, können Sie (1) auf den Rechner umstellen und allen Benutzern dieselben Einstellungen zuweisen. Mit MDM (Intune und vergleichbar) können Sie über den NetworkProxy-CSP je Gerät konfigurieren.³

flowchart TB
    accTitle: Den Geltungsbereich benutzerspezifischer Einstellungen ändern
    accDescr: WinINET-Einstellungen sind standardmäßig je Benutzer, lassen sich per Gruppenrichtlinie auf computerbezogene Einstellungen umstellen und per MDM über den NetworkProxy-CSP je Gerät konfigurieren
    user["WinINET-Einstellungen standardmäßig je Benutzer"] --> gp["Per GPO auf den Computer"]
    gp --> all["Allen Benutzern dieselben Einstellungen zuweisen"]
    mdm["NetworkProxy-CSP von MDM"] --> device["Je Gerät konfigurieren"]

Abbildung 2: Es gibt auch eine Konfiguration, die den Geltungsbereich von (1) auf das Gerät legt; „je Benutzer“ ist als Standardzustand zu lesen.

3. WinINET und WinHTTP — für interaktive Apps und für Dienste

3.1. Unterschied der Rollen

WinINET und WinHTTP sind beide HTTP-Clientstapel, die Windows mitliefert. Die angenommene Ausführungsform unterscheidet sich jedoch.

WinINET ist für interaktive Desktop-Apps gedacht. Es übernimmt automatisch Internetoptionen, Proxy, Cookies und den Anmeldeinformationscache des Benutzers und kann bei Bedarf auch eine Eingabe-UI für Anmeldeinformationen anzeigen. Die Verwendung in einem Dienst oder dienstähnlichen Prozess wird nicht unterstützt.¹

WinHTTP ist für Dienste und die Serverseite gedacht. Es unterstützt die Ausführung unter einem Dienstkonto, die Identitätswechsel (Impersonation) von Threads und die Sitzungstrennung. Dafür teilt es weder Browsereinstellungen, Cookies noch Anmeldeinformationen und zeigt keine UI.²

Die Microsoft-Richtlinie zur Auswahl lautet ebenfalls: WinINET, sofern der Prozess kein Dienst ist und keine Sitzungstrennung oder Identitätswechsel braucht; WinHTTP, wenn es ein Dienst ist.¹ Das heißt jedoch nicht, dass jede als Dienst laufende App die Rechnereinstellungen von WinHTTP liest. Den Umgang mit .NET-Diensten trennt Abschnitt 3.3.

3.2. Grundoperationen von netsh winhttp

Den rechnerweiten Standardproxy von WinHTTP bedienen Sie mit netsh.⁹

:: Aktuelle WinHTTP-Proxyeinstellung anzeigen
netsh winhttp show proxy

:: Statischen Proxy setzen (mit Ausnahmeliste)
netsh winhttp set proxy proxy-server="proxy.example.co.jp:8080" bypass-list="*.example.co.jp;<local>"

:: Einstellungen der Internetoptionen (WinINET) übernehmen
netsh winhttp import proxy source=ie

:: Auf den Standard (DIRECT) zurücksetzen
netsh winhttp reset proxy

Statische Einstellung, Übernahme und Autokonfiguration nicht vermischen

set proxy ist eine statische Einstellung. Automatische Erkennung, Angabe einer PAC-URL und Proxyauthentifizierung behandelt sie nicht.³

import proxy source=ie kopiert die statische Einstellung zum Zeitpunkt der Ausführung. Änderungen der Internetoptionen danach folgt WinHTTP nicht.

flowchart TB
    accTitle: Die Übernahme der Proxyeinstellung ist eine einmalige Kopie
    accDescr: import proxy source=ie kopiert nur die damalige statische Einstellung nach WinHTTP; spätere Änderungen der Internetoptionen werden nicht automatisch nachgezogen
    source["Statische Einstellung zum Ausführungszeitpunkt"] --> copy["import proxy source=ie"]
    copy --> dest["Kopie nach WinHTTP"]
    source -.-> later["Spätere Änderungen werden nicht nachgezogen"]

Abbildung 3: import ist keine synchronisierte Einstellung, sondern die Übernahme der damaligen statischen Einstellung.

Wenn Sie automatische Erkennung über PAC oder WPAD rechnerweit konfigurieren wollen, nutzen Sie netsh winhttp set advproxy. Die JSON-Detailkonfiguration enthält Proxy, ProxyBypass, AutoconfigUrl und AutoDetect.⁹

3.3. Die häufigste Falle: Ein Dienst liest die IE-Einstellungen des Benutzers nicht

Der typische Fall ist, ein Werkzeug, das der Entwickler auf dem eigenen PC laufen ließ, als Windows-Dienst unter LocalSystem zu betreiben.

Während der Entwicklung kommuniziert es über die eigenen benutzerspezifischen Einstellungen (1), aber die von LocalSystem sichtbaren Einstellungen sind etwas anderes. Ist die WinHTTP-Rechnereinstellung unkonfiguriert (DIRECT), versucht der Dienst, die externe API direkt zu erreichen, und läuft in den Timeout. Das Verfahren der Dienstwerdung selbst behandelt „Windows-Dienste erstellen und betreiben“.

flowchart TB
    accTitle: Das Missverhältnis nach der Umstellung von Handstart auf Dienst
    accDescr: Wird ein Werkzeug, das unter den benutzerspezifischen Einstellungen des Entwicklers funktionierte, zum LocalSystem-Dienst, ändern sich die sichtbaren Einstellungen; ist WinHTTP auf DIRECT, versucht es die Direktverbindung und scheitert
    dev["Manuell als Entwickler ausgeführt"] --> works["Kommuniziert mit den eigenen Einstellungen"]
    works --> service["Wechsel zum LocalSystem-Dienst"]
    service --> changed["Die sichtbaren Einstellungen ändern sich"]
    changed --> direct["Ohne WinHTTP-Konfiguration Direktverbindung"]
    direct --> failure["Timeout zur externen API"]

Abbildung 4: Auch auf demselben Rechner ändern sich die konsultierbaren Einstellungen, wenn das Ausführungskonto wechselt.

Die Einstellungen in der Form bereitstellen, die dieser HTTP-Stapel liest

Für Prozesse, die kommunizieren, ohne dass ein Benutzer angemeldet ist, stellen Sie rechnerweite Einstellungen bereit. Die Art der Bereitstellung muss jedoch zum HTTP-Stapel passen.

HttpClient von .NET (Core und später) liest die Rechnereinstellungen von WinHTTP nicht. Urteilen Sie nicht „es ist ein Dienst, also reicht netsh“. Die genaue Rangfolge prüfen Sie in Kapitel 5.

Eine statische Einstellung auf einem mitgenommenen PC kann auch den umgekehrten Unfall auslösen

Fixieren Sie den internen statischen Proxy auf einem Laptop, ist dieser Proxy außerhalb des Unternehmens nicht erreichbar, und die Kommunikation bricht ab. Eine statische Rechnereinstellung ist ein Mittel für Server, deren Netzkonfiguration sich nicht ändert.³

4. PAC und WPAD — der Inhalt der „Autokonfiguration“

PAC berechnet den Pfad, WPAD sucht den Ort der PAC. Teilen Sie „Autokonfiguration“ in diese zwei, wird sichtbar, was zu prüfen ist.

4.1. PAC-Datei und FindProxyForURL

PAC (Proxy Auto-Configuration) ist eine in JavaScript (ECMAScript) geschriebene Datei. Die erforderliche Funktion FindProxyForURL(url, host) gibt für die angegebene URL und den Host die Liste der zu nutzenden Proxys oder DIRECT für die Direktverbindung zurück.¹⁰

function FindProxyForURL(url, host) {
    // Interne Domäne und private Adressen direkt verbinden
    if (dnsDomainIs(host, ".example.co.jp") ||
        isInNet(host, "10.0.0.0", "255.0.0.0")) {
        return "DIRECT";
    }
    // Sonst über den Proxy. Ist der erste unbrauchbar, Fallback auf den nächsten
    return "PROXY proxy1.example.co.jp:8080; PROXY proxy2.example.co.jp:8080; DIRECT";
}

In diesem Beispiel werden interne Domäne und die angegebenen privaten Adressen direkt verbunden, alles andere über den Proxy. Letzteres geht zum nächsten Proxy, wenn der erste unbrauchbar ist, und fällt zuletzt auf DIRECT zurück.

flowchart TB
    accTitle: PAC ändert den Pfad je Ziel
    accDescr: Das beschriebene PAC-Beispiel bewertet URL und Host und gibt DIRECT zurück, wenn interne Domäne oder angegebene private Adresse zutreffen, sonst eine geordnete Proxy-Liste
    target["URL und Host übergeben"] --> check{"Interne Bedingung des Beispiels erfüllt?"}
    check -->|"ja"| direct["DIRECT zurückgeben"]
    check -->|"nein"| proxies["Reihenfolge Proxy 1, 2, DIRECT"]

Abbildung 5: Die PAC-Antwort ändert sich je URL, deshalb bestätigt der Erfolg einer anderen Site nicht den Pfad der problematischen API.

Daraus folgen zwei Hinweise für die Untersuchung.

Mit der problematischen URL prüfen. PAC kann je URL eine andere Antwort geben. Auch die automatische Proxyfunktion von WinHTTP ist so entworfen, dass sie die Ziel-URL der Anfrage jedes Mal übergibt. „Im Browser ist eine andere Site sichtbar“ beweist nicht, dass die problematische API denselben Pfad nimmt.⁴

Kommunikation, die im Proxy-Log fehlt, kann DIRECT oder eine Ausnahme sein. DIRECT bedeutet „geh ohne Proxy“. Erscheint interne Kommunikation nicht im Log, prüfen Sie die DIRECT-Bewertung der PAC und die Übereinstimmung mit der Ausnahmeliste.

4.2. Automatische Erkennung über WPAD

Ist „Einstellungen automatisch erkennen“ aktiv, sucht WPAD (Web Proxy Auto-Discovery) den Ort der PAC-Datei. Üblich ist, die PAC-URL per DHCP zu verteilen oder den Host wpad per DNS aufzulösen und die Datei von einer URL wie http://wpad/wpad.dat zu holen.¹¹

flowchart TB
    accTitle: Von der automatischen Erkennung bis zum Holen der PAC
    accDescr: WPAD sucht den Ort der PAC-Datei per DHCP oder DNS, holt die PAC von dort und nutzt sie zur Pfadberechnung
    auto["Automatische Erkennung aktivieren"] --> find["Ort per DHCP oder DNS suchen"]
    find --> pac["PAC-Datei holen"]
    pac --> route["Pfad je Ziel berechnen"]
    find -.-> missing["Ohne Infrastruktur scheitert die Erkennung"]

Abbildung 6: Automatische Erkennung braucht die DHCP-/DNS-Infrastruktur auf der Netzseite.

Nur automatische Erkennung in einem Netz ohne diese Infrastruktur funktioniert nicht und verlängert die Wartezeit bis zum Erkennungsfehler. „Automatisch“ wählen heißt nicht, dass es überall auflöst.

4.3. Verhalten von Clients, die PAC nicht auswerten

Auch wenn PAC verteilt ist, werten nicht alle Clients sie aus. netsh winhttp set proxy ist eine statische Einstellung, und Tools nach dem Muster der Umgebungsvariable HTTP_PROXY haben in der Regel keinen Ort für eine PAC-URL. Sie geben eine feste Proxy-URL an.³⁵

Bei nativen Apps, die WinHTTP direkt nutzen, prüfen Sie die Art, die Sitzung zu öffnen.

flowchart TB
    accTitle: Prüfen, ob WinHTTP PAC nutzt
    accDescr: Ist die WinHTTP-Sitzung mit AUTOMATIC_PROXY geöffnet, wird automatisch aufgelöst; bei der herkömmlichen Öffnung muss die App die AutoProxy-API aufrufen und das Ergebnis setzen
    open["Angabe von WinHttpOpen prüfen"] --> mode{"AUTOMATIC_PROXY?"}
    mode -->|"ja"| automatic["WinHTTP löst automatisch auf"]
    mode -->|"herkömmliche Öffnung"| api["Die App ruft die AutoProxy-API"]
    api --> apply["Ergebnis auf die Anfrage setzen"]

Abbildung 7: Allein die Information, dass WinHTTP genutzt wird, bedeutet nicht, dass auch PAC automatisch genutzt wird.

In älteren Implementierungen kann PAC vorhanden sein und trotzdem ungenutzt bleiben. In einem Netz mit PAC-Betrieb legen Sie auch fest, was Clients, die PAC nicht auswerten, per statischer Einstellung oder Umgebungsvariable erhalten.

5. Proxyauflösung in .NET — Framework und Core sowie später sind verschieden

In .NET Framework und .NET (Core und später) entsteht der Standardproxy unterschiedlich. Untersuchen Sie eine .NET-8-App mit Wissen aus der Framework-Zeit, prüfen Sie die falschen Einstellungen.

5.1. .NET Framework — Standard sind die Internetoptionen, Überschreiben mit defaultProxy

HttpWebRequest von .NET Framework und das darauf aufsetzende HttpClient nutzen den Standardproxy, solange Proxy nicht explizit gesetzt ist. Er ergibt sich aus der Kombination der Interneteinstellungen (WinINET-Äquivalent) des Ausführungskontos und der Konfigurationsdatei, und die Angaben der Konfigurationsdatei haben Vorrang.⁶

Gesteuert wird das über system.net/defaultProxy in app.config oder machine.config.¹³

<configuration>
  <system.net>
    <!-- useDefaultCredentials: Standardanmeldeinformationen an den Authentifizierungsproxy senden? -->
    <defaultProxy enabled="true" useDefaultCredentials="true">
      <proxy usesystemdefault="true"
             proxyaddress="http://proxy.example.co.jp:8080"
             bypassonlocal="true" />
      <bypasslist>
        <add address="[a-z]+\.example\.co\.jp$" />
      </bypasslist>
    </defaultProxy>
  </system.net>
</configuration>

Ist defaultProxy leer, werden die Internetoptionen genutzt; schreiben Sie proxyaddress und Vergleichbares, hat diese Angabe Vorrang. Aus dem Programm können Sie denselben Standard mit WebRequest.DefaultWebProxy ersetzen.¹³⁶

flowchart TB
    accTitle: Der Standardproxy von .NET Framework
    accDescr: .NET Framework nimmt die Interneteinstellungen des Ausführungskontos als Basis und gibt den in der Konfigurationsdatei angegebenen Werten Vorrang, um den Standardproxy festzulegen
    account["Einstellungen des Ausführungskontos"] --> config["Angaben der Konfigurationsdatei haben Vorrang"]
    config --> default["Standardproxy von Framework"]
    replace["Ersetzen mit DefaultWebProxy"] -.-> default

Abbildung 8: Der Framework-Standard sind die Einstellungen des „Ausführungskontos“, nicht unbedingt die, die auf dem Bildschirm des Administrators sichtbar sind.

Beim Lauf unter einem Dienstkonto gilt dieselbe Vorsicht wie in Abschnitt 3.3. Standardmäßig gelesen werden die Internetoptionen dieses Kontos — etwas anderes als das, was auf dem Desktop des Administrators sichtbar ist, und meist leer.

5.2. .NET (Core und später) — zuerst Umgebungsvariablen, dann die Benutzer-OS-Einstellungen

.NET (Core und später) hat die statische Eigenschaft HttpClient.DefaultProxy. Das ist der Standard, wenn der Handler nichts explizit angibt. Unter Windows wird er in der Reihenfolge Umgebungsvariablen lesen, und nur wenn sie undefiniert sind, die Benutzer-Proxyeinstellungen lesen initialisiert.⁵

Die drei Variablen, die den Proxy setzen, von NO_PROXY trennen

Ist eine von HTTP_PROXY, HTTPS_PROXY oder ALL_PROXY definiert, hat sie Vorrang vor den OS-Einstellungen. Liegt ein HTTPS_PROXY aus der Prüfung noch herum oder injiziert eine CI/CD-Vorlage sie, entsteht ein anderer Pfad als der, den Sie auf dem Bildschirm sehen.

Andererseits konfiguriert allein definiertes NO_PROXY keinen Proxy über Umgebungsvariablen. Unter Windows bleiben die Benutzer-Proxyeinstellungen des Betriebssystems in Kraft.

flowchart TB
    accTitle: Initialisierung des Standardproxys von .NET unter Windows
    accDescr: Ist eine der drei Proxy-Variablen HTTP_PROXY, HTTPS_PROXY und ALL_PROXY definiert, haben die Umgebungsvariablen Vorrang; sonst werden die Windows-Benutzereinstellungen genutzt. Allein NO_PROXY konfiguriert keinen Proxy über Umgebungsvariablen
    init["Initialisierung des Standardproxys"] --> env{"Die drei Proxy-Variablen vorhanden?"}
    env -->|"ja"| useenv["Umgebungsvariablen haben Vorrang"]
    env -->|"nein"| user["Windows-Benutzereinstellungen"]
    init -.-> no["Allein NO_PROXY konfiguriert nichts"]

Abbildung 9: Prüfen Sie zuerst, ob eine Proxyangabe über Umgebungsvariablen vorliegt, und unterscheiden Sie das von einem Zustand mit nur NO_PROXY.

Der „führende Punkt“ von NO_PROXY und der Unterschied unter Linux

NO_PROXY unterstützt keine Platzhalter (*). Ein führender Punkt wie .example.com stimmt mit www.example.com überein, nicht mit example.com selbst.⁵

In Linux-Containern und Vergleichbarem wird ohne definierte Umgebungsvariablen ohne Proxy initialisiert. Unter Windows und Linux unterscheidet sich das Standardverhalten, prüfen Sie es also auch beim Umzug in einen Container.⁵

5.3. Explizite Angabe — HttpClientHandler.Proxy und UseProxy

In beiden Runtimes hat die explizite Angabe an HttpClientHandler.Proxy höchste Priorität. Sie geht vor OS-Einstellungen und Konfigurationsdatei. Ist UseProxy = false, wird überhaupt kein Proxy genutzt.¹¹

using System.Net;

// Den aus der App-Konfiguration gelesenen Proxy explizit nutzen
var handler = new HttpClientHandler
{
    Proxy = new WebProxy("http://proxy.example.co.jp:8080")
    {
        BypassProxyOnLocal = true,
        BypassList = new[] { @"^intra\.example\.co\.jp$" },
        UseDefaultCredentials = true // Beim Authentifizierungsproxy mit den Anmeldeinformationen des Ausführungskontos antworten
    },
    UseProxy = true
};
var client = new HttpClient(handler);

// Client ohne jeden Proxy (Direktverbindung zu internen APIs)
var directHandler = new HttpClientHandler { UseProxy = false };
var directClient = new HttpClient(directHandler);

flowchart TB
    accTitle: Den wirksamen Proxy aus dem Handler bestimmen
    accDescr: Ist UseProxy false, Direktverbindung; ist es true, die explizite Proxy-Angabe des Handlers nutzen, und ohne explizite Angabe den Standardproxy nutzen
    use{"UseProxy ist true?"} -->|"nein"| direct["Direktverbindung"]
    use -->|"ja"| explicit{"Proxy explizit angegeben?"}
    explicit -->|"ja"| proxy["Den angegebenen Proxy nutzen"]
    explicit -->|"nein"| default["Den Standardproxy nutzen"]

Abbildung 10: Bevor Sie den Standardproxy untersuchen, prüfen Sie die explizite Angabe im Handler und UseProxy.

Auch den automatischen Bypass zu lokalen Zielen beachten

Ohne explizite Angabe und bei Befolgung der OS-Einstellungen können flache Namen ohne Punkt, Loopback-Adressen und Ziele, die mit dem Domänensuffix der eigenen Maschine übereinstimmen, als „lokal“ gelten und umgangen werden.¹¹

Wenn „IP-Adresse direkt und Name verhalten sich unterschiedlich“ oder „nach dem FQDN ging es durch den Proxy“, prüfen Sie diese Bewertung.

Die Rangfolge bis hierher fasst sich so zusammen.

6. Authentifizierungsproxy — 407 ist der Authentifizierungsfehler „des Proxys“

6.1. 407 und 401 nicht vermischen

Auch nach Erreichen des Proxys kommen Sie nicht weiter, wenn die Authentifizierung scheitert. Wer Authentifizierung verlangt, trennen Sie anhand von Statuscode und Headern.⁷

Bei 407 prüfen Sie zuerst die in Proxy-Authenticate aufgezählten Verfahren. Basic sendet Benutzername und Passwort, Negotiate (Kerberos/NTLM) und Vergleichbares sind Challenge/Response. Bei Letzterem fließt das Passwort selbst nicht; die Authentifizierung schließt über mehrere Austauschschritte ab.⁷

sequenceDiagram
    accTitle: Ablauf der Antwort an den Authentifizierungsproxy
    accDescr: Der Client erhält vom Proxy 407 und die Mitteilung des Authentifizierungsverfahrens und antwortet mit den dazu passenden Anmeldeinformationen. Bei Challenge/Response sind mehrere Austauschschritte nötig
    participant C as Client
    participant P as Proxy
    C->>P: Kommunikation anfordern
    P-->>C: 407 und Proxy-Authenticate
    C->>P: Je Verfahren auf die Authentifizierung antworten
    Note over C,P: Je Verfahren mehrere Austauschschritte

Abbildung 11: Bei 407 prüfen Sie die Authentifizierungsinformationen, die an den Proxy gehen, nicht an den Zielserver.

Welches Authentifizierungsverfahren „greift“, behandelt ausführlich „NTLM und Kerberos anhand von Diagrammen erklärt“.

6.2. Wie Anmeldeinformationen in .NET übergeben werden

Der Ort der Einstellung unterscheidet sich, je nachdem, ob Sie dem Standardproxy folgen oder den Proxy explizit angeben.

Folgen Sie dem Standardproxy und übergeben Authentifizierungsinformationen, nutzen Sie HttpClientHandler.DefaultProxyCredentials. Das sind die Anmeldeinformationen, die an diesen Standardproxy gehen, wenn UseProxy = true und Proxy = null.¹⁴

using System.Net;

var handler = new HttpClientHandler
{
    UseProxy = true,   // Standardwert. Zusammen mit null Proxy wird der Systemstandardproxy genutzt
    Proxy = null,
    // Auf 407 mit den Anmeldeinformationen des Ausführungskontos (angemeldeter Benutzer oder Dienstkonto) antworten
    DefaultProxyCredentials = CredentialCache.DefaultCredentials
};
var client = new HttpClient(handler);

Geben Sie den Proxy explizit an, liegen die Anmeldeinformationen auf der WebProxy-Seite. In den meisten Client-Szenarien sind nicht einzelne Benutzernamen und Passwörter empfohlen, sondern die Standardanmeldeinformationen des angemeldeten Benutzers; das ist WebProxy.UseDefaultCredentials = true.¹⁵

6.3. Das 407-Problem des Dienstkontos

Die „Standardanmeldeinformationen“ sind die Anmeldeinformationen des Kontos, das diesen Prozess ausführt. Ein interaktiver Benutzer authentifiziert sich als dieser Benutzer, ein LocalSystem-Dienst als Computerkonto.

flowchart TB
    accTitle: Mit der Dienstwerdung ändert sich das authentifizierte Subjekt
    accDescr: Bei Standardanmeldeinformationen authentifiziert die interaktive Ausführung als dieser Benutzer, ein LocalSystem-Dienst als Computerkonto; prüfen Sie, ob der Proxy dieses Subjekt authentifizieren kann
    run{"Ausführungskonto?"} -->|"interaktiver Benutzer"| user["Anmeldeinformationen dieses Benutzers"]
    run -->|"LocalSystem"| machine["Computerkonto"]
    user --> check["Prüfen, ob der Proxy authentifizieren kann"]
    machine --> check

Abbildung 12: Auch wenn der Code bei „Standard“ bleibt, ändert die Dienstwerdung das Subjekt, das der Proxy authentifiziert.

Ein Proxy, der Benutzer über AD authentifiziert, kann Computerkonten oder lokale Konten oft nicht authentifizieren, und 407 bleibt. Umgekehrt gibt es Umgebungen, die für Dienste eine Authentifizierungsausnahme je Quell-IP oder Konto vorsehen.

Deshalb entscheiden Sie bei Apps, die zum Dienst werden, schon im Entwurf, ob ein Domänen-Dienstkonto (gMSA und vergleichbar) genutzt wird, ob der Proxy eine Authentifizierungsausnahme erhält oder ob ein interner Relay-Proxy ohne Authentifizierung bereitsteht. Die Untersuchung von 407 braucht beides: die Einstellungen der App und „kann der Proxy dieses Ausführungskonto authentifizieren“.

Es gibt auch die Methode, Anmeldeinformationen in die Umgebungsvariable zu legen, etwa HTTP_PROXY=http://user:pass@proxy:8080.⁵ Klartextpasswörter liegen dann in der Umgebungsvariable, also in den Prozessinformationen, und sind für den Dauerbetrieb nicht empfohlen.

7. HTTPS und Proxy — CONNECT-Tunnel und TLS-Inspektion

7.1. HTTPS geht als „Tunnel“ durch den Proxy

Nutzt HTTPS den Proxy, sendet der Client zuerst CONNECT Zielhost:443 und öffnet einen TCP-Tunnel. Bei Erfolg antwortet der Proxy mit 200, danach führen Client und Zielserver den TLS-Handshake im Tunnel. Öffnet der Tunnel nicht, kommen 407, 502 und Vergleichbares zurück.¹⁶

flowchart TB
    accTitle: Bis der HTTPS-Tunnel öffnet
    accDescr: Bei HTTPS öffnet eine CONNECT-Anforderung den TCP-Tunnel; nach 200 folgt der TLS-Handshake im Tunnel. Öffnet der Tunnel nicht, kommen 407, 502 und Vergleichbares
    connect["Ziel mit CONNECT angeben"] --> result{"Tunnel geöffnet?"}
    result -->|"Erfolg, 200"| tls["TLS-Verbindung im Tunnel"]
    result -->|"Fehler"| error["407, 502 und Vergleichbares"]

Abbildung 13: Trennen Sie das Scheitern beim Öffnen des Tunnels vom späteren Scheitern der TLS-Verbindung.

Bei diesem „Durchleitungs“-Typ kann der Proxy den verschlüsselten HTTPS-Inhalt nicht lesen. Im Log sichtbar sind Hostname des Ziels und Erfolg oder Misserfolg der Verbindung, nicht der URL-Pfad.

7.2. TLS-Inspektionsproxy und Zertifikatsfehler

Bei TLS-Inspektion (SSL-Entschlüsselung, break and inspect) beendet der Proxy TLS zunächst, entschlüsselt, prüft und verschlüsselt erneut. Auch das dem Client vorgelegte Zertifikat wird durch eines ersetzt, das die eigene CA des Proxys neu signiert hat.⁸

flowchart TB
    accTitle: Bei TLS-Inspektion ändert sich das Zertifikat
    accDescr: Bei TLS-Inspektion beendet der Proxy TLS, prüft den Inhalt und legt dem Client ein von der eigenen CA neu signiertes Zertifikat vor; Vertrauen in diese CA ist nötig
    proxy["Der Proxy beendet TLS"] --> inspect["Entschlüsseln, prüfen, neu verschlüsseln"]
    proxy --> cert["Von der internen CA neu signiertes Zertifikat"]
    cert --> trust["CA-Vertrauen auf der Clientseite nötig"]

Abbildung 14: Beim Inspektionstyp ist nicht nur das Zertifikat des Ziels das Thema, sondern ob die interne CA vertraut wird.

Zuerst prüfen, in welchem Vertrauensspeicher geprüft wird

Diese Konfiguration setzt voraus, dass das CA-Zertifikat des Proxys an die vertrauenswürdigen Stammzertifikate aller Clients verteilt ist. Nicht nur Rechner ohne Verteilung, auch Runtimes mit eigenem Vertrauensspeicher, die den Windows-Zertifikatspeicher nicht sehen, erzeugen einen Prüffehler.

In .NET erscheint das typischerweise als HttpRequestException mit innerem AuthenticationException. Prüfen Sie Meldungen wie „Das Remotezertifikat ist ungültig“.

Die Abhilfe ist die Verteilung der CA, nicht das Deaktivieren der Prüfung

Das interne CA-Zertifikat verteilen Sie gewöhnlich an „Vertrauenswürdige Stammzertifizierungsstellen“ des lokalen Computers. Die Unterscheidung vom Benutzerspeicher behandelt „Windows-Zertifikatspeicher in der Praxis“.

Umgehungen wie ServerCertificateCustomValidationCallback mit ständigem true machen Sie nicht. Wird die App in einem externen Netz verwendet, bleibt die Schwachstelle, Man-in-the-Middle-Angriffe nicht zu erkennen.

Gepinnte Kommunikation von der Inspektion ausschließen

Kommunikation mit Certificate Pinning scheitert in dem Moment, in dem der Proxy das Zertifikat austauscht. Bei Windows-Komponenten, die bestimmte Microsoft-Zertifikate prüfen, gibt es diese Umgehung nicht; ein Ausschluss ist nötig.³

flowchart TB
    accTitle: Verteilung der CA und Ausschluss gepinnter Kommunikation trennen
    accDescr: Bei Zertifikatsfehlern der TLS-Inspektion das CA-Vertrauen prüfen; Kommunikation mit Certificate Pinning scheitert am Austausch selbst und ist von der Inspektion auszuschließen
    failure["Zertifikatsprüfungsfehler"] --> pinned{"Zertifikat gepinnt?"}
    pinned -->|"ja"| exclude["Von der Inspektion ausschließen"]
    pinned -->|"nein"| store["Den konsultierten Vertrauensspeicher prüfen"]
    store --> ca["Verteilung der internen CA prüfen"]

Abbildung 15: Die Abhilfe, die interne CA zu verteilen, und die Abhilfe, den Zertifikatsaustausch selbst zu vermeiden, sind verschieden.

Auch für SaaS-Verkehr zu Microsoft 365 empfiehlt Microsoft den Ausschluss von Entschlüsselung und Prüfung auf der Netzschicht.⁸ Treten Zertifikatsfehler nur bei bestimmten Cloud-Diensten auf, verdächtigen Sie die Kombination aus Ausschlussliste der Inspektion und Pinning.

8. Das Eingrenzungsverfahren — den Verursacher in fünf Schritten festmachen

Die bisherige Mechanik prüfen Sie in der tatsächlichen Untersuchung in dieser Reihenfolge.

(1) Reproduzieren: Auch bei derselben URL die Einstellungsfamilie des Werkzeugs angleichen

Rufen Sie die problematische URL möglichst vom selben Rechner unter demselben Konto auf. Beachten Sie auch Unterschiede der verwendeten Werkzeuge.

„curl kommt durch, die App nicht“ ist ein Hinweis auf abweichende Einstellungsfamilien. Allein der Erfolg eines anderen Werkzeugs bedeutet nicht, dass auch die App denselben Pfad genommen hat.

(2) Einstellungen sammeln: Die drei Familien gemeinsam aufzeichnen

In PowerShell können Sie so sammeln. HKCU der benutzerspezifischen Einstellungen gehört dem Konto, das diesen Befehl ausführt.

# (1) Benutzerspezifische (WinINET-)Einstellungen — beachten, dass HKCU des Ausführungskontos gelesen wird
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
    Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL

# (2) Rechner- (WinHTTP-)Einstellungen
netsh winhttp show proxy

# (3) Umgebungsvariablen
Get-ChildItem env: | Where-Object Name -match 'proxy'

(3) Konto identifizieren: Bei einem Dienst unter demselben Konto erneut prüfen

Identifizieren Sie, ob das Ziel ein Dienst, die Aufgabenplanung oder die Ausführung durch einen anderen Benutzer ist. Bei einem Dienst wiederholen Sie Reproduktion (1) und Sammlung (2) unter demselben Konto. Erfolg in der eigenen Administratorsitzung beweist nicht, was LocalSystem sieht.

flowchart TB
    accTitle: Unter dem Ausführungskonto angleichen und reproduzieren
    accDescr: Sammlung in der Administratorsitzung beweist nicht die vom Dienst sichtbaren Einstellungen; nach Identifikation des Ziel-Ausführungskontos Reproduktion und Sammlung unter diesem Konto erneut prüfen
    admin["In der Administratorsitzung prüfen"] --> identify["Ziel-Ausführungskonto identifizieren"]
    identify --> same["Unter demselben Konto reproduzieren und sammeln"]
    same --> compare["Einstellungen und Anmeldeinformationen abgleichen"]

Abbildung 16: Prüfen Sie, ob die in (1) und (2) gesammelten Informationen die Sicht des in (3) identifizierten Zielkontos sind.

(4) Fehler klassifizieren: „Es verbindet nicht“ zerlegen

Bei 407 prüfen Sie die Proxyauthentifizierung in Kapitel 6, bei Zertifikatsfehlern die TLS-Inspektion in Kapitel 7. Bei Timeout ist die erste Kandidatin, den Proxy nicht zu erreichen; untersuchen Sie Pfad, Namensauflösung und Firewall. Auch die Richtlinienablehnung 403 trennen Sie von Authentifizierung und Timeout.

flowchart TB
    accTitle: Vom Fehler das Untersuchungsziel trennen
    accDescr: Kommunikationsfehler in 407, 403, Timeout oder Namensauflösungsfehler und Zertifikatsfehler teilen und jeweils Authentifizierung, Richtlinienablehnung, Pfad und TLS-Inspektion untersuchen
    error["Scheitern der Kommunikation"] --> auth["Bei 407 Proxyauthentifizierung"]
    error --> deny["Bei 403 Richtlinienablehnung"]
    error --> route["Bei Zeitüberschreitung oder Namensauflösung der Pfad"]
    error --> tls["Bei Zertifikatsfehler TLS"]

Abbildung 17: Statuscode und Ausnahme zu trennen, grenzt die zu prüfenden Einstellungen und Protokolle ein.

Muster, in denen nicht der Proxy, sondern eine eingehende Regel der Windows-Firewall die Ursache ist, behandelt „Windows-Firewall und Business-Anwendungen“.

(5) Proxy-Log: Erreichen und authentifiziertes Konto bestätigen

In den Zugriffsprotokollen der betreffenden Zeit prüfen Sie, ob der Proxy erreicht wurde und als wer authentifiziert wurde. Fehlt jede Spur, behandeln Sie die Kommunikation als nicht beim Proxy angekommen und untersuchen DIRECT der PAC, die Ausnahmeliste und vergessene Umgebungsvariablen.

Bei Bedarf bestätigen Sie das tatsächliche Ziel per Paketmitschnitt. Das Aufnahmeverfahren behandelt „Paketmitschnitt unter Windows in der Praxis — pktmon, netsh trace und Wireshark wählen“.

9. Entwurfsempfehlung — die App zu einer machen, in der sich der Proxy einstellen lässt

Wie leicht die Untersuchung fällt, hängt von den Einstellungsfeldern und den Protokollen der App ab. Für Apps, die in Umgebungen mit Unternehmensproxy ausgeliefert werden, stellen Sie die folgenden vier Punkte bereit.

Nicht nur dem Standard folgen, explizite Angabe und Direktverbindung wählbar machen

Der Standard sei „den OS-Einstellungen folgen“. Für Fälle, in denen PAC nicht auswertbar ist, der Lauf als Dienst oder eine Sonderkonfiguration, lassen Sie Proxy-URL, Ausnahmeliste und „keinen Proxy nutzen“ aus der Konfigurationsdatei angeben. Der Implementierungspunkt sind HttpClientHandler.Proxy und UseProxy in Abschnitt 5.3.¹¹

Der Standard von .NET (Core und später) hat auch den in Abschnitt 5.2 beschriebenen Vorrang der Umgebungsvariablen. Überlassen Sie ihn dem Standard, lesen Sie, welche Einstellungen greifen, nach dieser Regel.

Ausnahmen für interne Ziele so fassen, dass sie in die Einführungsanleitung gehören

Halten Sie schriftlich fest, ob interne Kommunikation zu API, Datenbank, Lizenzserver und Vergleichbarem über DIRECT der PAC, die Ausnahmeliste oder NO_PROXY ausgenommen wird. Dass NO_PROXY keine Platzhalter kennt und was der führende Punkt bedeutet, zeigen Sie mit Beispielen.⁵

Timeouts und Retries unter der Voraussetzung des Proxywegs entwerfen

Wartet die App bei Proxy-Ausfall oder Authentifizierungswartezeit den langen Standardtimeout aus, stehen UI und Betrieb still. Trennen Sie den Verbindungstimeout kürzer und beschränken Sie Retries auf idempotente Anforderungen. Einzelheiten behandelt „HttpClient nicht mit using umschließen“.

Den Pfad aus dem tatsächlich konfigurierten Handler ins Protokoll schreiben

Schreiben Sie nur HttpClient.DefaultProxy ins Protokoll, übersehen Sie die explizite Handler-Angabe und UseProxy = false und zeichnen einen abweichenden Pfad auf. Wichtig ist, die wirksame Einstellung aus dem Handler zu wählen, der HttpClient erzeugt hat, und auch die Bypass-Bewertung des Ziels widerzuspiegeln.

using System.Net.Http;

// handler ist dieselbe Instanz, die HttpClient erzeugt hat
// UseProxy=false bedeutet immer Direktverbindung. Explizite Angabe hat Vorrang, sonst DefaultProxy
var effectiveProxy = handler.UseProxy
    ? handler.Proxy ?? HttpClient.DefaultProxy
    : null;
var target = new Uri("https://api.example.com/v1/orders");
var route = effectiveProxy is null || effectiveProxy.IsBypassed(target)
    ? "DIRECT"
    : effectiveProxy.GetProxy(target)?.ToString() ?? "DIRECT";
logger.LogInformation("HTTP-Senden {Target} Pfad {Route} Ausführungskonto {User}",
    target, route, Environment.UserName);

flowchart TB
    accTitle: Den Pfad aus der Konfiguration des Kommunikationsclients aufzeichnen
    accDescr: Aus dem Handler, der HttpClient erzeugt hat, den wirksamen Proxy wählen, Bypass-Bewertung und Proxyauflösung des Ziels durchführen und Pfad sowie Ausführungskonto ins Protokoll schreiben
    handler["Derselbe Handler wie bei der Erzeugung"] --> effective["UseProxy und explizite Angabe widerspiegeln"]
    effective --> target["Bypass-Bewertung und Auflösung des Ziels"]
    target --> log["Pfad und Konto aufzeichnen"]

Abbildung 18: Zeichnen Sie den Pfad nicht nur aus dem Standardproxy, sondern aus der Konfiguration des Clients selbst auf.

Zeichnen Sie beim Start Pfad und Ausführungskonto der wichtigsten Ziele auf, lassen sich (1) bis (3) in Kapitel 8 leichter nachverfolgen. Wenn jemand sagt „im Browser kommt es durch“, ist dass die App ihre eigenen Einstellungen und den Pfad erklären kann, der untersuchungsfeste Entwurf.

10. Zusammenfassung

Bei der Proxyuntersuchung unter Windows stellen Sie zuerst Einstellungsfamilie, Ausführungskonto und Ziel-URL zusammen.

Benutzerspezifische WinINET-Einstellungen, WinHTTP-Rechnereinstellungen und Umgebungsvariablen sind verschiedene Familien. Mit der Dienstwerdung ändern sich sichtbare Einstellungen und Anmeldeinformationen, und auch zwischen .NET Framework und .NET (Core und später) unterscheidet sich die Standardreihenfolge. Allein netsh winhttp set proxy behandelt weder PAC noch automatische Erkennung noch Authentifizierung.

PAC gibt je URL einen Proxy oder DIRECT zurück, und WPAD braucht die Infrastruktur auf der Netzseite. Nach festgelegtem Pfad prüfen Sie die Proxyauthentifizierung 407 und die Zertifikatsprüfung durch TLS-Inspektion getrennt. Die Zertifikatsprüfung deaktivieren Sie nicht; Sie verteilen die CA und schließen gepinnte Kommunikation aus.

Die Eingrenzung folgt der Reihenfolge Reproduzieren → Sammlung der drei Einstellungsfamilien → Identifikation des Ausführungskontos → Fehlerklassifikation → Proxy-Log. Auf der App-Seite stellen Sie explizite Proxyangabe und Direktverbindung, Ausnahmen, Timeouts und Pfadprotokoll bereit.

Wenn Sie das nächste Mal hören „nur die Geschäftsanwendung verbindet nicht“, fragen Sie zuerst so.

Unter wessen Konto läuft diese App, und welche der drei Proxy-Einstellungsfamilien liest sie?

Diese eine Frage ist der Eingang der Untersuchung.

Verwandte Artikel

• HttpClient nicht mit using umschließen ── HTTP-Kommunikation in C#-Geschäftsanwendungen (Erzeugungsmuster, Timeouts, Retries)
• Paketmitschnitt unter Windows in der Praxis — pktmon, netsh trace und Wireshark wählen
• Windows-Firewall und Business-Anwendungen — Eingehende Regeln über das Installationsprogramm registrieren
• Windows-Dienste erstellen und betreiben ── Von der Abgrenzung zur Aufgabenplanung bis zur Umwandlung eines BackgroundService in einen Dienst
• NTLM und Kerberos anhand von Diagrammen erklärt — Warum die Authentifizierung auf NTLM zurückfällt
• Windows-Zertifikatspeicher in der Praxis — Benutzer oder Computer, wofür entscheiden Sie sich?

Verwandte Beratungsbereiche

Die KomuraSoft LLC übernimmt Untersuchungen von Kommunikationsstörungen von Windows-Apps in Umgebungen mit Unternehmensproxy, Authentifizierungsproxy und TLS-Inspektion wie „auf der Entwicklungsmaschine funktioniert es, im Kundennetzwerk nicht“ und „nach der Dienstwerdung erreicht die externe API nichts mehr“, sowie die Beratung zum Kommunikationsentwurf von Geschäftsanwendungen unter der Voraussetzung einer Proxyumgebung (Einstellungsfelder, Timeouts, Protokollentwurf). Es reicht, bei den Reproduktionsschritten des Phänomens und der Art, Protokolle zu sammeln, anzufangen.

• Windows-App-Entwicklung
• Fehleruntersuchung und Ursachenanalyse
• Technische Beratung und Design-Review
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Warum kommt der Browser durch, nur die Geschäftsanwendung nicht durch den Unternehmensproxy?

Der Browser liest die benutzerspezifischen Proxyeinstellungen von WinINET, aber eine Geschäftsanwendung liest nicht unbedingt dieselben. Eine App, die als Windows-Dienst oder unter einem anderen Konto läuft, konsultiert die von diesem Konto sichtbaren Einstellungen, die Rechnereinstellungen von WinHTTP oder Umgebungsvariablen. Identifizieren Sie zuerst das Ausführungskonto und prüfen Sie die von diesem Konto sichtbaren Proxyeinstellungen sowohl mit netsh winhttp show proxy als auch in den Benutzereinstellungen. Wenn Sie mit curl.exe oder Ähnlichem unter demselben Konto auf demselben Rechner reproduzieren können, können Sie es als Missverhältnis zwischen Einstellungsfamilien behandeln, nicht als app-spezifisches Problem.

Ich habe netsh winhttp set proxy gesetzt, aber der Verkehr der App hat sich nicht geändert. Warum?

Was netsh winhttp setzt, ist der Rechnerstandard von WinHTTP. Es betrifft weder Browser noch interaktive Apps, die WinINET lesen, noch HttpClient von .NET (Core und später), der Umgebungsvariablen bevorzugt. netsh winhttp set proxy ist außerdem eine statische Einstellung; sie behandelt weder PAC-Autokonfiguration noch automatische Erkennung noch Proxyauthentifizierung. Sie müssen zuerst bestätigen, welchen HTTP-Stapel die Ziel-App verwendet und aus welcher Einstellungsfamilie sie den Proxy auflöst.

Welche Proxyeinstellungen liest eine .NET-App?

.NET Framework verwendet standardmäßig die Internetoptionen (WinINET-Äquivalent) des Ausführungskontos, und Sie können sie mit dem Element system.net/defaultProxy in app.config überschreiben. HttpClient unter .NET (Core und später) liest zuerst Umgebungsvariablen wie HTTP_PROXY, HTTPS_PROXY und NO_PROXY und fällt, wenn sie nicht definiert sind, auf die Windows-Benutzer-Proxyeinstellungen zurück. In beiden Fällen hat ein explizites HttpClientHandler.Proxy Vorrang. Die Standardauflösungsreihenfolge unterscheidet sich daher zwischen Framework und Core und später, sodass Sie das Proxyverhalten bei einer Migration neu prüfen müssen.

Was sollte ich prüfen, wenn 407 Proxy Authentication Required zurückgegeben wird?

407 ist ein Zeichen, dass der Proxy selbst Authentifizierung verlangt; das ist etwas anderes als ein Authentifizierungsfehler des Zielservers (401). Bestätigen Sie zuerst das Authentifizierungsschema, das der Proxy verlangt (Negotiate, NTLM, Basic), aus dem Header Proxy-Authenticate, und übergeben Sie in .NET Anmeldeinformationen mit HttpClientHandler.DefaultProxyCredentials oder WebProxy.UseDefaultCredentials. In einer App, die unter einem Dienstkonto läuft, werden die Standardanmeldeinformationen zu denen dieses Dienstkontos, sodass der typische Vorfall ist: es funktioniert für einen interaktiven Benutzer und liefert 407, sobald Sie daraus einen Dienst machen. Prüfen Sie auch im Proxy-Log, als wen es authentifiziert hat.

Ein TLS-Inspektionsproxy erzeugt Zertifikatsfehler. Darf ich die Zertifikatsprüfung deaktivieren?

Das Deaktivieren ist nicht empfohlen. Ein TLS-Inspektionsproxy entschlüsselt den Verkehr und präsentiert dem Client dann ein von seiner eigenen CA neu signiertes Zertifikat, sodass die Prüfung fehlschlägt, wenn dieses CA-Zertifikat nicht in den vertrauenswürdigen Stammzertifikaten liegt. Die korrekte Korrektur ist, das interne CA-Zertifikat an den Windows-Zertifikatspeicher zu verteilen (gewöhnlich Vertrauenswürdige Stammzertifizierungsstellen des lokalen Computers). Das Deaktivieren der Prüfung im Code bedeutet, dass ein Man-in-the-Middle-Angriff nicht erkannt werden kann, wenn die App in einem externen Netz verwendet wird, und die Schwachstelle bleibt.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.