Fix spelling and grammar mistakes across EN and FR content (chapter C)

This commit is contained in:
Djeex
2026-09-07 21:25:08 +02:00
parent de3498fa65
commit db30198450
30 changed files with 65 additions and 65 deletions
@@ -40,7 +40,7 @@ Si vous êtes en dual boot avec Windows, désactivez son *démarrage rapide* : i
Récupérez l'image **netinst** `amd64` sur [debian.org](https://www.debian.org/download.fr.html). Elle fait environ 700 Mo et récupère le reste des paquets sur le réseau pendant l'installation, ce qui est exactement ce qu'on veut sur un serveur branché en ethernet : vous obtenez des paquets à jour au lieu d'installer depuis un instantané vieux de plusieurs mois puis de tout mettre à jour derrière. Les images DVD complètes n'ont de sens que si la machine n'a pas de réseau pendant l'installation.
#### Créer une clée bootable avec Rufus
#### Créer une clé bootable avec Rufus
Sous Windows, utilisez [Rufus](https://rufus.ie/) (portable, aucune installation nécessaire). Branchez une clé USB de 2 Go ou plus, en gardant en tête qu'**elle sera entièrement effacée**, puis :
@@ -160,7 +160,7 @@ Toujours sur l'autre machine, générez une clé.
ssh-keygen -t ed25519
```
Appuyez sur :kbd{value="Enter"} pour accepter le chemin par défaut, et mettez une passphrase (elle protège le fichier de clé lui-même, votre système la retiendra après le premier déverrouillage). Il s'agit ensuite de transmettre la clée publique à votre serveur. A noter que Windows n'a pas de `ssh-copy-id`, nous pousserons donc la clé manuellement dans ce cas :
Appuyez sur :kbd{value="Enter"} pour accepter le chemin par défaut, et mettez une passphrase (elle protège le fichier de clé lui-même, votre système la retiendra après le premier déverrouillage). Il s'agit ensuite de transmettre la clé publique à votre serveur. À noter que Windows n'a pas de `ssh-copy-id`, nous pousserons donc la clé manuellement dans ce cas :
::code-group
```bash [macOS]
+4 -4
View File
@@ -19,11 +19,11 @@ Il existe aussi des clients Windows, macOS, iOS et Android.
Le principe est le suivant :
- Sur internet, n'importe qui peut contacter n'importe quel box internet et donc essayer de contacter n'importe quel serveur exposé.
- Votre serveur est sur votre réseau local. Il est accessible depuis le réseau local mais pas depuis internet, mis à part les services exposés (comme nous l'avons fait avec Dockge). Pour accéder aux ressources non exposées, vous devez être connecté sur le même réseau que votre serveur et donc être chez vous. De plus, vous devez laisser ouvert les ports utilisés par vos services à travers le pare feu de votre serveur.
- Votre serveur est sur votre réseau local. Il est accessible depuis le réseau local mais pas depuis internet, mis à part les services exposés (comme nous l'avons fait avec Dockge). Pour accéder aux ressources non exposées, vous devez être connecté sur le même réseau que votre serveur et donc être chez vous. De plus, vous devez laisser ouverts les ports utilisés par vos services à travers le pare-feu de votre serveur.
- Nous souhaitons ici au contraire, depuis n'importe où, pouvoir accéder de manière sécurisée aux services non exposés sur internet du serveur, comme la console SSH qui permet de se connecter à la machine par exemple.
- Nous souhaitons aussi accéder aux services d'autres serveurs, et par exemple relier de manière sécurisée deux instances de Dockge pour tout contrôler depuis la même interface.
Pour cela nous allons créer un **réseau privé virtuel**, ou VPN, c'est-à-dire un tunnel sécurisé auquel personne n'a accès à part les machines que vous relierez entre elles. Elles feront partie d'un nouveau réseau et pourront dialoguer entre elle comme dans un réseau local.
Pour cela nous allons créer un **réseau privé virtuel**, ou VPN, c'est-à-dire un tunnel sécurisé auquel personne n'a accès à part les machines que vous relierez entre elles. Elles feront partie d'un nouveau réseau et pourront dialoguer entre elles comme dans un réseau local.
D'autre part, vous pourrez ajouter votre téléphone, un ordinateur portable ou n'importe quel appareil au réseau pour pouvoir utiliser vos ressources depuis vos appareils quotidiens, où que vous soyez.
@@ -34,9 +34,9 @@ Dans cette illustration, la machine 1 est sur deux réseaux :
- son réseau local (tous les appareils liés à la box, avec une adresse IP du type `192.168.x.x ` donc ici la machine 1 et la machine 2)
- le réseau du VPN (tous les appareils reliés au VPN, avec une seconde adresse IP du type `10.8.x.x` donc ici la machine 1 et 4)
On peut aussi faire en sorte que les machines reliées au réseau virtuel partagent les accès à leur réseau local. Ici nous ne le ferons pas, pour des raisons de sécurité, et de complexité en terme de sous-réseau (si les deux machines distantes ont des machines locales qui utilisent la même adresse IP locale, par exemple `192.168.1.1`, cela posera des conflits).
On peut aussi faire en sorte que les machines reliées au réseau virtuel partagent les accès à leur réseau local. Ici nous ne le ferons pas, pour des raisons de sécurité, et de complexité en termes de sous-réseau (si les deux machines distantes ont des machines locales qui utilisent la même adresse IP locale, par exemple `192.168.1.1`, cela posera des conflits).
Ainsi, sur le réseau virtuel, seules les machines directement reliées pourront dialoguer entre elle depuis ce réseau. Elles ne pourront pas dialoguer avec une machine situées sur un autre réseau local et non reliée au VPN.
Ainsi, sur le réseau virtuel, seules les machines directement reliées pourront dialoguer entre elles depuis ce réseau. Elles ne pourront pas dialoguer avec une machine située sur un autre réseau local et non reliée au VPN.
## Côté serveur
::note{icon=""}
@@ -8,7 +8,7 @@ description: Utiliser les tunnels Cloudflare et Zero Trust pour exposer des serv
![cloudfare_tunnels](/img/serveex/cloudflared.svg)
## Introduction
L'architecture _Zero Trust_ est la pratique consistant à concevoir des systèmes fondés sur le principe de __« ne jamais faire confiance__, __toujours vérifier »__, par opposition au principe traditionnel de __« confiance, mais vérifier »__. Ce concept est devenu très populaires récemment, à la suite des attaques toujours plus nombreuses concernant les données des utilisateurs. C'est un concept très large, nous nous concentrerons sur lapplication du _Zero Trust_ aux services Web que nous hébergeons.
L'architecture _Zero Trust_ est la pratique consistant à concevoir des systèmes fondés sur le principe de __« ne jamais faire confiance__, __toujours vérifier »__, par opposition au principe traditionnel de __« confiance, mais vérifier »__. Ce concept est devenu très populaire récemment, à la suite des attaques toujours plus nombreuses concernant les données des utilisateurs. C'est un concept très large, nous nous concentrerons sur lapplication du _Zero Trust_ aux services Web que nous hébergeons.
Les _tunnels Cloudflare_ offrent un moyen simple d'arriver au _Zero Trust_, en s'appuyant sur [SWAG](/serveex/core/swag) et [Authentik](/serveex/advanced/authentik).
+1 -1
View File
@@ -124,7 +124,7 @@ Si vos médias sont stockés sur un disque réseau (un NAS ou un disque dur exte
## Transcodage matériel
Jellyfin réencode la vidéo à la volée dès qu'un client ne peut pas lire un fichier tel quel : la résolution de l'écran de l'appareil est inférieure à celle de la source, sa connexion réseau est trop lente pour le débit du fichier, ou il ne prend pas en charge le codec, le format HDR ou le type de sous-titres du fichier. C'est ce qu'on appelle le **transcodage**. Lorsque le transcodage est logiciel et éxecuté par le CPU, cela prend énormément de ressources et cela peut saturer un serveur modeste avec seulement un ou deux flux simultanés. Le **transcodage matériel** délègue ce travail au GPU intégré à votre processeur (Intel QuickSync, sur la plupart du matériel de homelab), qui s'en occupe bien plus vite et laisse le CPU libre pour tout le reste.
Jellyfin réencode la vidéo à la volée dès qu'un client ne peut pas lire un fichier tel quel : la résolution de l'écran de l'appareil est inférieure à celle de la source, sa connexion réseau est trop lente pour le débit du fichier, ou il ne prend pas en charge le codec, le format HDR ou le type de sous-titres du fichier. C'est ce qu'on appelle le **transcodage**. Lorsque le transcodage est logiciel et exécuté par le CPU, cela prend énormément de ressources et cela peut saturer un serveur modeste avec seulement un ou deux flux simultanés. Le **transcodage matériel** délègue ce travail au GPU intégré à votre processeur (Intel QuickSync, sur la plupart du matériel de homelab), qui s'en occupe bien plus vite et laisse le CPU libre pour tout le reste.
Le **tone mapping** est une fonction liée mais distincte : convertir une vidéo HDR (qui a besoin d'un écran HDR compatible pour rendre correctement) en SDR pour qu'elle s'affiche correctement sur un écran, une TV ou un client qui ne gère pas le HDR, au lieu de paraître délavée ou trop sombre.
+2 -2
View File
@@ -25,7 +25,7 @@ AdGuard lui, va s'intercaler entre le serveur de nom et votre appareil. Si vous
- Si le domaine n'est pas dans une blocklist, il contactera des serveurs de noms génériques (dit upstreams) et répondra vers vos appareils avec l'adresse IP recherchée.
- Si le domaine est dans une blocklist, il ne contactera pas les DNS upstream et ne répondra pas à vos appareils. Le contenu affilié à cette requête ne s'affichera pas.
C'est ainsi que les pubs et domaines malveillants sont bloqués : leurs domaines sont présents dans la blocklist, le reste de la page lui charge correctement.
C'est ainsi que les pubs et domaines malveillants sont bloqués : leurs domaines sont présents dans la blocklist, le reste de la page se charge correctement.
![Schéma d'AdGuard filtrant une requête DNS selon une liste de blocage](/img/serveex/adguard.svg)
@@ -360,7 +360,7 @@ Le chiffrement est essentiel si vous souhaitez garder privées les requêtes que
Afin de configurer le chiffrement :
- Allez dans _paramètre_ puis dans _chiffrement_.
- Allez dans _paramètres_ puis dans _chiffrement_.
- Paramétrez comme suit
![Écran des réglages de chiffrement d'AdGuard Home](/img/serveex/adguard-chiffrement.png)