OVH Community, votre nouvel espace communautaire.

[Tutoriel] Configurer Apache pour avoir les IP d'origines (mod_cloudflare)


ddavid
04/03/2012, 22h31
Citation Envoyé par keyser94
Question bête mais ou peux t-on activer le module sur un serveur mutualisé ?
Question pas bête du tout, à tout hasard j'aurais pensé que c'était activé ou non, en mode tout ou rien pour l'ensemble des clients de la gamme mutualisé. Mais si ce n'est pas le cas et que c'est paramétrable, ça m'intéresse de le savoir...

En tout cas fait testé : avec un mutu, des lignes manquent parfois dans les logs lorsque l’élément est pris dans le cache. Et pour les lignes présentes, pour l'instant je n'ai vu que l'IP du CDN.

keyser94
04/03/2012, 20h36
Bonsoir,

Question bête mais ou peux t-on activer le module sur un serveur mutualisé ?

Merci
Keyser

ddavid
03/03/2012, 15h35
Bon, j'ai commencé à refaire des tests, mais pour l'instant c'est uniquement en mutu.

Certaines requêtes semblent manquer dans les logs du mutu (et correspondent à des pages effectivement fournies par le cache).

Ceci étant dit, faudra que je revérifie un peu plus tard, il n'est pas exceptionnel qu'une partie des logs bruts n'apparaisse qu'avec du retard. (Même si en l'occurrence j'ai repéré des requêtes ultérieures aux "manquantes" que je cherche)

chtitux
03/03/2012, 00h05
Concernant la gestion de la connexion faite par le CDN quand il a déjà la requête en cache, j'avais essayé de l'analyser avec tcpdump/wireshark ( http://www.wireshark.org/docs/wsug_h...lstcpdump.html ).

Il me semble que le CDN fait des requêtes GET (quasi sûr, je n'ai jamais vu de HEAD dans mes logs Apache) et ne coupait pas la connexion TCP comme une brute, donc la bande passante n'est pas réellement économisée, vu que les pacquets TCP circulent.

Mais bon, j'avais fait les tests il y a 1 mois, et je ne suis ni sûr de la méthode employée, ni de l'analyse de mes résultats (et je ne peux plus refaire les tests actuellement).

ddavid
02/03/2012, 23h30
Citation Envoyé par chtitux
Justement non : le CDN d'OVH simule toutes les requêtes des visiteurs, et avec le module CloudFlare, $_SERVER['REMOTE_IP'] correspond au « vrai visiteur ».
Par contre si le contenu est dans le cache du CDN, la réponse que votre serveur va faire au CDN va être jetée à la poubelle (le CDN aura déjà répondu au visiteur).
Ça me semble être une approche qui se tient pour des questions de rapidité pour le visiteur final.

Cependant si le CDN prend quand même le contenu et le jette, qu'en est-il de la soit disant bande passante économisée pour le serveur de départ ?

La requête effectuée par le CDN lorsque le contenu est dans le cache est-elle une requête vraiment comme les autres, ou y a t-il une astuce avec l'usage de HEAD, d'un byte-range très court ou d'une clôture accélérée de la connexion TCP ? (Cette technique pouvant aussi être liée à un changement de comportement avec les modules supplémentaires ?)

Citation Envoyé par chtitux
Donc si vous servez des pages qui dépendent de l'IP du visiteur, il faut soit les héberger sur un serveur qui n'est pas derrière le CDN, soit exclure ces pages dans le manager, soit répondre avec un header HTTP no-cache.

Une façon simple de tester votre CDN, c'est de créer un fichier PHP avec . Rafraîchissez la page quelque fois, vous verrez que la date ne bouge plus : c'est que le CDN a caché le contenu à cette date (faites l'essai en activant/désactivant le module CloudFlare, vous verrez votre IP ou l'IP du CDN en fonction).
Y a t il une doc (ou une discussion faisant office de doc) que j'ai râtée indiquant le comportement du CDN d'ovh face aux différents headers ?

Car il y a de multiples cas qui peuvent être très intéressants, comme les headers d'expiration, les e-tags... Dans le manager du cloud je n'ai vu qu'un moyen de définir des règles selon le chemins des pages/éléments et leur "extension".

chtitux
02/03/2012, 23h14
Citation Envoyé par ddavid
lorsqu'un visiteur tape dans le CDN et que le CDN ne trouve pas ça dans le cache, il y a une requête au serveur "normal" (celui en place avant l'usage du CDN) et l'IP est alors transmise via une entête HTTP
C'est exactement ça : comme c'est le CDN qui vient faire la requête, Apache indique l'IP du CDN dans ses logs. Or, ce qui est intéressant pour l'hébergeur, c'est l'IP du vrai visiteur.
OVH indique l'IP du visiteur dans un header HTTP.
Le module que j'ai présenté remplace l'IP du CDN d'OVH par l'IP que OVH transmet dans l'header HTTP.

Citation Envoyé par ddavid
si le contenu est trouvé dans le cache du CDN, il y a aucune requête effectuée au serveur "normal", et donc l'IP ne se trouve que dans les logs du CDN ? Sais-tu s'ils sont disponibles quelque part pour le client d'OVH ou si seul OVH y a accès ?
Alors si j'ai bien compris, le CDN d'OVH fait la requête vers le serveur d'origine, même si le contenu est déjà en cache sur le CDN. (Par contre, le CDN n'attend pas la réponse du serveur pour transmettre la réponse au visiteur, donc ça va quand même plus vite pour lui).
La technique de l'IP du visiteur original dans l'header HTTP est la même.

Citation Envoyé par ddavid
Sinon quand on utilise $_SERVER['REMOTE_IP'], je suppose qu'il faut pour ça s'assurer que la page php ne finisse pas dans le cache du CDN au risque de générer des incohérences pour les visiteurs qui obtiendraient les données du cache ?
Justement non : le CDN d'OVH simule toutes les requêtes des visiteurs, et avec le module CloudFlare, $_SERVER['REMOTE_IP'] correspond au « vrai visiteur ».
Par contre si le contenu est dans le cache du CDN, la réponse que votre serveur va faire au CDN va être jetée à la poubelle (le CDN aura déjà répondu au visiteur).
Donc si vous servez des pages qui dépendent de l'IP du visiteur, il faut soit les héberger sur un serveur qui n'est pas derrière le CDN, soit exclure ces pages dans le manager, soit répondre avec un header HTTP no-cache.

Une façon simple de tester votre CDN, c'est de créer un fichier PHP avec . Rafraîchissez la page quelque fois, vous verrez que la date ne bouge plus : c'est que le CDN a caché le contenu à cette date (faites l'essai en activant/désactivant le module CloudFlare, vous verrez votre IP ou l'IP du CDN en fonction).

ddavid
02/03/2012, 22h53
Bonjour chtitux et merci pour ces informations.

Si j'ai bien compris, lorsqu'un visiteur tape dans le CDN et que le CDN ne trouve pas ça dans le cache, il y a une requête au serveur "normal" (celui en place avant l'usage du CDN) et l'IP est alors transmise via une entête HTTP, le module que t'indiques permettant alors de placer dans les logs l'IP ou de l'utiliser dans le code comme si l'accès était direct ?

Par contre, si j'ai également bien compris, si le contenu est trouvé dans le cache du CDN, il y a aucune requête effectuée au serveur "normal", et donc l'IP ne se trouve que dans les logs du CDN ? Sais-tu s'ils sont disponibles quelque part pour le client d'OVH ou si seul OVH y a accès ?

Sinon quand on utilise $_SERVER['REMOTE_IP'], je suppose qu'il faut pour ça s'assurer que la page php ne finisse pas dans le cache du CDN au risque de générer des incohérences pour les visiteurs qui obtiendraient les données du cache ?

claudevv
19/02/2012, 12h21
J'ai repris ton tuto pour cloudflare sur la release 2 OVH.
Et ça marche, et c'est simple ... en plus

Charger le fichier:
Code:
wget https://raw.github.com/cloudflare/CloudFlare-Tools/master/mod_cloudflare.c
Installer :
Code:
apxs2 -cia mod_cloudflare.c
Résultat :
Libraries have been installed in:
/usr/local/apache/modules

Modifier httpd.conf
Code:
LoadModule cloudflare_module modules/mod_cloudflare.so

CloudFlareRemoteIPHeader X-Remote-Ip
CloudFlareRemoteIPTrustedProxy 46.105.0.0/16
Merci

madameirma12955
16/02/2012, 17h09
Attention à ces modules. J'ai des visiteurs peux scrupuleux qui n'hésitent pas à ajouter à leurs requetes HTTP une entete identique à celle ajoutée par le CDN pour faire croire au module que l'adresse IP source est ailleurs que réellement.

Et se faire ainsi passer pour plusieurs visiteurs différents par ex.

OVH a-t'il penser à faire filtrer par le CDN ces fausses en-tête ? En général si c'est bien fait le CDN devrait décaler les IPs et s'ajouter dans la liste des IPs intermédiaires, et le module devrait prendre la dernière IP de la liste.

claudevv
10/02/2012, 20h08
ça marche pas ...
# if DSO load module first:
LoadModule rpaf_module modules/mod_rpaf-2.0.so

RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 46.105.194.0/24 46.105.195.0/24 46.105.196.0/24
RPAFheader X-Real-IP

claudevv
10/02/2012, 18h53
Bon finalement j'ai essayé sur le release 2:

ln -s /usr/local/apache/bin/apxs /usr/sbin/apxs2
make rpaf-2.0
make install-2.0

Résultat : Libraries have been installed in:
/usr/local/apache/modules
Maintenant je sèche sur la configuration dans httpd.conf ...
LoadModule rpaf_module modules/mod_rpaf-2.0.so

RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 ????? faut-il mettre les ip du cdn genre 46.105.194.0/24
RPAFheader X-Forwarded-For

Une idée ?

claudevv
10/02/2012, 18h08
Je reviens avec cette installation, mais cette fois-ci pour mod_rpaf, comme je suis un peu "trouillard" quand il s'agit de modifier une config serveur, alors je préfère poser une question !
Le readme indique :
Compile and Install for 2.0:
apxs -i -c -n mod_rpaf-2.0.so mod_rpaf-2.0.c
or simply try:
make

Je peux essayer sans trop de risque ?

claudevv
02/02/2012, 19h15
Merci

chtitux
02/02/2012, 18h11
Je n'ai pas de réponse sur ça, je n'utilise pas la release d'OVH.
Selon un autre thread, ça n'a pas l'air de poser problème, il faut juste faire attention à l'emplacement du binaire apxs2 (dans /usr/local/apache/bin/apxs apparemment).

Le tutoriel ne fait qu'ajouter 3 fichiers (le module compilé : le .so, le fichier pour charger le binaire : le .load, et le fichier de configuration : le .conf), ainsi que 2 liens pour charger et configurer effectivement le module.
Ça ne modifie pas le binaire Apache par exemple...

claudevv
02/02/2012, 17h55
Bonjour
Crois-tu qu'il soit possible de l'installer sur une release 2 sans sortir de la release ?
Cordialement

chtitux
02/02/2012, 06h53
Bonjour à tous,

OVH conseille sur son site d'utiliser mod_rpaf ou mod_remoteip pour afficher les IPs de vos visiteurs à la place de celles du CDN OVH.
Je n'ai pas réussi à installer ni l'un (rpaf de Debian Squeeze ne fonctionne pas, Invalid command 'RPAFheader', perhaps misspelled or defined by a module not included in the server configuration »), ni l'autre (remoteip n'est pas présent dans la version d'Apache 2.2 de Debian Squeeze, il faut Apache >= 2.3. Un backport est disponible sur http://people.apache.org/~wrowe/httpd-2.2-ports/ , mais je n'ai pas réussi à le faire fonctionner).

J'ai donc choisi d'utiliser le module développé par CloudFlare, mod_cloudflare, disponible sur Github à l'adresse https://github.com/cloudflare/CloudFlare-Tools , qui est basé sur mod_repoteip, mais qui fonctionne.

L'installation s'est faite sur une Debian Squeeze, mais ne devrait pas être trop différente chez les autres.
Étape 1 : Télécharger le fichier source :
Code:
wget https://raw.github.com/cloudflare/CloudFlare-Tools/master/mod_cloudflare.c
À partir de cette étape, toutes les commandes doivent être effectuées en root
Étape 2 : Installation du logiciel pour compiler le module
Code:
aptitude install apache2-dev
Étape 3 : Compilation & installation du moodule
Code:
apxs2 -cia mod_cloudflare.c
Debian active automatiquement le module. Vous pouvez voir l'activation si le fichier .load est présent :
Code:
ls -l /etc/apache2/mods-enabled/cloudflare.load 
lrwxrwxrwx 1 root root 33  2 févr. 00:32 /etc/apache2/mods-enabled/cloudflare.load -> ../mods-available/cloudflare.load
Étape 4 : Configuration.
Par défaut, mod_clouflare est configuré pour utiliser la configuration des serveurs CloudFlare.
Code:
cat >>  /etc/apache2/mods-available/cloudflare.conf << EOF


# Specific to OVH
CloudFlareRemoteIPHeader X-Remote-Ip

# OVH CDN servers
# 46.105.0.1 to 46.105.254.254
CloudFlareRemoteIPTrustedProxy 46.105.0.0/16


EOF

cd /etc/apache2/mods-enabled/ && ln -s ../mods-available/cloudflare.conf .
Étape 5 : Redémarrage d'Apache
Code:
service apache2 restart
Et voilà, les IPs de vos visiteurs sont revenues (et dans vos fichiers de logs, ET dans vos d'environnement d'Apache, comme $_SERVER['REMOTE_IP'] dans PHP) !
N'hésitez pas à poster vos retours sur ce tutoriel, qu'on puisse l'enrichir ensemble !

A+ & merci à OVH pour son CDN gratuit pour le moment,