4.4 KiB
\newpage
Netfilter
Le projet netfilter1 est l'implémentation de pare-feu au sein du
noyau Linux. Il s'agit d'un mécanisme de filtrage des paquets réseau basés sur
des règles, chargées par l'espace utilisateur dans le noyau. On utilise pour
cela les programmes nft (du projet nftables), ou de manière historique
iptables.
Les deux projets ont une manière de fonctionner très similaire, mais il est important de ne pas les utiliser en même temps, sous peine de voir apparaître des problèmes incompréhensible à déboguer, plus ou moins aléatoirement.
Réseau fonctionnel ?
Première étape : avez-vous vérifié l'état du réseau sur le routeur ?
- Peut-il accéder à Internet ?
- Peut-il accéder aux serveurs ?
- Peut-il accéder aux stations de travail ?
Dans la configuration initiale attendue de la machine virtuelle, les réponses que vous devriez obtenir sont :
- Oui, le routeur a accès à Internet, mais ne peut pas résoudre de noms de domaine.
- Oui, les serveurs répondent aux ping et sont joignables.
- Non, les stations de travail n'obtiennent pas d'IP, on ne peut pas les contacter.
Donner accès à Internet
Votre administrateur système vous assure que le serveur de noms est bien lancé et configuré comme demandé.
Deux éléments de configuration vont devoir être mis en place sur le routeur pour corriger2 cette situation.
Après cette configuration, toutes les machines (serveurs et stations de travail) pourront accéder à Internet.
Test à passer :
Exposer un service web sur Internet
Vous avez compris comment vos machines peuvent accéder à Internet sans avoir pour autant d'IP routable sur Internet. Cependant, si cela répond parfaitement à une utilisation de type station de travail, vos serveurs web doivent être accessibles sur Internet.
En utilisant une règle de netfilter, rendez vos deux serveurs web accessibles
depuis l'interface externe du routeur. Après configuration, depuis un
navigateur sur votre poste, vous devriez pouvoir accéder à :
Deux services sur un port ?
Sur Internet, rare sont les IP qui n'hébergent qu'un seul service. Très souvent, une armée de serveur est placée derrière, comme ici, et permet de distribuer plusieurs services sur la même IP, sans que les utilisateurs n'aient à changer leur port de connexion.
La distinction est généralement réalisée sur le nom de domaine accédé. Cependant, les protocoles IP, TCP ou UDP ne transportent pas cette information. C'est donc dans la couche applicative que le nom de domaine est passé.
Par exemple, vous pouvez observer ce comportement facilement avec curl :
42sh$ curl -k https://82.64.31.248
<img style="height: calc(100vh - 5px); max-width: 100vw;" src="//ouaset.masr.nemunai.re/public/vache.svg" alt="Bienvenue sur rhakotis">
42sh$ curl -k -H "Host: adlin.nemunai.re" https://82.64.31.248
<head><title>Index of /</title></head>
</div>
En HTTP[^https], on face un en-tête `Host`, contenant le nom de domaine. Le
serveur web (généralement ici utilisé comme proxy inverse) oriente la
distribution de son contenu en fonction de cet en-tête.
[^https]: En HTTPS, le certificat est distribué avant que le client n'ait pu
envoyé de contenu. Le nom est alors passé dans un champ d'extension de
TLS. Voir le [RFC 6066](https://tools.ietf.org/html/rfc6066) à propos de
SNI.
À vous maintenant d'installer un reverse-proxy (`nginx` par exemple), pour vous
permettre d'accéder aux deux services, sur le port 80.
En utilisant le résolveur local, vous pouvez vérifier le fonctionnement de
votre reverse-proxy avec (soit sur une station de travail, soit sur le routeur
directement) :
<div lang="en-US">
```sh
42sh$ curl http://news.adlin.p0m.fr/
<title>Tiny Tiny RSS : Login</title>
42sh$ curl http://matrix.adlin.p0m.fr/
<title>Matrix</title>
-
Oui, il s'agit bien ici de non configuration : ne cherchez pas de mesquinerie de la part de l'auteur du TP. ↩︎