App-Anfragen scheitern hinter einem Firmen-VPN, der Browser funktioniert

Eine App bricht, während der Browser die Seite lädt. Gehen Sie in dieser Reihenfolge den geerbten Proxy, die Port-Richtlinie, rohe TCP-Resets und die Grenzen der Nutzlastgröße durch.

Sie öffnen das interne Portal im Browser, und es lädt. Sie starten die Anwendung, die denselben Host aufruft, und sie scheitert mit einer Meldung, die keine Ebene benennt. Der Tunnel trägt den Browser, also ist der Tunnel nicht der erste Verdacht. Vier Dinge liegen zwischen Ihrer Anfrage und dem Dienst, und jedes hinterlässt eine andere Signatur. Das ist die Reihenfolge, die ich abarbeite, beginnend bei der Anfrage, die die App tatsächlich sendet, und nicht bei der Einstellungsseite des VPN-Clients.

Sehen Sie sich die Anfrage an, die die App wirklich sendet

Bevor Sie die Konfiguration anfassen, lassen Sie die App sagen, was sie tut. Ein Mitschnitt einer Anfrage mit ausdrücklich deaktiviertem Proxy und ein einfacher Porttest geben Ihnen zwei Grundlinien, mit denen spätere Schritte verglichen werden. Wenn die Anfrage ohne Proxy gelingt, haben Sie drei der vier Ebenen bereits erledigt.

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

Führen Sie die letzten beiden mit demselben Ziel aus und beobachten Sie, wo sie auseinanderlaufen. Ein funktionierender Browser plus ein funktionierendes curl plus eine App, die nicht funktioniert, verengen das Problem auf etwas, das die App hinzufügt: einen Proxy, einen Transport oder eine Nachrichtengröße.

Die App hat einen Proxy geerbt, den niemand konfiguriert hat

Die meisten HTTP-Stacks lesen die Proxy-Konfiguration standardmäßig vom Betriebssystem. Ein Firmen-VPN-Client installiert oft einen als Teil seines Zugriffsprofils, sodass Anfragen über einen Proxy hinausgehen, den der Entwickler im Code nie erwähnt hat. In .NET zieht der Standard-Handler die Einstellungen von IE/WinHTTP; Java liest -Dhttp.proxyHost; Node hat keine eingebaute Proxy-Unterstützung, bis eine Bibliothek sie hinzufügt. Der Fehler ist selten eine saubere Ablehnung, deshalb beginnen Leute, den Server zu betrachten.

Der Test kostet eine Anfrage: Deaktivieren Sie den Proxy ausdrücklich an einem Handler und vergleichen Sie.

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

Wenn das gelingt, gehört die Korrektur in die Konfiguration der Anwendung, nicht in den Tunnel. Wiederholen Sie die Prüfung für jede Laufzeitumgebung im Projekt, denn jede liest eine andere Quelle, und nur eine davon ist vielleicht defekt.

Der gewählte Port ist nicht der Port, den die Richtlinie erlaubt

Ein gerouteter Host ist kein erlaubter Dienst. Firmenrichtlinien erlauben üblicherweise ausgehende Web-Ports und verwerfen den Rest, sodass ein Dienst auf 8080 oder 1883 unerreichbar ist, während 443 einwandfrei funktioniert. Der Browser beweist hier nichts: Er nutzt per Definition 443.

Veröffentlichen Sie denselben Dienst hinter 443 und erreichen Sie ihn über den Namen, bevor Sie eine Ausnahme beantragen. Wenn die Ausnahme wirklich nötig ist, begrenzen Sie sie auf einen Quellbereich und ein Ziel und behandeln Sie sie als Teil der Dienstdefinition, nicht als persönlichen Workaround.

Rohes TCP, das der Pfad zurücksetzt

Langlebige rohe TCP-Verbindungen sind die Ebene, die am verwirrendsten ausfällt. Ein Pfad, der Webverkehr erlaubt, kann ungewöhnliches ausgehendes TCP trotzdem zurücksetzen oder umschreiben, und der Client meldet einen Socket-Fehler, der sich wie ein Ausfall liest. Messaging- und Event-Dienste liefern meist einen WebSocket-Transport genau für solche Netze, und der Wechsel ist eine Client-Option, keine Tunneländerung.

Wechseln Sie den Transport, testen Sie erneut und ändern Sie im selben Durchlauf nichts anderes. Dieser Test mit einer Variablen sagt Ihnen, ob der Reset vom Pfad oder vom Dienst kam.

Verbindungen, die nur bei großen Nutzlasten schließen

Eine Anfrage, die gelingt und etwa eine Sekunde später stirbt, aber nur bei großem Body, deutet auf eine Größengrenze irgendwo in der Mitte hin. Ein Zwischenstück, das Nachrichtenbytes zählt, kann die Verbindung mitten in der Übertragung fallen lassen, und der Client meldet einen abnormen Abschluss statt eines Timeouts.

Teilen Sie die Nutzlast auf Anwendungsebene in Blöcke. Halten Sie das von MTU-Arbeit getrennt: Eine kleinere Paketgröße des Tunnels hilft, wenn gewöhnliche TCP-Sitzungen bei einer konstanten Bytezahl hängen, und sie hilft nicht bei einer Nachricht, die ein Zwischenstück für zu groß hält.

Wie Sie die vier in einem Durchgang unterscheiden

Drei Beobachtungen entscheiden die meisten Fälle. Tritt der Fehler sofort auf oder nur bei großem Body? Gelingt dieselbe Anfrage mit deaktiviertem Proxy? Ändert sich das Ergebnis, wenn Sie Port oder Transport wechseln? Schreiben Sie die Antworten vor der nächsten Änderung auf, denn Firmen-VPN plus geerbter Proxy plus Anwendungsstandard ergeben drei plausible Ursachen auf einmal.

Halten Sie eine Variable pro Test und notieren Sie den verwendeten Zielhost. Ohne diese Grundlinie wiederholt die nächste Person alle vier Schritte von vorn.

Ähnliche Artikel