David Madore's WebLog: Séances de hacking réseau

Index of all entries / Index de toutes les entréesXML (RSS 1.0) • Recent comments / Commentaires récents

Entry #2028 [older|newer] / Entrée #2028 [précédente|suivante]:

(lundi)

Séances de hacking réseau

Il ne faut jamais désespérer : malgré les différentes difficultés que j'ai eues avec mon DreamPlug (entrées précédentes ici, et ), qui se sont toutes plus ou moins résolues, j'ai maintenant réussi à en faire quelque chose d'utile, c'est-à-dire un routeur en amont du PC qui est chez moi (entre ce dernier et mon modem ADSL) avec point d'accès Wifi. Je n'ai pas encore pris toutes les dispositions pour pouvoir éteindre mon PC la nuit, mais au moins, s'il y a de nouvelles difficultés qui surviennent sur ce front-là, elles ne seront plus la faute du DreamPlug.

J'ai donc passé, essentiellement ce week-end, de longues séances de hacking réseau pour reconfigurer tout ce fatras, ostensiblement pout traquer les hypothèses que j'avais pu faire (que mon PC est aussi routeur) et qui seraient devenues erronées, et en réalité pour m'amuser à peaufiner les détails et à faire joujou avec la couche réseau de Linux, qui, il faut bien le dire, est assez ludique.

J'ai fait quelque chose d'un peu inhabituel (s'agissant de la configuration IPv4 ; la configuration IPv6 ne posait aucune difficulté particulière vu que les adresses sont en nombre essentiellement illimité), que je peux peut-être expliquer, histoire de signaler que c'est parfaitement possible et que ça ne pose pas de problème (vu que beaucoup de gens à qui j'ai posé la question en amont se sont montrés sceptiques), c'est de donner à mon PC, et pas au DreamPlug routeur que j'ai intercalé en amont, l'adresse IP publiquement visible de la connexion ADSL.

Je détaille. Il est bien connu que les adresses IPv4, contrairement aux v6, sont en nombre sévèrement limité. Un fournisseur d'accès Internet par ADSL vous donne une adresse IP(v4) publique, si tant est qu'il vous en donne une fixe (il y a quelques gros nuls qui n'ont même pas cette option), quel que soit le nombre de PC que vous mettiez derrière. Si on a plus qu'un PC sur la connexion, donc, ces PC (tous sauf au plus un) utiliseront des adresses « privées », c'est-à-dire qu'elles ne doivent pas circuler en-dehors du réseau local : typiquement ce sont des adresses en 192.168.y.z ou 10.x.y.z (je ne sais pas comment ces nombres ont été choisis historiquement, d'ailleurs, et je ne sais pas pourquoi les 192.168.y.z sont plus populaires alors qu'elles sont plus chiantes à taper). Lorsqu'un PC utilisant une de ces adresses privées envoie un paquet IP vers le monde extérieur, un routeur quelque part, typiquement le dernier routeur avant le modem ADSL (ces deux équipements étant réunis en un seul sous la forme des « *box » que la plupart des usagers possèdent, et qui sont en fait presque toujours des systèmes Linux), doit transformer l'adresse IP privée de l'émetteur en l'unique adresse IP publique de la connexion, qui seule peut circuler sur le réseau, et ce routeur doit également retenir cette opération (on parle de connection tracking) de façon à pouvoir convertir en sens inverse le paquet de retour, i.e., savoir à quelle IP privée il est destiné alors que formellement il est adressé à l'unique IP publique de la connexion. Ce mécanisme s'appelle le masquerading IP, ou plus formellement NAT (pour Network Address Translation) ; dans le monde Windows/Mac non technique, on parle de partage de connexion (ce qui décrit bien le but de l'opération, mais pas le mécanisme). Il s'accompagne de toutes sortes de problèmes, mais on n'a pas d'autre choix tant qu'on continue à utiliser IPv4.

Sous Linux, on met en place ce mécanisme au moyen d'iptables, en envoyant les paquets vers la cible SNAT (ou MASQUERADE ou éventuellement SAME, la différence étant assez peu importante) dans la chaîne POSTROUTING de la table nat. On peut aussi faire du NAT entrant, c'est-à-dire indiquer que certains types de paquets entrants sur l'adresse publique doivent être réécrits (typiquement en fonction de leur numéro de port de destination) pour aller vers telle ou telle IP privée interne : dans ce cas la cible est DNAT.

Comme je l'ai écrit, tous les PC derrière la connexion sauf au plus un doivent utiliser des IP privées. Il se peut que tous utilisent des IP privées, mais on peut donner à une machine l'IP publique de la connexion. Tous les guides de configuration vous préconiseront la même chose : que ce soit le routeur-masqueradeur (celui qui réécrit les adresses des paquets, donc) qui reçoive l'IP publique, et tous ceux qui sont derrière, des IP privées. En vérité, ce n'est absolument pas une obligation : le routeur peut très bien avoir une IP privée et faire de l'auto-masquerading, c'est-à-dire réécrire les paquets qu'il émet lui-même, alors qu'un autre PC aurait l'IP publique. La configuration est tout à fait la même, et cela ne pose pas de difficulté particulière[#] et n'introduit pas spécialement de complication (sauf peut-être dans la tête de celui qui essaie de comprendre ce qui se passe et qui est habitué au schéma le plus usuel). A priori, le PC ayant l'IP publique va recevoir tous les paquets entrants qui ne font pas partie d'une connexion déjà établie (certains outils de configuration appellent ça — à mon avis à tort — la machine DMZ) ; mais on peut évidemment choisir de les répartir différemment (avec la cible DNAT sous Linux).

Quel est l'intérêt ? Tout simplement de changer les choses le moins possible : jusqu'à présent, c'était mon PC qui avait l'adresse publique de ma connexion ADSL, 213.41.184.174, enregistrée dans le DNS sous le nom de vega.gro-tsen.net, je voulais toujours pouvoir utiliser ce nom-là, à la fois depuis l'intérieur et depuis l'extérieur de mon réseau local, pour accéder à ce PC, et si possible ne pas avoir à changer de configuration sur ce PC où j'aurais pu supposer implicitement que son IP était 213.41.184.174. La solution traditionnelle pour ça consiste à rediriger les paquets voulus sur cette machine, et à faire du DNS différencié (split-horizon), où les machines extérieures voient l'adresse 213.41.184.174 associée au nom DNS vega.gro-tsen.net, tandis que les machines intérieures voient l'IP privée qui lui aurait été affectée : je trouve ça beaucoup plus alambiqué que ce que j'ai choisi, qui est de tout simplement garder l'IP que j'avais avant, et de donner une IP privée au routeur.

(Soit dit en passant, comme je n'ai jamais vraiment eu l'occasion de regarder des *box commerciales, je ne sais pas bien ce qu'elles font dans ce domaine, et notamment ce qu'elles proposent pour l'attribution des IP du réseau interne.)

Mais bon, tout ça ça a pris très peu de temps à mettre en place. Le reste du temps a été occupé à lire les manuels et à m'émerveiller (oooooh, je peux faire ça avec les paquets ? mais c'est rigolo, il faut absolument que je trouve un prétexte pour m'en servir). Je vais sans doute faire encore un peu joujou avec le Wifi, d'ailleurs.

Quand les choses seront bien rôdées, j'installerai sans doute une configuration du même style chez mes parents (où, actuellement, c'est un vieux PC de récup[#2] qui sert de routeur : je pense que ce sera plus pratique — et plus efficace énergétiquement — de mettre un GuruPlug ou DreamPlug à la place).

[#] Bon, j'exagère, il y a une chose qui pose une petite difficulté : c'est que le démon pppd, qui gère la connexion ADSL, n'a pas d'option prévue pour lui dire lors de la négociation de la connexion, il faut que tu fasses semblant d'accepter l'adresse IP que t'attribuera le pair, mais en fait tu en prendras une autre (puisque le pair nous attribuera l'IP publique mais qu'en fait on veut en prendre une privée). Pour ma part, j'ai fait ça en ajoutant un petit script que j'ai appelé /etc/ppp/ip-up.d/0fixpppaddr et dont le contenu est essentiellement ceci :

#! /bin/sh
# Change the local endpoint address on the ppp link to 192.168.0.1
# despite what ppp itself negociated.
/bin/ip addr del "$4" peer "$5" dev "$1"
/bin/ip addr add "192.168.0.1" peer "$5" dev "$1"
# Reinstate default route which was deleted in the process:
/bin/ip route add default dev "$1"

[#2] Un bi-Pentium II 450. Et quand je dis bi, il a vraiment deux processeurs physiquement distincts. Ça c'est quelque chose qui ne se trouve plus trop, de nos jours, sauf à aller taper dans du matos vraiment cher. Du coup j'ai une certaine réticence à jeter cette machine, quand même.

↑Entry #2028 [older|newer] / ↑Entrée #2028 [précédente|suivante]

Recent entries / Entrées récentesIndex of all entries / Index de toutes les entrées