Serveurs Proxy HTTP

Un article de Projet de documentation fug-fr .

Jump to: navigation, search

Avec l'aimable autorisation de l'auteur, traduction d'un article intitulé HTTP proxies de Dru Lavigne, dans la série FreeBSD Basics du site BSDDevCenter d'ONLamp


Sommaire

[modifier] Généralités:

Dans un article précédent, j'ai présenté certains avantages à utiliser un proxy. Aujourd'hui, je voudrais me concentrer sur les proxies HTTP. Nous jetterons un oeil à certains des proxies HTTP disponibles dans la collection des ports, et voir lequel peut convenir à vos besoins.

Si vous en avez déjà connaissance, votre première pensée ira probablement à squid, excellent proxy HTTP. Comme il existe déjà beaucoup d'articles et how-to sur l'utilisation et la configuration de squid, je ne couvrirais pas ce produit ici. Pour ceux qui sont déçus, je donnerais quelques URLs:

Squid est l'exemple d'un proxy HTTP très configurable, qui peut s'affirmer dans de grands réseaux. C'est parfaitement adapté si vous êtes administrateur d'un vaste réseau, mais surpuissant si vous voulez simplement surfer sans risque dans le cadre de votre FreeBSD, ou imposer une politique sur un petit réseau à la maison. Et en tant qu'utilisateur, quels sont les choses irritantes qui surviennent lorsque l'on surfe ? Les premiers rapidement venus à l'esprit:

  • Fenêtres pop up
  • annonces flash
  • cookies
  • Applets Java
  • Webbugs
  • Intros Shockwave
  • la vitesse, ou le manque

Dépendant du navigateur que vous utilisez, certains de ces indésirables peuvent être traités directement. D'autres exigeront d'installer un logiciel supplémentaire proxy. Commençons par jeter un oeil à quelques navigateurs communs, puis passons aux autres proxies.

[modifier] Navigateurs:

A cette date, ce sont les dernières versions libres de trois navigateurs populaires sur le Web:

  • mozilla
  • opera
  • linux-netscape

Gardez à l'esprit que de nouvelles fonctions sont ajoutées avec les nouvelles versions, ainsi celles manquantes maintenant, peuvent apparaitre dans des versions ultérieures. En outre, chaque navigateur a une section préférences, ainsi, si votre navigateur n'est pas énuméré ici, contrôlez les fonctions disponibles.

Pour ces navigateurs, la section préférences se trouve sous le menu d'édition de Netscape et de Mozilla, et sous le menu fichier dans Opéra. Vous trouverez une grande différence dans la quantité de préférences disponibles entre Netscape, Mozilla ou Opéra. C'est parce qu'il y a des versions plus ancienne de Netscape.

Chacun de ces navigateurs a une configuration nommée qui permet de traiter les cookies.

Chacun permet également d'autoriser ou d'invalider Java et Javascript. En conclusion, si vous avez une connexion Internet et de l'espace disque en abondance, vous pouvez obtenir une amélioration de vitesse, en "tunant" la configuration de chaque cache de votre navigateur.

Traiter les fenêtres pop up est un dispositif récent, ainsi on ne le trouve pas dans cette version de Netscape. Dans Opéra, un clic sur Général, pour trouver la configuration rejetant les pop up. Mozilla s'y prend d'avance, en invalidant les pop up entièrement, ou sur une base site par site. Pour invalider tous les pop up, allez à Privacy & Security->Popup Windows, et lisez l'avertissement sur les ramifications. Alternativement, si vous rencontrez toujours un site avec un pop up irritant, cliquez droit simplement sur la page , et choisissez "rejeter les fenêtres pop up de ce site."

[modifier] bfilter:

Maintenant, voyons ce que certaines des applications dans la collection des ports peuvent faire pour améliorer les dispositifs déjà fournis par votre navigateur préféré. Je commencerais par bfilter. Ce proxy HTTP contrôle non seulement les pop up, il arrête également ces "add-on" flashants gênant, et les webbugs. Pour construire ce port, passez en super-utilisateur et: 

# cd /usr/ports/net/bfilter
# make install clean

Le port installera l'application dans /usr/local/bin/bfilter, et un fichier de configuration dans /usr/local/etc/bfilter/config. Une fois l'installation terminée, quittez le compte super-utilisateur, et tapez bfilter, afin de lancer le proxy. Vérifiez alors qu'il est à l'écoute des requètes: 

$ sockstat -4
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS      
dlavigne bfilter  20336    3 tcp4   127.0.0.1:8080        *:*

Vous noterez que bfilter écoute sur le port 8080, sur l'adresse loopback. Si vous lisez les commentaires dans son fichier de configuration, vous verrez que 127.0.0.1 dit de détecter les demandes HTTP sur toutes les interfaces. Si vous souhaitez écouter seulement sur une interface, indiquez son adresse IP dans le fichier de configuration.

bfilter n'est pas un proxy transparent, signifiant que vous devrez configurer votre navigateur pour utiliser le proxy. Entrez dans la section préférences de votre navigateur, et vous devriez trouver une configuration qui traite des proxies. Saisissez l'adresse IP et le numéro de port utilisé par bfilter. Dans mon exemple, bfilter fonctionne sur la même machine que mon navigateur, ainsi j'utilise 127.0.0.1 comme adresse IP, et 8080 comme numéro de port. Si vous exécutez bfilter sur un ordinateur séparé, changez l'adresse IP dans son fichier de configuration, pour refléter celle attachée (NIC) à votre réseau interne. Configurez alors les navigateurs des ordinateurs de votre réseau, pour utiliser l'adresse IP dans leurs sections proxy des préférences.

bfilter a également un fichier de règles, que l'on trouve dans /usr/local/etc/bfilter/rules.
 Cependant, j'ai constaté que les règles par défaut ont plus ou moins fonctionné avec les pop up contagieuses, et aux add-on. Si vous recherchez un serveur proxy facile à utiliser, bfilter est une bonne solution.

[modifier] Middleman:

Un autre proxy HTTP que j'ai plaisir à utiliser est middleman. Comme bfilter, cela fonctionne trés bien, mais ce qui fait son intérêt, ce sont les fonctions supplémentaires, qui permettent d'en apprendre plus sur HTTP, et de voir ce qui se passe dans les coulisses ,chaque fois que vous visitez un site Web.

D'abord, installons le port: 

# cd /usr/ports/www/middleman	
# make install clean

Notez que le nom de l'application installée sera dans /usr/local/bin/mman. Vous devez également savoir le nom du fichier de configuration par défaut, afin de lancer l'application. Si vous tapez juste mman, vous recevrez en sortie le fichier d'aide. Au lieu de cela, utilisez le commutateur c ou config-file pour lancer le proxy: 

# mman -c /usr/local/etc/mman.xml

J'ai constaté que le proxy doit être lancé en tant que super-utilisateur. N'oubliez pas de contrôler que mman est à l'écoute, et configurez en conséquence la section proxy de votre navigateur: 

sockstat -4
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS      
root     mman       575    0 tcp4   127.0.0.1:8080        *:*

Si vous projetez d'utiliser middleman, prenez le temps de lire /usr/local/share/doc/middleman/README.html. C'est la seule documentation sur le produit, mais elle est très complète, et pleine d'idées intéressantes sur la façon d'utiliser un proxy.

Bien que la configuration par défaut convienne probablement à vos besoins, vous devriez vérifier l'interface Web en tapant mman dans votre navigateur. Ceci permettra de visualiser:

  • Connexions actives
  • entrées de log
  • config
  • cache
  • cache DNS
  • en-têtes
  • connexions

[modifier] Au sujet de HTTP:

Si vous n'avez jamais utilisé un serveur HTTP ou un proxy HTTP auparavant, vous pouvez être stupéfié de la quantité d'interactions, qui se produisent à chaque connexion à un site web. J'ai mentionné dans le dernier article que nous nous réfèrerons à la RFC(2616). Faisons un aperçu rapide sur la façon dont le protocole HTTP fonctionne; Je vous laisserais le soin de vous référer a la RFC pour compléter les détails qui vous intéressent.

Chaque fois que vous parcourez un site Web, votre navigateur doit faire une demande séparée pour chaque élément de la page. Par exemple, si je tape slashdot.org dans mon navigateur, je verrais les entrées suivantes dans mon cache mman: 

* http: //images.slashdot.org:80/topics/topicgamesrts.gif
* http: //images.slashdot.org:80/topics/topicinternet.gif
* http: //images.slashdot.org:80/title.gif
* http: //slashdot.org:80/
* http: //images.slashdot.org:80/topics/topicaposx.gif
* http: //images.slashdot.org:80/topics/topicms.gif
* http: //images.slashdot.org:80/topics/topiccomdex.gif
* http: //images.slashdot.org:80/slc.gif
* http: //images.slashdot.org:80/pix.gif
* http: //images.slashdot.org:80/topics/topicscience.gif
* http: //images.slashdot.org:80/greendot.gif
* http: //slashdot.org:80/favicon.ico
* http: //images.slashdot.org:80/topics/topichardware.gif

Notez que chaque GIF ou image est une demande séparée, comme chacune est enregistré dans un fichier séparé sur le web serveur. Afin que mon navigateur puisse afficher la page principale du site Slashdot, il a dû individuellement demander chacun des 11 .gifs, le .ico, et la page HTML qui explique comment tout formater.

Dans HTTP, il y a deux types de paquets: les requêtes, et les réponses. Le paquet de demande vient toujours du navigateur. Ceci se comprend, car un navigateur est un client, et le travail d'un client est de faire des demandes. Et bien sur, les paquets de réponse viennent toujours du serveur web.

Le paquet de demande d'un navigateur a trois composants:

  • protocole
  • en-tête
  • corps

Le protocole indique ce que le client demande. Tous les protocoles sont énumérés et expliqués dans la RFC et typiquement, sont écrits en majuscule. La méthode la plus commune est d'utiliser get, car typiquement votre navigateur veut obtenir une page ou une image particulière du site. Si vous jetez un oeil à vos logs mman, dans cet exemple, les logs proxy HTTP ou de serveur HTTP, vous verrez les demandes get: 

Sat 21 16:04:43 [575] request: GET
http: //images.slashdot.org:80/greendot.gif
Sat 21 16:04:43 [575] cache: create:
http: //images.slashdot.org:80/greendot.gif
Sat 21 16:04:43 [575] request: GET http: //images.slashdot.org:80/pix.gif
Sat 21 16:04:43 [575] cache: create: http: //images.slashdot.org:80/pix.gif
Sat 21 16:04:43 [575] request: GET
http: //images.slashdot.org:80/topics/topicgamesrts.gif
Sat 21 16:04:43 [575] cache: create:
http: //images.slashdot.org:80/topics/topicgamesrts.gif
Sat 21 16:04:43 [575] request: GET
http: //images.slashdot.org:80/topics/topiccomdex.gif
Sat 21 16:04:43 [575] cache: create:
http: //images.slashdot.org:80/topics/topiccomdex.gif
<snip>

Ici, mman a émis la demande get de mon navigateur, puis a placé une copie de l'élément demandé dans son cache.

Le paquet de la réponse d'un serveur web a également trois composants:

  • Statut
  • en-têtes
  • corps

C'est-à-dire, le paquet de demande envoie une requête, et le serveur web répond avec un paquet réponse. Ces messages de conversation sont numériques, et sont énumérés dans la RFC. Vous êtes déjà surement tombé sur "une erreur 404", car 404 est la représentation d'une réponse non trouvée. Le mode le plus commun est 200, ou OK. Si un navigateur émet une demande get, et si le serveur trouve la ressource demandée, il la renverra avec un mode 200. S'il ne peut pas trouver le fichier demandé, il enverra à la place un error 404.

Vous avez probablement noté que les paquets de demande et de réponse contiennent des en-têtes et un corps. Le corps contient habituellement la page ou l'image demandée. Ainsi, quand mon navigateur fait une demande get http: //images.slashdot.org:80/greendot.gif, le serveur web a trouvé le GIF, et a envoyé un paquet de réponse avec un mode 200, avec le GIF lui-même dans le corps du paquet.

[modifier] Affichage des en-têtes avec mman:

Les entêtes sont la partie intéressante des paquets HTTP. Ils contiennent l'information utile qui aident le navigateur et le serveur web à communiquer avec pertinence. Ils contiennent également des informations sensibles sur le serveur, et le navigateur. Voici les résultats d'un clic sur les entêtes dans l'interface Web de mman: 

Unfiltered
Type		Value
Host		mman
User-Agent	Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1)Gecko/20030619
Accept		text/xml,application/xml,application/xhtml+xml,text/html;
.	q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;
.	q=0.2,*/*;q=0.1
Accept-Language	en-us,en;q=0.5
Accept-Encoding	gzip,deflate,compress;q=0.9
Accept-Charset	ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive	300
Proxy-Connection keep-alive
Referer		http:  //mman/headers
.
Filtered
Type		Value
Host		mman
Accept		text/xml,application/xml,application/xhtml+xml,text/html;
.	q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;
.	q=0.2,*/*;q=0.1
Accept-Language	en-us,en;q=0.5
Accept-Encoding	gzip,deflate,compress;q=0.9
Accept-Charset	ISO-8859-1,utf-8;q=0.7,*;q=0.7
Referer		http: //mman/headers
User-Agent	Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)

Rappelez-vous, chaque paquet HTTP inclut des en-têtes. Voici ce que vous voyez des valeurs qui sont envoyées par mon navigateur. La section Unfiltered contient les défauts de mon navigateur. Elle montre clairement mon système d'exploitation, la version et le type de navigateur que j'utilise. La section Filtered montre que mman a changé certaines de ces en-têtes, avant de les envoyer au serveur web. Si je n'aime pas ces nouvelles valeurs, je peux simplement cliquer sur Config, choisir l'entête, et éditer par exemple le User-Agent. Cette section de configuration est trés puissante, vous pouvez ajouter, effacer, et modifier la teneur des en-têtes. Cependant, ne faites pas ceci inconsidéremment. Assurez vous d'avoir lu la RFC, et compris les ramifications des valeurs particulières d'entêtes que vous avez envie de recommander au ciel.

Il est également intéressant de voir les entêtes envoyé par un serveur web. Si je tape cet URL dans mon navigateur, et utilise deux points entre le mot headers et l'URL: 

headers..www.mp3.com

Je verrais ceci: 

*Server header:*
.
HTTP/1.1 200 OK
Date: Sat, 21 Jun 2003 21:17:43 GMT
Server: Apache/1.3.12m1 (Unix) yasl/2.25 sw/1.7 mod_rdbcookie/1.2
.	mod_mp3idver/0.12 rwh/1.1 bw/3.37 rewrite/3.3 include/3.6
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

Notez qu'il n'y a aucun secret sur ce serveur. L'en-tête indique clairement le type et la version logicielle du serveur web. Si vous êtes responsable de la mise à jour d'un serveur, rappelez-vous que chaque paquet HTTP le quittant, indique si vous avez appliqué ou non vos patches !.

[modifier] Controle d' accès:

mman supporte également des fonctionnalités qui peuvent être très utiles dans un environnement géré en réseau. Un, il peut forcer des utilisateurs à s'authentifier avant qu'on leur permette d'utiliser l'Internet. Je cliquerais sur Config, puis access, et ajouterais une politique.

Si je laisse la section adresses IP vide, la politique d'accès affectera chaque IP qui se relie au proxy. Je peux alors placer des valeurs dans username et mot de passe. Avant de sauvegarder cette politique, je dois configurer ce à quoi les utilisateurs auront accès, une fois entré leur username et mot de passe corrects. Mes choix sont:


  • Web interface:

Ceci permettra à des utilisateurs de configurer le proxy, ainsi je laisserais cette option ouverte.

  • Proxy requests:

Si je contrôle cette option, le proxy recevra des demandes des navigateurs qui ont été manuellement configurés pour utiliser l'adresse IP, et le port du proxy.

  • CONNECT requests:

CONNECT est une méthode HTTP qui est souvent désactivée,due à ses risques associés de sécurité.

  • HTTP requests:

Je dois me rappeler de choisir cette option, ou les utilisateurs ne pourront pas accéder à des serveurs HTTP.

  • Transparent proxying:

Si je contrôle cette option, le proxy arrêtera les demandes Web, même si le navigateur n'a pas été configuré pour utiliser le proxy. C'est généralement une bonne idée dans un réseau, car elle assure que les utilisateurs ne pourront contourner votre serveur proxy.

  • Allow bypassing:

mman a des mots-clés qui peuvent être inclus avec une URL, pour contourner des restrictions sur un site particulier. Par exemple, si je veux voir les pop pup pour un site, je pourrais taper ceci dans mon navigateur : bypass [f] ..www.mp3.com. Si vous ne voulez pas d'utilisateurs contournant vos filtres, ne choisissez pas cette option.

Si vous décidez de créer votre propre politique, rappelez-vous d'en créer une deuxième qui permettra en tant qu'administrateur de configurer mman. Si vous projetez de configurer mman sur le même ordinateur qui exécute le proxy, gardez la politique par défaut, mais placez la sous votre nouvelle politique, qui affecte vos utilisateurs.

Maintenant, quand les utilisateurs ouvrent leurs navigateurs Web, le navigateur lui-même les invitera à entrer leur login, que vous avez créé dans votre politique. S'ils le saisissent correctement, ils pourront accéder à l'Internet, selon les paramètres réglés dans votre politique.

Le dernier dispositif que je souhaite mentionner, est limits. Cette configuration permet de contrôler l'accès Internet selon le mois, le jour, et l'heure. Par exemple, vous pourriez configurer une politique d'accès Internet limitée de 9:00 à 17:00 heures, du lundi au vendredi.

[modifier] Conclusion

Il me semble que j'ai à peine effleuré la surface du proxy middleman. Peut-être ai-je piqué votre intérêt, et vous essayerez cette application vous-même.

Dans un prochain article, je voudrais terminer la série proxy en jetant un oeil aux proxy SMTP.


Dru Lavigne enseigne les technologies Marketbridge à Ottawa, et participe à l'Open Ressource Protocole.

Récupérée de « http://freebsd.bebik.net/wiki/index.php/Serveurs_Proxy_HTTP »