From eef44c2dce3a40e4a9851c93d588e98d32d502c9 Mon Sep 17 00:00:00 2001 From: Daniel Allaire Date: Sat, 8 Aug 2026 11:06:05 -0400 Subject: [PATCH] nginx : dimensionner les tampons d'en-tetes pour les sessions OIDC MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit oauth2-proxy journalisait AuthSuccess pendant que le navigateur recevait une erreur de passerelle : le cookie de session porte le jeton d'identite, decoupe en plusieurs Set-Cookie, et le tampon par defaut de nginx (4 Ko) ne peut pas les contenir. upstream sent too big header while reading response header from upstream server: icinga.chezlepro.internal, request: GET /oauth2/callback Pose sur TOUTES les expositions : c'est une propriete du proxy, pas de ce service-la, et le prochain service derriere un IdP rencontrerait le meme mur. Trouve grace au journal d'evenements active juste avant : LOGIN puis CODE_TO_TOKEN reussis pour icingaweb2 ont ecarte l'identite d'un coup. Laisse ouvert : trois upstream timed out vers Keycloak en 14 h, alors que Keycloak repond en millisecondes depuis l'edge. Cause non etablie — et ma sonde MTU ne valait rien, l'ICMP etant bloque par construction entre hotes. Co-Authored-By: Claude Opus 5 --- CHANGELOG.md | 34 +++++++++++++++++++ roles/serveur_nginx/defaults/main.yml | 7 ++++ .../templates/expositions.conf.j2 | 15 ++++++++ 3 files changed, 56 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index ec85604..a4cb7fe 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,39 @@ # CHANGELOG — Set-OPS +## 2026-08-08 — 502 sur Icinga : le tampon de nginx, après une authentification réussie + +Symptôme trompeur s'il en est : `oauth2-proxy` journalisait `AuthSuccess` — jeton, jeton +d'identité, rafraîchissement, tout obtenu — pendant que le navigateur recevait une erreur +de passerelle. L'authentification n'était pas en cause ; c'est la réponse qui ne passait +plus. + +``` +upstream sent too big header while reading response header from upstream +server: icinga.chezlepro.internal, request: "GET /oauth2/callback?..." +``` + +Le cookie de session d'`oauth2-proxy` porte le jeton d'identité, découpé en plusieurs +en-têtes `Set-Cookie`. Le tampon par défaut de nginx (4 Ko) ne peut pas les contenir. +`serveur_nginx` pose désormais `proxy_buffer_size` / `proxy_buffers` / +`proxy_busy_buffers_size` sur **toutes** les expositions : c'est une propriété du proxy, +pas de ce service-là, et le prochain service placé derrière un IdP rencontrerait le même +mur. + +Trouvé uniquement parce que le journal des évènements de Keycloak venait d'être activé : +il a montré `LOGIN` puis `CODE_TO_TOKEN` réussis pour `icingaweb2`, ce qui a écarté d'un +coup l'identité et renvoyé l'enquête vers le chemin de retour. + +**Deux constats laissés ouverts, faute de pouvoir conclure.** + +Le journal de l'edge montre trois `upstream timed out` vers Keycloak en quatorze heures +(console de compte deux fois, autorisation Nextcloud une fois). Mesuré depuis l'edge, +Keycloak répond en **millisecondes** — ce n'est pas lui qui est lent. Cause non établie. + +Et ma sonde MTU ne valait rien : `ping -M do` annonce 100 % de perte alors que HTTP répond +en 5 ms, parce que l'ICMP est bloqué **par construction** entre hôtes (seul `frag-needed` +est ouvert au registre des flux). Troisième fois aujourd'hui que l'instrument est le +problème et non le composant — après `/dev/tcp` sous `sh` et `Maildir/new/`. + ## 2026-08-08 — Keycloak ne gardait aucune trace des connexions Deux services n'aboutissaient pas pour l'exploitant (Nextcloud, Icinga Web 2). Tout a été diff --git a/roles/serveur_nginx/defaults/main.yml b/roles/serveur_nginx/defaults/main.yml index 2d2a2a2..1ae9a30 100644 --- a/roles/serveur_nginx/defaults/main.yml +++ b/roles/serveur_nginx/defaults/main.yml @@ -38,3 +38,10 @@ serveur_nginx_groupe: "serveur_nginx" # cible>:. Une exposition non resolvable (cible sans hote actif, ou sans # port) est ignoree (binding declare mais pas encore cablable). serveur_nginx_publier_expositions: true + +# Tampons d'en-tetes de reponse cote proxy — voir templates/expositions.conf.j2. +# Dimensionnes pour un cookie de session OIDC (jeton d'identite decoupe en plusieurs +# `Set-Cookie`), que le defaut de 4 Ko ne peut pas contenir. +serveur_nginx_proxy_buffer_size: "16k" +serveur_nginx_proxy_buffers: "8 16k" +serveur_nginx_proxy_busy_buffers_size: "32k" diff --git a/roles/serveur_nginx/templates/expositions.conf.j2 b/roles/serveur_nginx/templates/expositions.conf.j2 index f6c9e89..bc4abec 100644 --- a/roles/serveur_nginx/templates/expositions.conf.j2 +++ b/roles/serveur_nginx/templates/expositions.conf.j2 @@ -41,6 +41,21 @@ server { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; + + # Tampons d'en-tetes de reponse. Le defaut de nginx (4 Ko) ne suffit PAS + # derriere une authentification OIDC : le cookie de session porte le jeton + # d'identite, decoupe en plusieurs `Set-Cookie`, et nginx repond alors 502 + # « upstream sent too big header » — juste apres une authentification + # REUSSIE, ce qui rend le symptome trompeur. Constate le 2026-08-08 sur + # icinga.chezlepro.internal, ou oauth2-proxy journalisait `AuthSuccess` + # pendant que le navigateur recevait une erreur de passerelle. + # + # Pose pour TOUTES les expositions : c'est une propriete du proxy, pas du + # service, et le prochain service place derriere un IdP rencontrerait le + # meme mur. + proxy_buffer_size {{ serveur_nginx_proxy_buffer_size }}; + proxy_buffers {{ serveur_nginx_proxy_buffers }}; + proxy_busy_buffers_size {{ serveur_nginx_proxy_busy_buffers_size }}; {% if expo.websocket | default(false) %} # Collabora & co : editeur en direct via WebSocket (upgrade + longue tenue). proxy_http_version 1.1;