Warum ein 403 von einer VPN-Seite kein Proxy-Fehler ist

Nutzer trennen das VPN, treffen auf einer internen Seite auf einen 403 und melden, der Proxy sei defekt. Drei getrennte Dinge können diese Seite erzeugen: Der Origin hat die Anfrage abgelehnt, der Forward-Proxy hat sich geweigert, den Tunnel zu öffnen, oder der Proxy hat eigene Anmeldedaten verlangt. Jedes davon ist eine korrekte Antwort auf eine andere Frage, und sie zu einer generischen Fehlerseite zu verflachen zerstört den einzigen Beweis, den Sie haben. Sortieren Sie die Ablehnung nach der Komponente, die sie erzeugt hat, und vergleichen Sie dann den Netzwerkpfad, den jede Komponente tatsächlich nutzt.

Benennen Sie die Komponente, die den 403 erzeugt hat

Ein HTTP-Statuscode gehört der Partei, die ihn gesendet hat. Wenn der Origin 403 zurückgibt, hat er die Anfrage ausgewertet und entschieden, dass der Aufrufer die Ressource möglicherweise nicht besitzt, was eine Autorisierungsantwort und kein Transportproblem ist. Wenn ein Forward-Proxy 403 auf ein CONNECT antwortet, hat er den Tunnelbau überhaupt verweigert, und nichts oberhalb wurde jemals kontaktiert. Wenn er 407 antwortet, will er eigene Anmeldedaten, die nichts mit der Anmeldung der Anwendung zu tun haben.

RFC 9110 definiert diese Rollen, einschließlich der proxyspezifischen Herausforderung. Lesen Sie den eigenen Status der Antwort und jeden Proxy-Authenticate-Header, bevor Sie den Body lesen, denn eine freundliche HTML-Fehlerseite verbirgt meist, welche Komponente sie geschrieben hat.

Was ein CONNECT-Tunnel vor einem Byte-Relay verbirgt

Sobald ein Proxy 200 auf CONNECT zurückgibt, leitet er Bytes weiter, und der Browser behält seine eigene TLS-Sitzung mit dem Origin. Ein Byte-Relay-Proxy kann daher den verschlüsselten 403 innerhalb dieser Sitzung nicht lesen und wird nie zum Autor der Ablehnung. Eine Ablehnung, bevor der Tunnel öffnet, ist ein völlig anderes Ereignis, erzeugt eine Schicht tiefer.

Ein TLS-terminierender Reverse-Proxy steht an anderer Stelle: Er besitzt die TLS-Grenze, parst HTTP und kann Antworten legitim umschreiben oder abfangen. Diese Fähigkeit ist eine Konfigurationsentscheidung, keine Eigenschaft des Proxying an sich, und sie berechtigt nicht dazu, die Zugriffsrichtlinie der Anwendung zu umgehen. Die Antwort zu lesen ist eine Fähigkeit; zu entscheiden, was der Aufrufer sehen darf, bleibt Aufgabe des Origins.

Die praktische Folge ist, dass Sie wissen müssen, welche der drei Formen Sie betreiben, bevor Sie einen 403 interpretieren. HTTP-Inspektionsregeln zu einem Stream-Proxy hinzuzufügen verleiht ihm keine Sichtbarkeit, und von einem Byte-Relay zu erwarten, eine Origin-Ablehnung zu erklären, schickt Sie in das falsche Log.

Vergleichen Sie den Egress-Pfad des Proxys mit der Tunneladresse des Browsers

Ein Browser, der mit einem VPN verbunden ist, verschiebt nicht automatisch einen separaten Proxy-Server auf diesen Tunnel. Der Origin sieht die Egress-Adresse des Proxys, und wenn der Proxy weiterhin über die lokale Standardroute hinausgeht, sieht die geschützte Seite eine Adresse, der nie vertraut werden sollte. Die innere VPN-Adresse auf dem Laptop ist für diesen Origin unsichtbar. Das ist der häufigste Grund, warum ein funktionierender Tunnel noch immer einen 403 von einer Seite liefert, die sich für alle anderen korrekt verhält.

Testen Sie die beiden Pfade getrennt, damit die Adressen nicht verwechselt werden.

curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/private

Die erste Anfrage zeigt, was der Origin auf Ihre eigene Adresse antwortet, die zweite, was er auf die des Proxys antwortet. Ein übereinstimmendes Paar 403 deutet auf die Autorisierungsregeln des Origins; ein 200 gefolgt von einem 403 deutet auf den Proxy-Pfad. Fragen Sie den Origin-Eigentümer, welche Quelladressen das Regelwerk tatsächlich zulässt, statt anzunehmen, der VPN-Pool sei enthalten.

Testen Sie jede Grenze mit einer Anfrage, die sie isoliert

Isolieren Sie die Proxy-Schicht, indem Sie sie um etwas bitten, das sie aus Anwendungsgründen nicht verweigern kann. Ein CONNECT zu einem Host, den der Proxy erreichen darf, mit verworfenem Output, sagt Ihnen, ob die Tunnelzulassung überhaupt funktioniert.

curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'

Wenn das eine 200 für das CONNECT und dann einen TLS-Handshake ausgibt, ist die Proxy-Zulassung in Ordnung, und der spätere 403 kam vom Origin. Wenn es 407 ausgibt, geben Sie Proxy-Anmeldedaten mit --proxy-user an und wiederholen Sie, bevor Sie Schlüsse über die Seite ziehen. Wenn es 403 in der CONNECT-Zeile ausgibt, ist die eigene Allow-List des Proxys die zu prüfende Grenze, und die Anwendung ist nicht beteiligt.

Halten Sie Anmeldedaten aus der Shell-Historie und aus eingefügten Transkripten heraus. Ein in eine Kommandozeile getipptes Proxy-Passwort ist für andere lokale Nutzer sichtbar, und ein aufgezeichneter CONNECT-Trace mit Anmeldedaten ist schlimmer als gar kein Trace.

Halten Sie das Urteil lesbar, statt die Seite umzuschreiben

Wenn Sie wissen, welche Komponente abgelehnt hat, bewahren Sie diese Antwort. Ein Reverse-Proxy, der einen Origin-403 als 504-Timeout umbenennt oder ihn durch eine Erfolgsseite ersetzt, verbirgt eine Autorisierungsentscheidung hinter einer Verfügbarkeitsgeschichte und schickt den nächsten Responder zum falschen Team. Benutzerdefinierte Fehlerseiten sind in Ordnung, wenn sie den Status behalten und Kontext hinzufügen.

Caching verdient dieselbe Sorgfalt. RFC 9111 regelt, wie gemeinsame Caches Antworten wiederverwenden dürfen, und eine für einen Aufrufer erzeugte Ablehnung darf nicht einem anderen als Erlaubnis übergeben werden. Wenn Ablehnungsantworten überhaupt gespeichert werden, halten Sie sie privat und begrenzt, und fügen Sie nie eine öffentliche Frischeregel hinzu, nur um Upstream-Verkehr zu reduzieren.

Schließen Sie mit einem schriftlichen Urteil ab, das die Komponente, den erzeugten Status und die Quelladresse nennt, die der Origin gesehen hat. Halten Sie die genaue Anfrage, die geltenden Proxy-Einstellungen und die Zeit fest, damit der nächste Bericht an denselben Beweisen gemessen werden kann, statt aus dem Gedächtnis neu abgeleitet zu werden. Dieser Eintrag beantwortet den nächsten Bericht in Sekunden und verhindert, dass derselbe 403 erneut als VPN-Ausfall diagnostiziert wird.