4. Le serveur proxy

4.1 Installer le serveur proxy

Le serveur proxy nécessite un logiciel complémentaire. Vous pouvez l'obtenir sur l'un des nombreux miroirs de~: ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-src.tgz. Il ya aussi un exemple de fichier de configuration dans ce répertoire "socks-conf". uncompressez et détarez les fichiers dans un répertoire de votre système, et suivez les instructions pour le confectionner. J'ai eu quelques problèmes pour le réaliser. Vérifiez les Makefiles. Certains sont corrects, d'autres, non.

4.2 Configurer le serveur proxy

Le programme de connexion nécessite deux fichiers de configuration distincts. L'un pour indiquer les accès autorisés, l'autre pour rediriger les requêtes vers le serveur proxy approprié. Le fichier d'accès doit se trouver sur le serveur. Le fichier de routage peut être placé sur n'importe quelle machine Un*x. Les ordinateurs DOS et, je pense, les Macintosh font leur propre routage.

Le fichier d'accès

Avec socks4.2 Beta, le fichier d'accès s'appelle "sockd.conf". Il doit contenir deux lignes~: une ligne d'autorisations et une ligne d'interdiction. Chaque ligne doit avoir trois champs~:

l'identificateur ("permit" ou "deny")
l'adresse IP
le modificateur d'adresse

L'identificateur est soit permit, soit deny. Vous devez avoir une ligne permit et une ligne deny.

L'adresse IP contient une adresse à quatre octets en notation classique IP, soit, par exemple, 192.0.2.0.

Le modificateur d'adresse est aussi une adresse à quatre octets en notation classique IP, et fonctionne comme un masque réseau. Représentez-vous ce nombre sur 32~bits. Si un bit est à 1, le bit correspondant de l'adresse qu'il contrôle doit concorder avec le bit correspondant du champ de l'adresse IP. Par exemple, si la ligne est~:


permit 192.0.2.23 255.255.255.255

alors elle autorisera seulement l'adresse dont chaque bit correspond à 192.0.2.23, soit 192.0.2.23. Tandis que la ligne~:


permit 192.0.2.0 255.255.255.0

autorisera toute adresse du groupe 192.0.2.0 à 192.0.2.255, soit tout le domaine de la classe C. Il ne faut pas avoir la ligne~:


permit 192.0.2.0 0.0.0.0

qui autoriserait toute adresse, sans distinction.

Bien, d'abord autorisez toute adresse que vous souhaitez, puis interdisez le reste. Pour autoriser quiconque dans le domaine 192.0.2.xxx, les lignes~:


permit 192.0.2.0 255.255.255.0


deny 0.0.0.0 0.0.0.0

fonctionneront très bien. Notez le premier "0.0.0.0" dans la ligne "deny". Avec un modificateur de 0.0.0.0, le champ adresse IP n'a aucune importance. Tous les champs à 0 est la norme, car c'est facile à écrire.

On peut utiliser plusieurs lignes de chaque type.

Des utilisateurs spécifiques peuvent aussi se voir accorder ou refuser l'accès. Cela est réalisé par l'authentification d'identité. Tous les systèmes ne supportent pas le système ident, y compris Trumpet Winsock, donc nous n'irons pas plus loin en ce qui concerne cela. La documentation de socks est tout à fait adéquate.

Le fichier de routage

Le fichier de routage de socks est bêtement nommé "socks.conf". Je dis "bêtement", car il est si proche du nom du fichier d'accès qu'il est aisé de les confondre.

Le fichier de routage sert à indiquer aux clients de socks quand il est nécessaire d'utiliser celui-ci. Par exemple, dans notre réseau, 192.0.2.3 ne nécessite pas l'usage de socks pour communiquer avec le firewall 192.0.2.1. Il a une connection directe Ethernet. Il définit 127.0.0.1, le port de bouclage, automatiquement. Evidemment, il n'est pas nécessaire d'utiliser socks pour vous parler à vous-même. Il y a trois entrées~:

deny
direct
sockd

Deny indique à socks quand rejeter une requête. Cette entrée a les trois mêmes champs que ceux de sockd.conf~: identificateur, adresse et modificateur. Généralement, puisqu'il est aussi manipulé par sockd.file, le fichier d'accès, le champ modificateur est positionné à 0.0.0.0. Si vous voulez vous protéger de tout appel externe, vous pouvez le faire là.

L'entrée "direct" indique pour quelles adresses ne pas utiliser socks. Il s'agit des adresses pouvant être atteintes sans le serveur proxy. A nouveau, nous avons les trois champs~: identificateur, adresse et modificateur. Dans notre exemple, nous aurions~:


direct 192.0.2.0 255.255.255.0

Donnant l'accès direct pour toute machine de notre réseau protégé.

L'entrée sockd indique à l'ordinateur l'emplacement du démon serveur de socks. La syntaxe est la suivante~:


  sockd @=<liste de serveurs> <adresse IP> <modificateur>

Notez l'entrée @=. Elle vous permet de configurer les adresses IP de plusieurs serveurs proxy. Dans notre exemple, nous utilisons un seul serveur proxy, mais vous pouvez en avoir plusieurs pour permettre un plus grand trafic et pour assurer une tolérance aux pannes.

Les champs adresse IP et modificateur fonctionnent exactement comme dans les autres exemples. Vous spécifiez ainsi où va quelle adresse.

4.3 Travailler avec un serveur proxy

Unix

Pour faire fonctionner vos applications avec un serveur proxy, celles-ci doivent être "sockifiées". Il vous faudra deux telnet différents~: un pour la communication directe, et un autre pour celle avec le serveur proxy. Le paquetage socks contient des indications pour sockifier un programme, ainsi qu'un certain nombre de programmes pré-sockifiés. Si vous utilisez la version sockifiée pour aller directement quelque part, socks basculera automatiquement sur la version directe pour vous. A cause de cela, il nous faut renommer tous les programmes sur notre réseau protégé et les remplacer par leur version sockifiée. "Finger" devient "Finger.orig", "telnet" devient "telnet.orig", etc. Vous devez indiquer chacun d'eux à socks à l'aide du fichier include/socks.

Certains programmes manipulent le routage et la sockification eux-mêmes. Netscape est l'un d'entre eux. Vous pouvez utiliser un serveur proxy sous Netscape en donnant l'adresse du serveur (192.0.2.1 dans le cas qui nous intéresse) dans le champ SOCKs sous Proxies. Chaque application nécessite au moins un petit coup d'oeil, quelle que soit son attitude vis-à-vis d'un serveur proxy.

MS Windows avec Trumpet Winsock

Trumpet Winsock contient des fonctionnalités de serveur proxy incluses. Dans le menu "setup", donnez l'adresse IP du serveur, ainsi que celles de tous les ordinateurs directement accessibles. Trumpet se débrouillera alors avec tous les paquets sortants.

4.4 Faire fonctionner le serveur proxy avec les paquets UDP

Le paquetage socks fonctionne seulement avec les paquets TCP, pas avec les UDP. Cela le rend quelque peu moins utile. De nombreux programmes très utiles, comme talk et Archie, utilisent UDP. Il existe un paquetage prévu pour être utilisé comme serveur proxy pour les paquets UDP appelé UDPrelay, de Tom Fitzgerald <fitz@wang.com>. Malheureusement, à l'heure où ces lignes sont écrites, il n'est pas compatible avec Linux.

4.5 Inconvénients avec les serveurs proxy

Le serveur proxy est, avant tout, un système de sécurité. Son utilisation pour augmenter le nombre d'accès Internet avec un nombre limité d'adresses aura de nombreux inconvénients. Un serveur proxy autorisera un plus grand accès de l'intérieur du réseau protégé vers l'extérieur, mais laissera l'intérieur totalement inaccessible de l'extérieur. Ce qui implique aucun serveur, aucune connexion talk ni Archie, ni e-mail direct vers les ordinateurs de l'intérieur. Ces inconvénients peuvent sembler légers, mais regardez-les sous l'angle suivant~:

Vous avez laissé un document en cours sur votre ordinateur à l'intérieur du réseau protégé. Vous êtes à la maison, et décidez que vous voulez retravailler celui-ci. Vous ne le pouvez pas. Vous ne pouvez atteindre votre ordinateur, car il est derrière le firewall. Vous essayez de vous loger d'abord sur le firewall, mais comme tout le monde a accès au serveur proxy, vous n'avez pas de compte dessus.
Votre fille va au collège. Vous souhaitez lui envoyer un e-mail. Vous avez différents choses de caractère privé à discuter, et préfèreriez recevoir directement votre courrier sur votre machine. Vous avez pleine confiance dans votre administrateur réseau, mais, malgré tout, il s'agit de courrier privé.
L'impossibilité d'utiliser les paquets UDP représente un gros inconvénient avec les serveurs proxy. Je pense que les fonctionnalités UDP arriveront sous peu.

De plus, les serveurs proxy sont lents. A cause de la dégradation du rapport information/protocole, n'importe quel autre moyen d'obtenir cet accès sera plus rapide.

En deux mots, si vous avez les adresses IP nécessaires, et que la sécurité n'est pas un impératif pour vous, n'utilisez pas le firewall ni les serveurs proxy. Si vous n'avez pas suffisamment d'adresses IP, mais que, de même, la sécurité n'est pas fondamentale, vous pouvez jeter un coup d'oeil aux émulateurs IP, comme Term, Slirp ou TIA. Term est disponible sur ftp://sunsite.unc.edu, Slirp est disponible sur ftp://blitzen.canberra.edu.au/pub/slirp, et TIA est disponible sur marketplace.com. Ces paquetages iront plus vite, permettront de meilleures connexions, et fourniront un accès supérieur à l'intérieur du réseau depuis l'internet. Les serveur proxy sont utiles pour ces réseaux qui comportent de nombreuses machines se connectant au vol à l'internet, avec un setup et peu de travail ensuite.

Chapitre suivant, Chapitre Précédent

Table des matières de ce chapitre, Table des matières générale

Début du document, Début de ce chapitre