Page suivante Page précédente Table des matières 8. Le serveur proxy SOCKS 8.1 Installation du serveur proxy Le serveur proxy SOCKS est disponible sur : 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". décompressez 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. Une chose importante est que le serveur proxy doit être ajouté dans /etc/inetd.conf. Vous devez ajouter une ligne : socks stream tcp nowait nobody /usr/local/etc/sockd sockd pour indiquer au serveur de s'exécuter sur demande. 8.2 Configuration du 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'autorisations d'accès doit se trouver sur le serveur. Le fichier de routage peut être placé sur n'importe quelle machine Unix. Les ordinateurs DOS et, je pense, les Macintosh font leur propre routage. Le fichier d'accès Avec socks4.2 bêta, le fichier d'accès s'appelle "sockd.conf". Il doit contenir deux lignes : une ligne d'autorisations et une ligne d'interdictions. Chaque ligne présente trois champs : l'identificateur (permit ou deny) l'adresse IP le modificateur d'adresse L'identificateur est soit permit, soit deny. Vous devez avoir aussi bien une ligne permit qu'une ligne deny. L'adresse IP contient une adresse à quatre octets en notation classique IP, soit, par exemple, 192.168.2.0. Le masque de modification 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, une ligne : permit 192.168.2.23 255.255.255.255 autorisera seulement l'adresse dont chaque bit correspond à 192.168.2.23, donc seulement 192.168.2.23. Tandis que la ligne : permit 192.168.2.0 255.255.255.0 autorisera toute adresse du groupe 192.168.2.0 à 192.168.2.255, soit tout le domaine de classe C. Il ne faut pas spécifier la ligne : permit 192.168.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.168.2.xxx, les lignes : permit 192.168.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.168.2.3 ne nécessite pas l'usage de socks pour communiquer avec le firewall 192.168.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 L'entrée "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.168.2.0 255.255.255.0 Donnant ainsi 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. DNS depuis l'arrière d'un firewall Configurer un service de noms de domaines depuis l'arrière d'un firewall est une tâche relativement simple. En gros, il vous faut configurer le DNS sur la machine firewall. Ensuite, indiquez à chaque machine derière le firewall d'utiliser celui-ci. 8.3 Travailler avec un serveur proxy Unix Pour faire fonctionner vos applications avec un serveur proxy, celles-ci doivent être "SOCK-ifié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 SOCK-ifier un programme, ainsi qu'un certain nombre de programmes pré-SOCK-ifiés. Si vous utilisez la version SOCK-ifiée pour aller à un emplacement direct, socks basculera automatiquement sur la version directe pour vous. Pour cette raison, il nous faut renommer tous les programmes sur notre réseau protégé et les remplacer par leur version SOCK-ifié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 traitent le routage et la SOCK-ification 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.168.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. 8.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. 8.5 Inconvénients des 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, Persoinne ne vous a créé de compte dessus. Votre fille va à l'université. 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. FTP cause un autre problème avec les serveurs proxy : Lorsque FTP récupère un e liste de fichiers, le serveur ouvre une socket sur la machine client pour lui anvoyer les informations. Un serveur proxy ne permettra pas cela, donc FTP en particulier ne fonctionne pas. 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 résumé, si vous avez les adresses IP nécessaires, et que la sécurité ne soit pas un impératif pour vous, n'utilisez ni un firewall ni un serveur 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 InterNet. Les serveur proxy sont utiles pour ces réseaux qui comportent de nombreuses machines se connectant au vol à InterNet, avec un setup et peu de travail ensuite. Page suivante Page précédente Table des matières