Bonjour, C'est nginx qui fait le SSL et le RP. Je tourne pour tous mes tests à un seul serveur d'application, donc pas de soucis dans le load balancing, tout le monde arrive sur le même serveur actuellement :)
Je vais regarder un peu Charles. Valentin Le 28/04/2011 10:22, J. Mardas a écrit : > Bonjour, > > j'ajouterai à cela de vérifier que : > > - le RP ne mets pas en cache des pages contenant un set-cookie > (vérifier les etag, cache-control, pragma, expire & co le cas échéant > supprimer ces entêtes). > - le critère de load balacing en amont effectivement l'IP source > parfois même le port source surtout avec des IP en sortie loadbalancée > > Je suis également partisan d'ajouter son propre header pour suivre par > où est passé un session. J'ai déjà vu des équipement insérer leurs IP au > début, au milieu et à la fin du header X-forwarded-For. > > Pour debuger tu peux également utiliser Charles Proxy > (http://www.charlesproxy.com/) que j'ai découvert récement et qui est > très abouti > > Question quel est le reverse utilisé ? > > HTH > > > > > Le 27 avril 2011 21:59, Jean Baptiste FAVRE <fr-...@jbfavre.org > <mailto:fr-...@jbfavre.org>> a écrit : > > Bonsoir, > > On 27/04/2011 11:37, Valentin Surrel wrote: > > Bonjour la liste, > > > > Afin de pister un bug bien velu, on cherche à inspecter le flux réseau > > entre un client et nous. Problème, on a un frontal qui fait du SSL et > > rajoute un X-Real-IP header avant de reverse-proxy sur les serveurs > > d'application. > > > > Un moyen de trouver les requêtes que fait le client est de faire ça : > > > > ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541 > > > > 1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas > tracer > > la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir > > d'option pour ceci dans ngrep. > > > > Auriez-vous des pistes à me suggérer (on peut très difficilement tout > > enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi > > impossible du fait de sa taille) ? > > > > Est-il possible de faire le tcpdump en amont du frontal sur l'IP > 1.2.3.4 > > et ensuite de décoder le HTTPS ? (avec wireshark ?) > > Je suppose que le cookie (de session ?) est généré (et donc géré) par > le(s) serveur(s) applicatif(s) et non par le reverse ? > > 1. Est-il envisageable de faire sauter le SSL entre le reverse et le > serveur applicatif ? Ce qui simplifierait l'écoute réseau. > > 2. Sinon, cas à la con où l'applicatif se préoccupe de vérifier que le > flux est bien en SSL, est-il envisageable de forcer l'utilisation du > chiffrement null entre le reverse et le serveur applicatif ? Le flux > circulerait alors en clair bien qu'en SSL (négo toussa) ce qui > simplifierait l'écoute réseau. > > 3. Passer le(s) serveur(s) applicatif(s) en mode debug, éventuellement > juste pour ces utilisateurs là. > > 4. Ces clients sont-ils derrière un proxy ? Celui-ci ne ferait-il pas un > peu de ménage dans les headers, voire ajouterait ces propres cookies (de > mémoire, il ne peut y en avoir plus de 4 par requête. Du coup, la > requête pourrait être débarrassée du cookie de session. > > 5. Dérivé du précédent. Si les clients sont derrière un proxy, est-il > possible que celui-ci, s'il ajoute son(es) propre(s) cookie(s) utilise > le même nom de cookie(s) ? Du coup, l'ID de session serait remplacé. > > Mes 2 cents, > JB > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ > > _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
