Pourquoi un 403 d'un site VPN n'est pas une panne du proxy
Un 403 d'origine, un CONNECT refusé et un défi 407 marquent des frontières différentes. Comparez d'abord le chemin de sortie du proxy avec l'adresse VPN du navigateur.
Les utilisateurs déconnectent le VPN, reçoivent un 403 sur un site interne et signalent que le proxy est en panne. Trois choses distinctes peuvent produire cette page : l'origine a refusé la requête, le proxy direct a refusé d'ouvrir le tunnel, ou le proxy a exigé ses propres identifiants. Chacune est une réponse correcte à une question différente, et les aplatir en une page d'échec générique détruit la seule preuve dont vous disposez. Classez le refus selon le composant qui l'a produit, puis comparez le chemin réseau que chaque composant utilise réellement.
Nommez le composant qui a produit le 403
Un code d'état HTTP appartient à la partie qui l'a envoyé. Quand l'origine renvoie 403, elle a analysé la requête et décidé que l'appelant n'a peut-être pas la ressource, ce qui est une réponse d'autorisation et non un problème de transport. Quand un proxy direct répond 403 à un CONNECT, il a refusé de construire le tunnel, et rien en amont n'a jamais été contacté. Quand il répond 407, il veut ses propres identifiants, qui n'ont rien à voir avec la connexion à l'application.
| What you observe | What it means |
|---|---|
| Origin replies 403 | The origin understood the request and denied it |
| Proxy refuses CONNECT with 403 | The proxy declined to open that tunnel |
| Proxy replies 407 | Proxy authentication is required first |
| Gateway replies 502 or 504 | Upstream failure or timeout, not a permission decision |
Le RFC 9110 définit ces rôles, y compris le défi propre au proxy. Lisez l'état de la réponse elle-même et tout en-tête Proxy-Authenticate avant de lire le corps, car une page d'erreur HTML amicale cache généralement quel composant l'a écrite.
Ce qu'un tunnel CONNECT cache à un relais d'octets
Une fois qu'un proxy renvoie 200 à CONNECT, il relaie des octets et le navigateur garde sa propre session TLS avec l'origine. Un proxy qui relaie des octets ne peut donc pas lire le 403 chiffré dans cette session, et il ne devient jamais l'auteur du refus. Un refus avant l'ouverture du tunnel est un événement tout autre, produit une couche plus bas.
Un proxy inverse qui termine TLS est dans une autre position : il possède la frontière TLS, analyse HTTP et peut légitimement réécrire ou intercepter des réponses. Cette capacité est un choix de configuration, non une propriété du proxy en général, et elle n'autorise pas à contourner la politique d'accès de l'application. Lire la réponse est une capacité ; décider ce que l'appelant peut voir reste le travail de l'origine.
La conséquence pratique est que vous devez savoir laquelle des trois formes vous exploitez avant d'interpréter un 403. Ajouter des règles d'inspection HTTP à un proxy de flux ne lui donne pas de visibilité, et attendre d'un relais d'octets qu'il explique un refus d'origine vous fera chercher dans le mauvais journal.
Comparez le chemin de sortie du proxy avec l'adresse du tunnel du navigateur
Un navigateur connecté à un VPN ne déplace pas automatiquement un serveur proxy distinct sur ce tunnel. L'origine voit l'adresse de sortie du proxy, et si le proxy sort encore par la route par défaut locale, le site protégé voit une adresse à laquelle il n'a jamais été configuré pour faire confiance. L'adresse VPN interne de l'ordinateur portable est invisible pour cette origine. C'est la raison la plus fréquente pour laquelle un tunnel qui fonctionne donne encore un 403 d'un site qui se comporte correctement pour tous les autres.
Testez les deux chemins séparément pour que les adresses ne puissent pas être confondues.
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/privateLa première requête montre ce que l'origine répond pour votre propre adresse, la seconde ce qu'elle répond pour celle du proxy. Une paire de 403 identiques pointe vers les règles d'autorisation de l'origine ; un 200 suivi d'un 403 pointe vers le chemin du proxy. Demandez au propriétaire de l'origine quelles adresses source le jeu de règles admet réellement, plutôt que de supposer que le pool VPN est inclus.
Testez chaque frontière avec une requête qui l'isole
Isolez la couche proxy en lui demandant quelque chose qu'elle ne peut pas refuser pour des raisons applicatives. Un CONNECT vers un hôte que le proxy est autorisé à atteindre, avec la sortie écartée, vous dit si l'admission au tunnel fonctionne tout court.
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'
Si cela affiche un 200 pour le CONNECT puis une poignée de main TLS, l'admission du proxy est correcte et le 403 ultérieur venait de l'origine. Si cela affiche 407, fournissez des identifiants proxy avec --proxy-user et répétez avant de tirer quelque conclusion que ce soit sur le site. Si cela affiche 403 sur la ligne CONNECT, la liste d'autorisation propre au proxy est la frontière à examiner, et l'application n'est pas impliquée.
Gardez les identifiants hors de l'historique du shell et hors des transcriptions collées. Un mot de passe proxy tapé sur une ligne de commande est visible par les autres utilisateurs locaux, et une trace CONNECT capturée avec des identifiants est pire que pas de trace du tout.
Gardez le verdict lisible au lieu de réécrire la page
Une fois que vous savez quel composant a refusé, préservez cette réponse. Un proxy inverse qui renomme un 403 d'origine en délai 504, ou le remplace par une page de succès, cache une décision d'autorisation derrière une histoire de disponibilité et envoie le prochain intervenant à la mauvaise équipe. Les pages d'erreur personnalisées conviennent lorsqu'elles conservent le statut et ajoutent du contexte.
La mise en cache mérite le même soin. Le RFC 9111 régit la façon dont les caches partagés peuvent réutiliser les réponses, et un refus produit pour un appelant ne doit pas être remis à un autre comme s'il s'agissait d'une autorisation. Si des réponses de refus sont stockées, gardez-les privées et limitées, et n'ajoutez jamais une règle de fraîcheur publique uniquement pour réduire le trafic amont.
Terminez par un verdict écrit qui nomme le composant, le statut qu'il a produit et l'adresse source que l'origine a vue. Consignez la requête exacte, les réglages de proxy en vigueur et l'heure, afin que le prochain rapport puisse être confronté aux mêmes preuves au lieu d'être redéduit de mémoire. Ce compte rendu répond au prochain rapport en quelques secondes et empêche le même 403 d'être rediagnostiqué comme une panne VPN.