<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>3. Compréhension du problème</title><link href="style.css" rel="stylesheet" type="text/css"><meta content="DocBook XSL Stylesheets V1.70.1" name="generator"><link rel="start" href="index.html" title="Petit guide du perçage de pare-feux"><link rel="up" href="index.html" title="Petit guide du perçage de pare-feux"><link rel="prev" href="ar01s02.html" title="2. Introduction"><link rel="next" href="ar01s04.html" title="4. La solution sécurisée : percer en utilisant ssh"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">3. Compréhension du problème</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ar01s02.html">Précédent</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> <a accesskey="n" href="ar01s04.html">Suivant</a></td></tr></table><hr></div><div class="sect1" lang="fr"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N1019C"></a>3. Compréhension du problème</h2></div></div></div><p> Quand vous comprenez un problème, vous avez fait la moitié du chemin vers la solution. </p><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a name="N101A1"></a>3.1. Donner un nom aux choses</h3></div></div></div><p> Si vous voulez que cette méthode fonctionne, vous devrez comprendre comment elle fonctionne pour que, si quelque chose ne marche pas, vous sachiez où chercher. </p><p> La première étape pour comprendre le problème est de donner un nom aux concepts appropriés. </p><p> Comme d’habitude, nous allons ci-après appeler « client » la machine qui décide d’initialiser la connexion, ainsi que les programmes et les fichiers sur cette machine. Réciproquement, nous appelerons « serveur » celui qui attend les connexions et les accepte, ainsi que les programmes et fichiers sur cette machine. Le perçage de pare-feu est utile lorsque les deux machines sont séparées par un pare-feu, de telle sorte qu’il est possible pour le serveur d’accepter certaines connexions, alors qu'il n'est pas certain que le client puisse en accepter. Un tunnel sera créé entre les deux machines, ce qui permet un trafic IP complet malgré le pare-feu. </p><p> Habituellement, lorsque l’on perce un pare-feu, le client est la machine derrière le pare-feu : il a un accès limité à internet, mais peut d’une façon ou d’une autre ouvrir une connexion ou une autre sur le serveur. Le serveur est une machine avec un accès complet à internet, qui va servir de proxy pour le client afin qu’il accède à internet. Dans un VPN, les rôles peuvent être inversés, avec le client étant sur internet et le serveur servant de proxy au client afin d’accéder à certains réseaux privés. </p></div><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a name="N101AC"></a>3.2. Le problème principal</h3></div></div></div><p> Le problème principal pour le perçage de pare-feu est de créer un tunnel : une connexion continue d’une machine cliente vers une machine serveur de l’autre côté du pare-feu, qui permet un échange bidirectionnel d’informations. Optionnellement, cette connexion devrait être sécurisée. Le problème annexe est de transformer cette connexion en un accès IP complet pour une utilisation transparente par les programmes normaux. </p><p> Pour le problème principal, nous considérerons que soit (1) vous pouvez établir des connexions TCP/IP normales du côté client du pare-feu vers un port sur une machine serveur où un sshd tourne ou peut être mis en fonctionnement, ou (2) vous pouvez d’une façon ou d’une autre établir une connexion telnet à travers un proxy telnet. Au cas où vous ne pourriez pas, nous allons vous diriger vers un autre logiciel qui permet de percer un tunnel à travers un pare-feu. Bien que nous ne donnions qu’une solution sécurisée dans le premier cas, vous pouvez bidouiller votre propre solution sécurisée dans les autres cas, si vous comprenez le principe (si vous ne le comprenez pas, quelqu’un, par exemple moi, peut le faire pour vous contre rémunération). </p></div><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a name="N101B3"></a>3.3. Le problème annexe</h3></div></div></div><p> Pour le problème annexe, les émulateurs d’IP (<span><strong class="command">pppd</strong></span> ou <span class="productname">SLiRP</span>™) sont lancés de chaque côté du tunnel. </p><p> Du côté qui veut un accès IP complet vers l’autre côté, il vous faudra lancer <span><strong class="command">pppd</strong></span>. De l’autre côté, vous devez lancer <span><strong class="command">pppd</strong></span> si vous voulez un accès IP complet dans l’autre sens, ou <span class="productname">SLiRP</span>™ si vous voulez empêcher tout accès. Consultez votre documentation <span><strong class="command">pppd</strong></span> ou <span class="productname">SLiRP</span>™ habituelle pour plus d’informations, si vous avez des besoins spécifiques qui ne sont pas traités dans les exemples ci-dessous. </p><p> Bien qu’il s’agisse d’un concept banal, ça nécessite néanmoins quelques astuces toutes bêtes afin de fonctionner, car (a) si vous utilisez une quelconque session shell programmée interactive pour démarrer l’émulateur d’IP du serveur de n’importe quel côté, il vous faut synchroniser correctement le démarrage de l’émulateur d’IP de l’autre côté, afin de ne pas envoyer des saletés dans la session shell, et (b) les émulateurs d’IP sont conçus pour être lancés sur une interface « tty » : vous devez donc convertir votre interface tunnel en une tty. </p><p> Le point (a) ne représente rien de plus que le problème de synchronisation habituel, et n’existe même pas si vous utilisez <span><strong class="command">ssh</strong></span>, qui s’occupe de manière transparente du lancement de commande du serveur. </p><p> Le point (b) requiert l’utilisation d’un simple utilitaire extérieur. Nous en avons fait un, <span><strong class="command">cotty</strong></span> juste dans ce but. </p><p> < PIQUAGE DE CRISE> </p><p> Entre autres problèmes débiles dûs à l’étroitesse d’esprit des concepteurs de <span><strong class="command">pppd</strong></span> (ceci n’est plus le cas dans les versions récentes de Linux), on peut seulement le lancer soit par un dispositif dans <code class="filename">/dev</code> ou par le tty courant. On ne peut pas le lancer par une paire de tunnels (ce qui serait la conception évidente). C’est parfait pour le <span><strong class="command">pppd</strong></span> du serveur s’il y en a un, puisqu’il peut utiliser le <code class="filename">tty</code> des sessions <span><strong class="command">telnet</strong></span> ou <span><strong class="command">ssh</strong></span>; mais pour le <span><strong class="command">pppd</strong></span> du client, cela entraîne un conflit en cas d’utilisation de <span><strong class="command">telnet</strong></span> pour établir une connexion. </p><p> En effet, <span><strong class="command">telnet</strong></span> veut, également, être sur un tty, il se comporte <span class="emphasis"><em>presque</em></span> correctement avec deux tunnels, à part qu’il insistera encore pour faire des iotctl au tty courant, avec lequel il va interférer ; l’utilisation de <span><strong class="command">telnet</strong></span> sans un tty impose également un régime tel que toute la connexion échouera sur des ordinateurs « lents » (<span><strong class="command">fwprc</strong></span> 0.1 fonctionnait parfaitement sur un P/MMX 233, un délai d’attente de 6 sur un 6x86-P200+, et aucun sur un 486dx2/66). L’un dans l’autre, lors de l’utilisation de <span><strong class="command">telnet</strong></span>, vous avez besoin de <span><strong class="command">cotty</strong></span> comme démon pour copier la sortie d’un tty sur lequel fonctionne pppd sur un autre tty sur lequel fonctionne <span><strong class="command">telnet</strong></span>, et inversement. </p><p> Si je trouve l’abruti (probablement un gars de <span class="productname">MULTICS</span>™ bien que il a dû y avoir des gens d’<span class="productname">UNIX</span>™ assez bêtes pour copier cette idée) qui a inventé le principe des dispositifs « tty » grâce auxquels on lit et on écrit à partir d’un « même » pseudo fichier, au lieu d’avoir des couples de tunnels propres, je l’étrangle ! </p><p> </JE ME CALME> </p></div></div><div class="navfooter"><hr><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="ar01s02.html">Précédent</a> </td><td align="center" width="20%"> </td><td align="right" width="40%"> <a accesskey="n" href="ar01s04.html">Suivant</a></td></tr><tr><td valign="top" align="left" width="40%">2. Introduction </td><td align="center" width="20%"><a accesskey="h" href="index.html">Sommaire</a></td><td valign="top" align="right" width="40%"> 4. La solution sécurisée : percer en utilisant ssh</td></tr></table></div></body></html>
