Quand vous comprenez un problème, vous avez fait la moitié du chemin vers la solution.
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.
La première étape pour comprendre le problème est de donner un nom aux concepts appropriés.
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.
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.
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.
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).
Pour le problème annexe, les émulateurs d’IP (pppd ou SLiRP™) sont lancés de chaque côté du tunnel.
Du côté qui veut un accès IP complet vers l’autre côté, il vous faudra lancer pppd. De l’autre côté, vous devez lancer pppd si vous voulez un accès IP complet dans l’autre sens, ou SLiRP™ si vous voulez empêcher tout accès. Consultez votre documentation pppd ou SLiRP™ habituelle pour plus d’informations, si vous avez des besoins spécifiques qui ne sont pas traités dans les exemples ci-dessous.
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.
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 ssh, qui s’occupe de manière transparente du lancement de commande du serveur.
Le point (b) requiert l’utilisation d’un simple utilitaire extérieur. Nous en avons fait un, cotty juste dans ce but.
< PIQUAGE DE CRISE>
Entre autres problèmes débiles dûs à l’étroitesse d’esprit des concepteurs de pppd (ceci n’est plus le cas dans les versions récentes de Linux), on peut seulement le lancer soit par un dispositif dans /dev
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 pppd du serveur s’il y en a un, puisqu’il peut utiliser le tty
des sessions
telnet ou ssh; mais pour le
pppd du client, cela entraîne un conflit en cas d’utilisation de
telnet pour établir une connexion.
En effet, telnet veut, également, être sur un tty, il se comporte presque 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 telnet sans un tty impose également un régime tel que toute la connexion échouera sur des ordinateurs « lents » (fwprc 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 telnet, vous avez besoin de cotty comme démon pour copier la sortie d’un tty sur lequel fonctionne pppd sur un autre tty sur lequel fonctionne telnet, et inversement.
Si je trouve l’abruti (probablement un gars de MULTICS™ bien que il a dû y avoir des gens d’UNIX™ 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 !
</JE ME CALME>