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-sag@jbfavre.org mailto:fr-sag@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/