Filial-Browser zum Proxy: zwei Verbindungen, zwei Wege

Ein Filial-Browser hinter einem expliziten Proxy öffnet zwei Verbindungen, und sie scheitern aus unterschiedlichen Gründen. Die erste ist Browser zum Proxy-Listener, über das Standort-VPN geführt. Die zweite ist Proxy zur Website, mit eigenem Resolver, eigener Route und eigener Egress-Richtlinie des Proxys. Support-Tickets, die beide als einen Fluss behandeln, schicken Leute stundenlang zum falschen Gerät. Richten Sie jede bewusst ein und testen Sie sie in dieser Reihenfolge.

Schritt 1: die beiden Flüsse aufschreiben

Das unmittelbare Ziel des Browsers ist der Proxy-Listener, nicht jede Website, die der Benutzer am Ende besucht. Dieser eine Satz löst den größten Teil der Verwirrung in diesem Design.

branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> website

Verschiedene Quellen, verschiedene Routen, verschiedene Berechtigungen. Bewahren Sie die Skizze im Änderungsdatensatz auf, denn jede spätere Prüfung bezieht sich auf eine ihrer beiden Hälften.

Schritt 2: dem Browser einen Weg zum Listener geben

Notieren Sie den Proxy-Hostnamen, den Listener-Port, die Anforderungen an die Authentifizierung und die zulässigen Filialquellen. Diese Liste ist das Abnahmekriterium für den ersten Fluss und sollte sowohl die interne Namensauflösung als auch die Tunnelroute umfassen.

Wenden Sie eine enge Netzwerkregel für den vorgesehenen Dienst an, statt einen unbeschränkten Proxy ins Internet zu veröffentlichen. Der Proxy kann in einem internen Netz bleiben, wenn seine vorgesehenen Clients einen unterstützten Weg zu ihm haben.

Schritt 3: den Browser konfigurieren, nicht nur die Routentabelle

Nutzen Sie die Proxy-Einstellung des Browsers, eine PAC-Datei oder den verwalteten Erkennungsmechanismus der Organisation. Gewöhnliche Website-Pakete mit einer Route an die Proxy-Adresse zu schicken, bringt den Browser nicht dazu, das Proxy-Protokoll zu sprechen; das ist transparente Abfangung und gehört zu einem anderen Gateway-Design.

Notieren Sie, welche Anwendungen die Einstellung beachten. Mailclients, Updater und Spiele tun das oft nicht, und sie nutzen weiter den einfachen Weg.

Schritt 4: die Weiterverbindung des Proxys beweisen

Der Proxy braucht seinen eigenen Resolver und eine zulässige Route zur Website sowie jede Firewall- oder Übersetzungsrichtlinie, die seine Internetgrenze verlangt. Ein Browser, der den Listener erreicht, beweist davon nichts. Testen Sie den zweiten Fluss vom Proxy selbst aus, mit demselben Ziel und Port, die der Benutzer gemeldet hat.

Bei HTTPS öffnet CONNECT einen Tunnel zum angeforderten Ziel. Gewöhnliche Weiterleitung liefert dem Proxy nicht die entschlüsselte Seite, und das Abschalten der Zertifikatsprüfung, um eine Inspektion zu improvisieren, ist keine Lösung.

Schritt 5: vier Fehler unterscheiden

Eine Proxy-Authentifizierungsaufforderung ist ein 407 vom Listener. Ein abgelehntes CONNECT ist eine Richtlinienentscheidung auf dem Proxy, meist mit eigenem Status und eigener Logzeile. Eine fehlgeschlagene Weiterverbindung sieht wie ein Timeout oder Reset aus, den der Proxy gegen das Ziel protokolliert. Eine Website-Antwort bedeutet, dass beide Verbindungen funktionierten und das Problem am Ursprung liegt.

Melden Sie die Grenze, die Sie beobachtet haben, nicht die Zusammenfassung, das VPN sei ausgefallen.

Schritt 6: Umfang festlegen und Rückfall planen

Entscheiden Sie, was passiert, wenn Proxy oder Tunnel nicht verfügbar sind, und sagen Sie klar, welchen Verkehr dieses Design abdeckt. Es trägt Webzugriff von Clients, die die Proxy-Einstellung beachten; es trägt keine Mail, keine beliebigen Geräteprotokolle und keine Software, die die Konfiguration ignoriert.

Validieren Sie den erforderlichen Browservorgang und eine erforderliche Ablehnung nach einem genehmigten Plan, bevor Sie das Design auf weitere Clients ausdehnen.