tuto/nat: update 2021
This commit is contained in:
parent
66efc3bb70
commit
ea61426809
|
|
@ -1,6 +1,6 @@
|
|||
include ../pandoc-opts.mk
|
||||
|
||||
SOURCES = tutorial.md what.md netfilter.md wks.md rendu.md
|
||||
SOURCES = tutorial.md what.md netfilter.md revproxy.md wks.md rendu.md
|
||||
|
||||
|
||||
all: tutorial.pdf
|
||||
|
|
|
|||
|
|
@ -68,67 +68,23 @@ 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
|
||||
En utilisant une règle de `netfilter`, rendez vos trois serveurs web accessibles
|
||||
depuis l'interface externe du routeur. Après configuration, depuis un
|
||||
navigateur sur votre poste, vous devriez pouvoir accéder à :
|
||||
|
||||
<div lang="en-US">
|
||||
* `http://$EXT_ROUTER_IP:8080/` : TinyTinyRSS
|
||||
* `http://$EXT_ROUTER_IP:80/` : Vitrine
|
||||
* `http://$EXT_ROUTER_IP:8080/` : Miniflux
|
||||
* `http://$EXT_ROUTER_IP:8448/` : Matrix
|
||||
</div>
|
||||
|
||||
|
||||
Deux services sur un port ?
|
||||
---------------------------
|
||||
### Miniflux
|
||||
|
||||
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.
|
||||
Utilisez le nom d'utilisateur `adeline` pour vous connecter à
|
||||
miniflux. N'oubliez pas de changer le mot de passe avant que quelqu'un
|
||||
d'autre s'en charge à votre place !
|
||||
|
||||
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` :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ dig +short adlin.nemunai.re
|
||||
82.64.31.248
|
||||
42sh$ curl https://adlin.nemunai.re
|
||||
<head><title>Index of /</title></head>
|
||||
|
||||
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>
|
||||
```
|
||||
</div>
|
||||
Si vos serveurs ont bien accès à Internet, vous pourrez mettre à jour
|
||||
la liste des flux pré-enregistrés dans miniflux, afin de faire un peu
|
||||
de veille !
|
||||
|
|
|
|||
|
|
@ -25,18 +25,49 @@ en fonction de votre organisation ou de vos choix) :
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP3/router.yml
|
||||
login_x-TP3/matrix.yml
|
||||
login_x-TP3/hosts
|
||||
login_x-TP3/site.yml
|
||||
login_x-TP3/group_vars/all
|
||||
login_x-TP3/playbooks/basis.yml
|
||||
login_x-TP3/playbooks/router.yml
|
||||
login_x-TP3/playbooks/matrix.yml
|
||||
login_x-TP3/playbooks/name-server.yml
|
||||
login_x-TP3/playbooks/vitrine.yml
|
||||
login_x-TP3/roles/common/tasks/main.yml
|
||||
login_x-TP3/roles/matrix-synapse/defaults/main.yml
|
||||
login_x-TP3/roles/matrix-synapse/tasks/main.yml
|
||||
login_x-TP3/roles/matrix-synapse/templates/homeserver.yaml.j2
|
||||
login_x-TP3/roles/name-server/defaults/main.yml
|
||||
login_x-TP3/roles/name-server/tasks/main.yml
|
||||
login_x-TP3/roles/name-server/templates/myzone.j2
|
||||
login_x-TP3/roles/revproxy/defaults/main.yml
|
||||
login_x-TP3/roles/revproxy/tasks/main.yml
|
||||
login_x-TP3/roles/revproxy/templates/nginx.conf.j2
|
||||
...
|
||||
```
|
||||
</div>
|
||||
|
||||
Le seul fichier devant impérativement se trouver à la racine de votre tarball
|
||||
est `router.yml`. Le reste de l'arborescence est laissé à votre discrétion du
|
||||
moment que vous n'oubliez pas de fichiers.
|
||||
|
||||
Le fichier `matrix.yml` correspond au serveur Matrix que vous avez pu mettre en
|
||||
place au TP2, qui ne devrait pas nécessiter plus de travail pour le TP3.
|
||||
### Check-list minimale
|
||||
|
||||
- Votre routeur route les paquets IPv4 et IPv6,
|
||||
- votre routeur fournit du DHCP sur le réseau des stations de travail, afin qu'elles puissent accéder à Internet normalement et aux serveurs,
|
||||
- votre routeur filtre les paquets entrants (IPv4, IPv6) selon la politique que vous avez défini,
|
||||
- votre routeur bloque les connexions entrantes vers le réseau des stations de travail,
|
||||
- votre routeur effectue du NAT en IPv4 pour les serveurs et les stations de travail.
|
||||
|
||||
- Votre vitrine est exposée en HTTP et HTTPS,
|
||||
- les options HTTPS ont été choisies avec soin, selon les recommandations de l'ANSSI,
|
||||
- le visiteur est redirigé systématiquement vers la version HTTPS,
|
||||
- le visiteur est redirigé vers `www.login_x.srs.p0m.fr` lorsqu'il visite `login_x.srs.p0m.fr`,
|
||||
- `news.login_x.srs.p0m.fr` affiche miniflux,
|
||||
- `matrix.login_x.srs.p0m.fr` est prêt.
|
||||
|
||||
- Votre serveur de nom de domaines est accessible en TCP et UDP,
|
||||
- votre nom de domaine se résout depuis un résolveur public,
|
||||
|
||||
- La configuration de tous les serveurs accessibles respectent les recommandations de l'ANSSI,
|
||||
- votre IPv6 publique peut évoluer en changeant simplement une variable `group_vars/all`.
|
||||
|
||||
|
||||
## Signature du rendu
|
||||
|
|
|
|||
|
|
@ -0,0 +1,96 @@
|
|||
\newpage
|
||||
|
||||
Reverse-proxy
|
||||
=============
|
||||
|
||||
Plusieurs 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 serveurs 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` :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ dig +short adlin.nemunai.re
|
||||
82.64.31.248
|
||||
42sh$ curl https://adlin.nemunai.re
|
||||
<head><title>Index of /</title></head>
|
||||
|
||||
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 différents 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>Connexion - Miniflux</title>
|
||||
|
||||
42sh$ curl http://matrix.adlin.p0m.fr/
|
||||
<title>Matrix</title>
|
||||
|
||||
42sh$ curl http://www.adlin.p0m.fr/
|
||||
<title>Ma Vitrine</title>
|
||||
```
|
||||
</div>
|
||||
|
||||
Notez que ce n'est pas le rôle du routeur/pare-feu de faire
|
||||
reverse-proxy, vous devriez utiliser le serveur web de votre vitrine
|
||||
pour gérer les autres domaines.
|
||||
|
||||
|
||||
Connexions sécurisées
|
||||
---------------------
|
||||
|
||||
Maintenant que vos services écoutent en HTTP, il est temps de leur
|
||||
ajouter un certificat, afin que toutes les connexions soient
|
||||
sécurisées.
|
||||
|
||||
Plusieurs solutions s'offrent à vous dans ce genre de situation :
|
||||
|
||||
- laisser le reverse-proxy établir les connexions TLS (en envoyant
|
||||
notamment le certificat), puis transmettre les paquets reçus et
|
||||
déchiffrés, sur le réseau interne en clair. On parle alors de
|
||||
Terminaison TLS.
|
||||
|
||||
- utiliser un proxy SNI pour acheminer vers la bonne machine interne,
|
||||
le trafic entrant, en le gardant chiffré jusqu'au
|
||||
bout. L'orientation se fait grâce à l'extension TLS SNI.
|
||||
|
||||
On préférera la première solution pour avoir un meilleur contrôle des
|
||||
machines directement exposées, mais il faut bien avoir conscience que
|
||||
cela peut créer un goulot d'étranglement.
|
||||
|
||||
La deuxième solution est plus adaptée lorsque l'on souhaite depuis le
|
||||
réseau interne, directement aux machines, sans passer par un
|
||||
reverse-proxy, ou lorsque le réseau externe est en IPv6.
|
||||
Dans ce cas, pour se passer de la terminaison TLS, chaque serveur doit
|
||||
avoir son propre certificat à disposition.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 105 KiB After Width: | Height: | Size: 108 KiB |
|
|
@ -3,20 +3,20 @@ title: Administration Linux avancée -- TP n^o^ 3
|
|||
subtitle:
|
||||
author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
|
||||
institute: EPITA
|
||||
date: Vendredi 29 mars 2019
|
||||
date: Lundi 30 mars 2020
|
||||
abstract: |
|
||||
Durant ce troisième TP, nous allons faire un peu plus de réseau !
|
||||
|
||||
\vspace{1em}
|
||||
|
||||
Tous les éléments de ce TP (exercices et projet) sont à rendre à
|
||||
<adlin@nemunai.re> au plus tard le dimanche 21 avril 2019 à 23
|
||||
<adlin@nemunai.re> au plus tard le dimanche 12 avril 2019 à 23
|
||||
h 42. Consultez la dernière section de chaque partie pour plus d'information
|
||||
sur les éléments à rendre.
|
||||
|
||||
En tant que personnes sensibilisées à la sécurité des échanges électroniques,
|
||||
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||
[me](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x842807A84573CC96)
|
||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re)
|
||||
faire signer votre clef et n'hésitez pas à [faire signer votre
|
||||
clef](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
|
|
|
|||
|
|
@ -8,21 +8,23 @@ Présentation du système d'information
|
|||
|
||||
Le système d'information que vous allez avoir à gérer aujourd'hui est de taille
|
||||
moyenne : vous aurez en votre possession un serveur DNS résolveur, un serveur
|
||||
DNS autoritaire, un serveur de base de données ainsi que deux serveurs web
|
||||
(servant respectivement TinyTinyRSS, ainsi que Matrix).
|
||||
DNS autoritaire, un serveur de base de données ainsi que plusieurs serveurs web
|
||||
(servant respectivement votre vitrine, [Miniflux](https://miniflux.app/), ainsi
|
||||
que [Matrix](https://matrix.org/)).
|
||||
|
||||
Vous êtes l'administrateur réseau de l'entreprise et l'on vous demande de
|
||||
connecter tous ces services **correctement**.
|
||||
|
||||
L'image ISO que vous avez récupérée met à votre disposition tout ce système
|
||||
d'information, déjà configuré pour sa partie logicielle, il ne reste plus qu'à
|
||||
éditer la configuration du routeur.
|
||||
d'information, déjà en partie configuré pour sa partie logicielle, il ne reste
|
||||
plus qu'à éditer la configuration du routeur.
|
||||
|
||||
|
||||
|
||||
Attention, contrairement au précédent TP, tout se fait en direct, il n'y a
|
||||
aucune sauvegarde effectuée : à chaque redémarrage de la machine virtuelle,
|
||||
vous retomberez dans l'état initial.
|
||||
vous retomberez dans l'état initial : seuls quelques éléments comme le token de
|
||||
votre tunnel et le contenu de la base de données.
|
||||
|
||||
Accéder à la machine virtuelle
|
||||
------------------------------
|
||||
|
|
@ -31,16 +33,18 @@ Une fois la machine virtuelle démarrée, vous devriez voir apparaître l'IP qu'
|
|||
obtenue la machine sur votre réseau :
|
||||
|
||||
```
|
||||
You didn't define your token to connect the network. Please run here `join-p0m` and then reboot.
|
||||
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
|
||||
link/ether 42:2c:63:f1:5a:49 brd ff:ff:ff:ff:ff:ff
|
||||
inet 10.42.23.211/24 brd 10.42.23.255 scope global eth0
|
||||
valid_lft forever preferred_lft forever
|
||||
inet6 fe80::4534:6558:22cf:f2cd/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
nsenter: cannot open /run/netns/wks1: No such file or directory
|
||||
Attachez une seconde carte ethernet à la VM pour pouvoir vous connecter à un poste de travail.
|
||||
```
|
||||
|
||||
Cette IP est l'IP externe de votre routeur, qu'il a obtenu par DHCP.
|
||||
Cette IP est l'IP attribuée à votre routeur par votre hyperviseur, obtenue par
|
||||
DHCP.
|
||||
|
||||
Une ligne de commande est disponible au sein de la machine virtuelle à des fins
|
||||
de débogage, si nécessaire. Vous ne devriez normalement pas avoir à interagir
|
||||
|
|
@ -54,12 +58,24 @@ station de travail.
|
|||
### Tunnel Maatma
|
||||
|
||||
Pour retrouver votre tunnel sur Internet, vous devez, dans la console de la
|
||||
machine virtuelle, écrire votre token dans le fichier
|
||||
`/var/lib/adlin/wireguard/adlin.token` :
|
||||
machine virtuelle, utiliser la commande `join-p0m`.
|
||||
|
||||
Vous pouvez aussi écrire directement dans le fichier persistant :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
echo M0nT0k3n > /var/lib/adlin/wireguard/adlin.token
|
||||
```
|
||||
</div>
|
||||
|
||||
### Connexions SSH
|
||||
|
||||
Vous pouvez vous connecter en utilisant le compte `root` et le mot de passe
|
||||
`adlin2021`.
|
||||
|
||||
Notez que vous n'avez pas accès à la machine hébergeant la base de données, ni
|
||||
à celle du résolveur DNS.
|
||||
|
||||
|
||||
Objectif du TP
|
||||
--------------
|
||||
|
|
@ -72,4 +88,4 @@ noms local (les serveurs ayant déjà été configurés ainsi, il faudra simplem
|
|||
s'assurer que ce soit également le cas des stations de travail).
|
||||
|
||||
Étant donné le caractère éphémère de vos actions, la réalisation d'un
|
||||
*Playbook* Ansible semble plutôt adapté !
|
||||
*Playbook* Ansible semble plutôt adaptée !
|
||||
|
|
|
|||
|
|
@ -3,6 +3,20 @@
|
|||
Stations de travail
|
||||
===================
|
||||
|
||||
Plusieurs stations de travail sont simulées au sein de votre machine
|
||||
virtuelle. Celles-ci vont régulièrement faire des requêtes DHCP afin d'obtenir
|
||||
une IP.
|
||||
|
||||
Pour vous simplifier les opérations de débug, vous pouvez ajouter une carte
|
||||
ethernet à la machine virtuelle afin d'avoir accès en SSH à l'un des
|
||||
postes. L'IP sera alors indiquée sur l'écran de la VM, au démarrage : il s'agit
|
||||
de l'interface `eth1`.
|
||||
|
||||
Vous pouvez également ajouter une troisième carte réseau pour la brancher à
|
||||
d'autres machines virtuelle de hyperviseur, en passant par un pont. Toutes vos
|
||||
VM reliées à ce pont bénéficieront alors du réseau des postes de travail de
|
||||
votre *entreprise*.
|
||||
|
||||
DHCP
|
||||
----
|
||||
|
||||
|
|
|
|||
Reference in New Issue