
Crédit photo : Le Monolecte (flickr)
Gruik gruik. Bon, ok, on parle de ports. Donc ni de porcs ni des endroits ou on range les bateaux meme si ca s’ecrit pareil. Il faudra lire l’article en entier pour comprendre l’illustration.
En informatique, un port designe deux choses
Voyons comment vulgariser la chose. Les réseaux informatiques fonctionnent par couche. La couche la plus haute (7, ou 5 selon les représentations) est généralement le protocole parlé par l’application que vous utilisez. Votre navigateur web, par exemple, sait entre autre parler avec le protocole “HTTP”, base du web (à ne pas confondre avec le langage HTTP qui, lui, sert à “programmer” les pages web elles-mêmes). La plus basse (1), c’est le protocole qui sert à coder le signal sur le support de transmission (modulation de fréquence électrique, de fréquence radio, …)
Lorsqu’une application de couche haute souhaite communiquer, elle parle à la couche inférieure. Ainsi, votre navigateur web parlant HTTP va envoyer à la couche transport (4) une demande “hey, je veux établir une connexion avec telle adresse IP en TCP”. Cette couche va discuter avec celle d’en dessous (3) qui va mettre toutes ces informations dans un paquet IP puis descendre le tout au niveau inférieur (2) qui sait comment causer à la carte réseau qui va elle-même traduire le message sur votre câble réseau (1) jusqu’au modem ADSL qui va dépiler toutes ces informations pour remonter jusqu’à la couche 3 afin de savoir ou envoyer le paquet (et ainsi de suite de routeur en routeur qui dépilent et empilent les données entre la couche 1 et la couche 3) jusqu’à la destination qui remontera au dessus à la couche 4 pour vérifier que la transmission est bien passée et envoyer la donnée utile (l’adresse du site que vous voulez consulter) au serveur web qui va formuler sa réponse et rebelotte dans l’autre sens.
C’est un peu imbitable, je sais, mais la morale de l’histoire à retenir, c’est que les couches inférieures n’ont strictement aucune notion de ce que savent faire les couches supérieures (c’est également vrai dans l’autre sens). En gros, votre navigateur web ne sait pas transporter des paquets dans un réseau et un modem ADSL ne sait pas ce qu’est le protocole HTTP.
Partant de la, pour que la liaison puisse se faire correctement, les logiciels de couche 5 discutent avec TCP (situé en couche 4 si vous avez bien retiendu la leçon) via des numéros dis “numéros de ports”. Il y en a 65534 disponible dans le protocole TCP (et pareil en UDP). Lorsque votre machine discute avec l’une de ses semblable dans l’un de ces deux protocoles dédiés au transport d’information, la transmission est identifiée par l’adresse IP source, l’adresse IP destination mais aussi le port source et le port destination. C’est ce qui vous permet de pouvoir télécharger une page web pendant que votre client peer2peer fonctionne sans que tout ne se mélange à l’arrivée.
Pour faire une analogie foireuse (once again), imaginez que vous ne puissiez pas voir ni comprendre pourquoi quelqu’un qui frappe à votre porte est la. Vous établiriez un code qui dirait que le facteur frappe au volet de la cuisine, le monsieur d’EDF à celui du salon et le livreur de lait sonne à la cloche. Votre maison disposerai donc de 3 ports de communication chacun dédiés à une fonction bien précise. Une fois la personne qui arrive est bien identifiée, elle peut rentrer dans la maison (la couche haute) par la porte.
Dans la pratique, les 65000 et quelques ports sont loin de tous être dédiés à une fonction précise. On compte un peu plus d’un millier de ports réservés par des applications courantes en TCP comme en UDP, mais dans l’absolu chacun fait ce qu’il veut. Un serveur web tourne traditionnellement sur le port 80 mais rien ne vous empêche d’en faire tourner un sur le port 42687 ou sur le 22 théoriquement réservé à SSH.
Pour revenir rapidement sur les différences entre TCP et UDP, déjà abordée dans un billet précédent, le distingo majeur est que TCP contrôle la transmission. Chaque paquet est numéroté et vérifié avant d’être envoyé au logiciel du dessus, de sorte qu’il est impossible qu’une information détériorée n’y parvienne, contrairement à UDP qui permet de passer les paquets dans l’ordre de leur arrivée (qui n’est pas nécessairement l’ordre d’émission)
Pour bien comprendre, prenez le cas du téléphone via internet qui utilise UDP. Quand il y a un problème sur le trajet, vous n’entendez plus votre correspondant (ou bien si le problème est vraiment très court vous entendez un petit glitch dans la conversation). Dès que le problème est résolu, la communication est rétablie et vous continuez à discuter.
Imaginez maintenant que le téléphone sur IP fonctionne sur TCP. En cas de problème de transport, TCP renvoi les demandes en disant “j’ai pas bien reçu la réponse, recommence” jusqu’à ce que la séquence de paquet soit continue et propre. La séquence en question contenant votre voix, si le problème dure mettons 5 secondes, lors du rétablissement, soit vos 5 secondes de paroles seront compressées et restituée à votre interlocuteur bien plus vite que l’original (donc incompréhensible), soit votre conversation sera décalée de 5 secondes.
C’est pour cela qu’on qualifie donc généralement UDP de protocole de transport pour les applications temps réel ou la récupération de données datant de plus de quelques milisecondes n’a aucune espèce d’importance, alors que TCP est utilisé pour tout le reste ou il faut absolument avoir toutes les données en bon état pour que ça fonctionne mais ou on n’est pas a une ou deux secondes près (une page web avec des images pleines de trous, ça le fait pas)

Crédit photo : Giorgio Montersino (flickr)
Notre amie haute autorité du moment a encore sorti un communiqué de presse aujourd’hui (après celui de samedi qui gueulait après un site proposant une assurance juridicotechnique contre les sanctions de la nouvelle loi).
Et je me fends la poire. Je découvre avec grande joie le monde impitoyable de la presse avec ce blog, c’est un grand bonheur.
Grosso modo, la presse, c’est un tas de gens qui se tirent la bourre à longueur de temps (24h/24 et 7j/7) pour savoir qui sortira son article en premier sur le dernier sujet sensible du moment. Vous ajoutez à cela l’immédiateté de la publication d’internet et vous obtenez un tas de gens accroché aux basques des gens qui publient des communiqués pour les reprendre partiellement, en tirer juste ce qui les intéresse (en bien ou en mal) sans jamais publier le communiqué en lui même.
Comme en prime, le sujet HADOPI est grââââve à la mode en ce moment, ça fleuri, ça foisonne !
Alors c’était quoi, ce communiqué de presse ? C’était la haute autorité qui repousse la date de la fin de la consultation à propos des logiciels labellisés HADOPI censés sécuriser l’ordinateur de Madame Michu.
Et la, les journalistes, ils rapportent l’info sur une demi ligne, dévient pendant deux pages sur une probable violation du droit administratif quand HADOPI contraint les gens à s’identifier pour obtenir le document. Certains vont même jusqu’a prétendre que l’argument avancé dans le communiqué de presse (“La question de la protection et de la sécurisation des accès à internet est cruciale à l’heure où le numérique revêt une dimension toujours plus importante et soulève de plus en plus d’intérêt”) est faux …
Ben non les enfants, parce qu’à force de faire du bruit, ça soulève de plus en plus d’intérêt. Moi, par exemple, j’aime bien gueuler contre les lois que je trouve idiotes, mais j’aime bien creuser un peu aussi, et cette consultation j’aimerais bien y répondre parce qu’avec le bruit qui a été fait autour de tout ça cet été dans nos petites galaxies associatives, je me suis intéressé au sujet, mais le 10 septembre, ça faisait trop court comme délai pour moi.
Quand est-ce que les journalistes se posent 2 minutes pour réfléchir à leurs papiers et faire un travail de fond sans toujours chercher le sensationnel qui va leur rapporter de l’audience (et/ou de la page vue) ? Manifestement jamais. Il n’y a que les gens qui s’intéressent réellement aux sujets qui prennent le temps de les creuser (au grand bonheur des journalistes qui font ce qu’ils savent bien faire, tirer le truc intéressant et jeter le reste).
Par exemple, comme travail de fond, on pourrait citer celui de la Quadrature à propos d’HADOPI. Partisan, certe, mais propre, argumenté, documenté et très bien illustré. En un mot, bravo. Les autres ne font finalement office que de flux RSS avec une fonction “résume moi ça en une page” … Dommage que ce soit au détriment du contenu et de l’information.
Un petit rappel des échéances de cette semaine.
Décision du conseil d’état à propos de la demande de suspension du décret 2010-872 formulée par FDN mercredi 8 septembre à 17h. J’ai prévu de livetweeter la chose (@turblog et dans le blender situé dans la première colonne à droite de ce blog) si d’aventure la SNCF m’autorise à me déplacer sur Paris, ce qui semble faisable, d’après le planning prévu.
Et puis, moindre importance mais il y aura des bulles, la réunion préparatoire pour la constitution d’un FDN Like Parisien. Ça se passe au Trappiste (au début de la rue St Denis) vendredi en fin de journée.

Crédit photo : Simon Collison (flickr)
En tant qu’interface chaise clavier (oui, c’est de vous que je parle), pour connaitre l’IP qu’utilise votre ordinateur, vous pouvez lancer ipconfig qui va vous renseigner sur l’adresse de l’ordinateur. Si cette adresse commence par 10, par 192.168 ou par 172.16, vous avez perdu, c’est une adresse locale qui ne va pas plus loin que le modem ou le routeur qui se situe à proximité.
Pour connaitre votre adresse sur internet, vous devez utiliser un petit service extérieur, par exemple ici.
L’IP n’a rien de confidentiel puisque comme je l’ai deja expliqué dans d’anciens articles, chaque paquet de données qui sort de chez vous la porte sur le front comme le nez au milieu de la figure. Le service qui vous l’indique ne fait donc pas de magie noire, il ne fait que l’extraire de votre propre demande pour vous la montrer.
Mais le sujet de ce billet s’adressait surtout aux machines elle-mêmes. Pour ressituer la problématique, nous allons encore une fois prendre windows comme exemple. Vous êtes peut-être déjà consulté la rubrique “paramètres réseaux” et constaté, au choix, que l’adresse locale de votre machine était renseignée à la main ou, plus probablement, que la case “obtenir automatiquement une adresse” était cochée.
Alors, comment marche cette attribution automatique ? Tant que l’ordinateur n’a pas d’IP, il ne peut théoriquement pas communiquer avec ses petits copains, sauf qu’à coté d’IP existe un protocole nommé ARP qui fonctionne avec les adresses MAC (voir par ici pour avoir une vague idée de ce que c’est).
Concrètement, le PC sans domicile fixe va envoyer un SOS général à tout le reseau local, demandant en gros “heee, y’a quelqu’un qui peut me renseigner ??”. La, deux solutions :
Mais DCHP ne s’arrête pas à ça. Il est aussi capable par exemple d’indiquer à une machine quelque chose qui ressemble à “si tu n’as pas de système d’exploitation disponible, tu peux aller demander de quoi démarrer à l’autre la bas”. Il indique aussi une durée de vie à l’information qu’il fourni. Passé ce délai, votre ordinateur va aller reposer la question pour obtenir des infos fraiches (qui, la plus part du temps, n’auront pas changé)
Ce mécanisme d’affectation d’adresses et d’informations réseau est, même s’il ne porte pas forcement le nom de DHCP, également utilisé par votre machinbox pour obtenir l’IP publique fournie par le FAI.
Le fait de bénéficier d’une IP fixe ne dispense pas nécessairement d’utiliser de l’allocation d’adresses dynamique, ne serait-ce que par exemple parce que les DNS peuvent changer et qu’il est tout de même plus simple de modifier la configuration d’un serveur central qui distribue l’information plutôt que d’avoir à prévenir tous les clients du changement et d’attendre jusqu’à la fin des temps qu’ils aient tous effectué la modification pour terminer sa migration.
Comme raconté en milieu de semaine, j’ai rencontré mardi dernier Eric Walter, secrétaire général de la HADOPI. Quelques personnes m’ont reproché de ne pas avoir assez relaté le discours de mon interlocuteur dans mon billet, c’était plus ou moins voulu.
Pour corriger ça et aussi pour récolter d’autres questions pertinentes si certains en ont (voir rubrique contact, la haut), vous trouverez ci dessous la liste des interrogations que je lui ai transmise ce jour. Il m’a promis une réponse dans le courant de la semaine prochaine.
Je me suis posé des questions sur l’opportunité d’organiser une interview live, mais il m’a semblé, au final, plus constructif qu’il dispose du temps nécessaire au développement de réponses plus intéressantes que ce que nous avons vu sur La Tribune, histoire d’engager une démarche de dialogue et pas d’opposition systématique comme je le disais hier dans mon billet-bisounours.
Suite à cet mon article expliquant comment prendre l’IP de quelqu’un, qui à lui même été repris sur OWNI, Michael de anti-hadopi.com indique qu’il est aujourd’hui impossible d’envoyer un paquet avec une fausse IP source :
Tous les routeurs de tous les ISP du monde et a fortiori les routeurs centraux des carriers appliquent par défaut une règle qui interdit le “source routing”. Donc, pas de chance, si vous envoyez un paquet avec une adresse source différente de la votre il ira tout simplement à la poubelle sans bruit … Ca serait un peu trop facile quand même ;-)
Hormis le fait qu’il est strictement impossible, pour ce que Michael appelle un “carrier” (un fournisseur de transit mondial, dans notre jargon), de configurer ses équipements pour détecter les fausses IP dans les paquets, tant le trafic est dense et mouvant (il peut à un instant T arriver par telle route puis basculer par telle autre), je me suis posé la question de savoir si, depuis mes derniers tests datant d’il y a plusieurs années, les fournisseurs d’accès avaient effectivement configuré leurs routeurs de coeur de réseau pour dire “si tu vois passer un paquet en provenance des abonnés vers dehors et qu’il n’a pas une IP source sous notre responsabilité, jette le”.
Je n’ai bien entendu pas testé tous les FAI de France et de Navarre, ce serait trop long, mais j’ai fais deux tests. La méthodologie est basique, je dis à ma machine qu’elle est responsable de la fausse IP et j’utilise la fonction -S de ping pour envoyer un paquet avec cette IP source. Du coté de la destination, je lance un logiciel d’écoute sur le réseau (tcpdump) en lui demandant de m’afficher tout le trafic qui provient de cette fausse IP source. Si je vois arriver les paquets que j’envois, c’est qu’aucun des opérateurs traversés n’a jeté mes demandes. Je ne vous fais pas de copier/collé du résultat, c’est totalement falsifiable, il faudra me croire sur parole ou tester vous-même pour vérifier.
Premier test, envoyé depuis un réseau situé derrière TATA Communications (opérateur indien), un paquet avec une IP Bouygues Telecom vers le réseau de BULL : je recoit sans problèmes les paquets.
Second test, envoyé depuis une machine hébergée chez Free (Dedibox), un paquet avec une IP de l’hébergeur OVH vers une machine chez Orange : ça passe aussi.
La méthode est discutable :
Une chose est claire, il est tout à fait possible, de nos jours, d’envoyer des paquets falsifiés d’a peu près n’importe ou sur le réseau, n’en déplaise à Monsieur anti-hadopi.com qui semble persuadé du contraire.
Comme on l’a déjà vu, internet est un monde peuplé de câbles divers et variés (cuivre, fibres …) ainsi que de quelques liaisons sans fil (wifi, satellite …) mais la logique du réseau en lui même n’est pas plate comme l’est l’infrastructure physique, loin s’en faut.
Il existe une infinité de mécanismes permettant de virtualiser des liens, si bien qu’aujourd’hui, la topologie logique d’un réseau telle qu’on la voit quand on l’étudie n’a pas grand chose à voir avec la réalité.
Avant d’aller plus loin, je dois vous parler des switchs. Dans les temps reculés de l’histoire des réseaux, on utilisait des hubs (bon, pas si reculé que ça, j’en ai encore un accroché à un mur dans mon sous sol). Le principe etait simple, tout paquet arrivant sur le hub était immédiatement copié sur tous les ports pour aller vers toutes les machines qui se chargeaient de faire le tri. C’était pas le Pérou, du coup on a inventé le switch qui, lui, fait le tri et n’envoie a chaque machine que le trafic qui lui est réellement destiné.
Le hub, tout comme le switch, n’a (sauf exception) pas la moindre fichue idée de ce qu’est une adresse IP. Il ne fonctionne qu’avec les adresses MAC propres a chaque équipement. Lorsqu’une machine a un paquet pour une autre, elle lance a la cantonade (broadcast) un appel sur le réseau local “heyy, c’est quoi la mac qui utilise telle IP” et construit son petit paquet avec cette MAC. Le switch, quant a lui, connait toutes les macs présentes et sait que ce paquet ira sur tel port. Il sait aussi faire des choses magiques comme par exemple se virtualiser lui même.
Prenons un exemple tout bête. Lorsque vous branchez votre box ADSL, vous la reliez d’un coté a votre ordinateur et de l’autre a la prise de téléphone. La box agit, entre autre, comme un convertisseur de média entre l’ADSL utilisé par votre FAI et l’ethernet utilisé par l’ordinateur.
Imaginez maintenant que votre FAI arrive directement en ethernet chez vous (avec la fibre par exemple). Si la machinbox n’effectue aucune action intéressante, vous pouvez éventuellement brancher directement la fibre sur votre ordinateur. Mais si votre FAI ne vous octroie qu’une seule IP, vous aurez besoin de la machinbox pour faire du NAT. vous branchez donc la fibre a la box, la box a un switch et vos ordinateurs aussi.
Mais vous pouvez aussi brancher la fibre au switch et pas a la box. Du coup, vous vous dites que le trafic fait directement fibre -> ordinateur. Eh ben raté, votre switch peut tout a fait créer un réseau virtuel (VLAN) entre la fibre et la box et un second entre la box et les ordinateurs. Vu depuis votre chaise vous avez un réseau en étoile autour de votre switch, mais vu depuis l’extérieur, vos ordinateurs sont derrière la machinbox.
Abordons un exemple plus poilu. Vous avez crée votre petit réseau de voisinage dans votre bled et pour le raccorder à internet via la fédération FDN, vous devez tirer 120km de fibre a travers la foret des Landes pour aller jusqu’à un datacenter situé à Bordeaux.
Ça va vous couter les deux couilles, mais une entreprise locale est prête à financer une partie de l’opération si elle elle peut utiliser la fibre par la suite. Par contre, le milieu associatif, c’est pas trop son trip, elle, au bout, elle veut mettre Orange. Bon, l’erreur est humaine, il ne faut pas lui en vouloir.
Pas de problème monsieur, un switch à chaque bout de la fibre, un vlan pour le petit FAI, et un autre pour l’entreprise. Les flux de données emprunteront le meme chemin pendant un temps mais seront 100% isolés l’un de l’autre.
Un autre exemple de virtualisation très répandu, c’est L2TP. C’est l’un des protocoles qui, lorsque vous êtes (par exemple) abonné chez FDN, transportent vos données depuis votre modem ADSL jusqu’au coeur du réseau FDN. Vous n’avez strictement aucun moyen de savoir par ou passe votre trafic, ni géographiquement, ni du point de vue des opérateurs intermédiaires.
Il existe beaucoup d’autres moyens de virtualiser le réseau, la liste serait trop longue, mais il faut quand même que je vous parle des fameux VPN (parce qu’à la base, je ne voulais parler que de ça).
Pour bien comprendre le VPN, il suffit de faire comme si c’était un lien physique et bien réel. Vous êtes abonné chez votre FAI, mais pour éviter de vous faire trancher votre internet par HADOPI quand mamie télécharge Derrick, il vous faut une IP qui n’a pas un tatouage “français” sur la tête. Vous allez donc prendre votre pelle, votre pioche et un gros bateau et aller tirer votre fibre jusqu’à New York ou vous trouverez l’IP qui fera le bonheur de grand maman.
Ou alors, vous êtes plus pragmatique et vous faites un VPN. point de vue réseau, c’est strictement la même chose, à ceci prêt que le VPN sera toujours moins performant qu’une liaison directe puisque les données empruntent des chemins détournés.
En pratique, quand vous établissez un VPN, vous créez une carte réseau virtuelle dans l’ordinateur (et dans celui de l’autre coté) et un système de transport quelconque assure la création d’un câble virtuel entre les deux. Ce câble peu éventuellement être chiffré pour assurer la confidentialité des données (c’est d’ailleurs à ça que servaient les VPN au départ, cacher le contenu des transmissions aux opérateurs intermédiaires)
Le VPN le plus basique se bornera à ouvrir une connexion TCP entre votre ordinateur et un serveur VPN chez le fournisseur, mais il existe un tas de moyen vicieux et plus ou moins performant pour faire un VPN. Le lien virtuel peut être établi a peu près sur n’importe quoi, au travers de multiples connexions pouvant ressembler à une session de navigation sur le web pour tromper un firewall d’entreprise qui n’autorise que le web par exemple. On peut aussi utiliser le système DNS ou l’ICMP. Certains sont même allés jusqu’à créer des liens virtuels de ce genre ou les données sont transportées par pigeons voyageurs (système de transmission loin d’être inefficace point de vue débit) pendant que d’autres réfléchissent à la meilleure façon d’utiliser pastebin ou twitter pour la transmission.
Lorsque les gens qui veulent réguler et censurer internet auront compris ces principes, on aura fait un grand pas :)
Dans la série sur le montage d’un hébergeur, et un peu partout, je parle de NAT. Beaucoup savent plus ou moins vaguement ce que c’est. Allons-y donc. (L’illustration est signée nurdcartoon ! Un grand merci à Pascal et désolé d’avoir du réduire l’image pour la faire rentrer)
Network Address Translation, non, il ne s’agit pas de téléporter des IP mais de les transformer. De transformer par exemple les adresses d’un petit réseau local numérotées dans le bloc 192.168.0.0/24 en une seule et unique IP publique attribuée par le FAI pour que tous les ordinateurs du réseau puissent avoir accès à l’exterieur.
Pourquoi le FAI ne donne pas plusieurs adresses ? D’une part parceque ca fait un sacré boulot de suivi, d’autre part parce qu’on manque globalement d’adresses sur l’ensemble du réseau et enfin parce que la moyenne des clients d’aujourd’hui n’a pas besoin de plus d’une IP. Notez que notre FDN national fourni des IP par bloc sur simple demande justifiée et argumentée et sans surcout (ben oui, les IP, ça ne s’achète pas, en vrai, ça se demande poliment)
L’autre vrai fausse bonne raison de faire du NAT, c’est la sécurité. Lorsqu’une machine dispose d’une IP routable, elle est directement exposée à tout ce qui arrive de l’extérieur. Si d’aventure un logiciel fonctionne sur la machine et agit comme un serveur avec un port ouvert, il est potentiellement exploitable de l’extérieur pour compromettre la machine.
Le NAT déporte le problème sur l’équipement à qui l’adresse IP publique est attribuée, généralement, votre machinbox. Lorsqu’un paquet arrive de l’extérieur vers cette IP sans correspondre à un flux de données qui a été démarré par un ordinateur situé dans notre réseau, la machinbox réponds ”va te faire voir” voir ne répond pas du tout.
C’est une vrai fausse sécurisation, parce que lors de l’inévitable passage à IPv6, ça va faire tout drôle à beaucoup de gens de se retrouver en frontal avec la jungle d’internet sans aucune protection en amont. C’est d’ailleurs un sujet donnant lieu à des débats assez poilu … “faut-il instaurer un NAT IPv6 ?” ou encore “est-il de la responsabilité du FAI de s’assurer que rien de méchant n’arrive jusqu’à l’ordinateur du client ?”. Pour ma part, comme avec les enfants, répétition / pédagogie, mais éviter au maximum les mesures coercitives, même si “c’est pour votre bien”.
Lorsqu’on veut distribuer du contenu depuis chez soi derrière sa machinbox, on est mal, dans la mesure ou par défaut on ne peut faire que des connexions qui démarrent de chez soi, exit donc les gens qui viennent consulter votre site, votre machinbox les renverra dans leur pénates à grands coups de pieds dans l’arrière train. On a, en plus, souvent des problèmes de performances, la machinbox n’étant pas toujours capable de suivre la cadence lorsqu’on établi trop de connexions en même temps (cas du peer2peer, par exemple)
Heureusement (chez les 3 plus gros en tout cas), vous pouvez paramétrer la machinbox pour l’obliger à transmettre ce qui vient de dehors, c’est à dire récupérer une connexion entrante sur l’IP publique pour la faire atterrir sur une machine qui a une IP privée sur le réseau local. Ça ne règle pas le problème de perf, mais au moins, vous êtes joignable.
Il ne faut pas oublier que dans notre ami TCP (le protocole situé au dessus d’IP, utilisé par une grosse partie des applications sur le réseau), il y a un nombre de ports limités disponibles (plus de 65000 tout de même, il y a de quoi voir venir), mais surtout, qu’un port précis correspond généralement à quelque chose. Le web d’aujourd’hui utilise le 80 pour les transmissions de données en clair et le 443 pour les transmissions chiffrées, mais ce n’est qu’une convention, vous pouvez parfaitement accéder à un site tournant sur un serveur situé sur un autre port en utilisant une URL précisant le port : http://www.lesite.com:80/
Du coup, puisque vous n’avez qu’une adresse IP publique, vous n’avez qu’un seul port 80 publique, impossible donc de le répartir directement entre deux machines différentes chez vous, à moins de vouloir expliquer à vos visiteurs qu’il faut taper http://www.monpetitchezmoi.com:8081/ dans leur navigateur.
Vous allez donc expliquer à votre machinbox que “le port 80 de ton IP publique, tu va le renvoyer vers le port 80 de l’IP 192.168.0.10″. Cette IP est celle de votre machine (“ipconfig” dans cmd sous windows pour connaitre l’IP réelle de sa machine, “ifconfig” sous FreeBSD ou Linux)
Que va faire la machinbox ? Elle va attendre sagement les paquets qui vont arriver, et lorsqu’un paquet dira qu’il veut accéder au port 80 de l’IP publique en TCP, elle va tout simplement changer l’adresse IP de destination pour y mettre l’adresse de la machine locale et envoyer le paquet en l’état sur le réseau local. Lorsque votre machine va répondre, elle va indiquer son IP privée comme source du paquet, la machinbox va donc remettre l’IP publique à la place avant de renvoyer le paquet sur Internet pour que le demandeur de la connexion s’y retrouve.
Histoire d’être complètement exhaustif, elle va aussi toucher au port source du paquet pour s’y retrouver elle-même, mais ça n’a pas grand intérêt ici.
Vous voilà paré pour que l’extérieur puisse communiquer avec votre ordinateur. Du coup, vous avez une nouvelle obligation, celle de tenir à jour le logiciel utilisé sur votre ordinateur et répondant au port que vous avez ouvert sur votre machinbox, car si il y a une faille de sécurité dans le soft en question, tôt ou tard, elle sera exploitée
Nous reviendront à notre série hébergement avec un billet généraliste à propos de l’ensemble des composantes logicielles impliquées.
Ça va bien cinq minutes d’être hadopi-centric mais on a du boulot.
Vous avez déjà théoriquement compris, si vous avez tout bien lu la série sur le montage d’un fournisseur d’accès et le début de celle sur le montage d’un hebergeur, que pour être hébergeur, il faut avoir de l’internet (géré par vous même ou par votre fournisseur d’accès, peu importe) avec une ou plusieurs ip fixes (c’est mieux, mais pas obligatoire) et au moins une machine à mettre au bout.
Une machine qui d’ailleurs n’a rien de spécial. Votre PC de bureau voir même le vieux cadavre du PC précédent suffiront, il vous suffit de dire que c’est un serveur et hop, c’en est un. Il faut aussi, si vous publiez effectivement un contenu avec, penser à le laisser allumé tout le temps. Comme je vous le disais au début, le fond du problème est de savoir ce que vous voulez (ou pouvez) externaliser dans ce métier. Pour pouvoir couvrir la totalité du sujet, je vais souvent prendre le parti de l’internalisation totale, mais, pour le billet qui nous occupe, notez que vous pouvez très bien louer un serveur à l’extérieur pour faire tout ceci, si, par exemple, il n’est pas imaginable pour vous d’avoir une machine allumée en permanence chez vous ou que vous prévoyez un trafic d’accès à votre contenu dépassant la capacité de votre liaison internet.
Pour que notre tout nouveau serveur fonctionne comme on le souhaite, il suffit d’y installer des logiciels. Un serveur web, un resolver DNS, un FTP, un MTA ou bien tout simplement, chose beaucoup plus répandue de nos jours (quoi que de moins en moins), un logiciel de peer2peer qui agit a la fois comme client et comme serveur. La qualité de serveur ou de client dépend uniquement du comportement du logiciel que vous installez, pas de votre position sur le réseau, de la taille de votre portefeuille ou autre.
Petit aparté au sujet des logiciels, on attends d’ici une quinzaine la première version de Diaspora, un réseau social décentralisé auquel vous pourrez participer sur le principe du peer2peer, en installant le logiciel sur votre ordinateur. Vous pourrez aussi bien sur l’utiliser sans rien installer en squattant les installations faites par les autres. C’est une petite révolution dans le monde du réseau social et ça risque de réhabiliter un brin le peer2peer à l’avenir si l’équipe qui a monté le projet se débrouille bien.
Nous verrons un peu plus tard les spécificités logicielles des serveurs fonctionnant avec des systèmes d’exploitation libre (FreeBSD, Linux, …). Nous allons commencer par ce que Mme Michu a probablement à sa disposition sans avoir à trop se casser la tête : Windows.
Microsoft fourni une suite logicielle contenant IIS qui n’est (presque) qu’un vulgaire serveur web. Le pendant de votre navigateur si vous préférez. Mais sa prise en main n’est pas nécessairement évidente pour le néophyte, nous allons donc illustrer l’exemple avec quelque chose de plus simple.
Je dois vous avouer que je n’ai pas utilisé de Windows en tant que serveur depuis plus de 10 ans, je (re) découvre donc en même temps que vous.
J’ai jeté mon dévolu sur lighttpd que vous pouvez télécharger ici (ou ailleurs en cherchant un peu si ce lien venait à disparaître). Je vous passe l’installation en elle même qui n’a rien de particulier. Vous devriez obtenir, à la fin, un joli dossier ou vous trouverez un sous dossier “bin”.
La dedans, un Service-Install.exe permet de terminer la configuration et de faire que lighttpd fonctionne en permanence en tache de fond (qu’il devienne un “service” de Windows). Ne cherchez pas d’interface graphique de configuration, il n’y en a pas.
Une fois terminé l’installation du service et son lancement, ouvrez votre navigateur et allez sur votre site : http://localhost/
Vous tomberez sur la page par défaut de lighttpd qui vous dit grosso modo qu’il est bien installé.
Allez maintenant dans le dossier C:\program filles\lighttpd\htdocs, faites un clic droit sur le fichier index.html puis ouvrir avec -> bloc note, effacez tout ce qui est apparu dans le bloc note et inscrivez juste “je suis le roi d’internet” puis sauvegardez et retournez dans votre navigateur pour rafraîchir la page.
Voila, vous êtes hébergeur (je vous le concède, le contenu est loin d’être intéressant, mais ça, c’est de votre faute).
Pour vous en convaincre, faites vous inviter chez votre voisin pour l’apéro, muni de votre adresse IP notée sur un papier et tapez dans son navigateur http://votre_ip/, vous devriez retrouver votre petite phase. Reste à vous trouver un nom de domaine et à le configurer comme il faut (voir le billet précédent)
Vous venez, mine de rien, de toucher du doigt l’un des principes de la neutralité d’internet : pouvoir publier du contenu sans être contraint de s’appuyer sur un intermédiaire, sans avoir à demander le droit à qui que ce soit. C’est comme ça que Google à commencé.
Vous n’irez bien sur pas très loin puisqu’avec ce que nous avons installé la, vous ne pourrez publier que du texte et de la page HTML brute, sans langage dynamisant (du genre PHP), sans base de données, etc … Mais c’est le début de l’aventure !
Il se peut que ça fonctionne chez vous et pas chez le voisin (c’est même fortement probable). Trois possibilités :
A venir, un article hors série sur les box ADSL et le Nat, pour tordre le cou à la seconde possibilité qui, si mon petit doigt ne m’a pas menti, risque d’être aujourd’hui la plus récurrente.