4. Configurer les routeurs Spoke

Les quatre routeurs Spoke de la topologie jouent toujours le rôle de routeur d'extrémité.

Pour les manipulations de configuration de ce rôle, on s'appuie sur le support de travaux pratiques : Routage inter-VLAN et protocole PPPoE.

Dans cette section, on s'intéresse aux rôles et fonctionnalités suivantes :

  • Gérer les sessions PPP avec les routeurs Hub

  • Valider les communications entre routeurs Spoke

4.1. Configurer les clients PPP

Les tâches à réaliser sont :

  • Activer le routage

  • Configurer le protocole PPP

Pour l'activation du routage, on retrouve les mêmes opérations que sur les routeurs Hub.

Q25.

Comment activer le routage dans le sous-système réseau du noyau Linux ?

Utiliser la commande sysctl pour effectuer des recherches et identifier les paramètres utiles. Par exemple :

sudo sysctl -a -r ".*forward.*"

Il est dorénavant recommandé de créer un fichier de configuration spécifique par fonction. C'est la raison pour laquelle on crée un nouveau fichier /etc/sysctl.d/10-routing.conf.

Attention ! Il ne faut pas oublier d'appliquer les nouvelles valeurs des paramètres de configuration.

cat << EOF | sudo tee /etc/sysctl.d/10-routing.conf
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv4.conf.all.log_martians=1
EOF

Voici un exemple des résultats obtenus après application des nouveaux paramètres.

sudo sysctl --system

La configuration des “clients” PPP diffère de celle des routeurs Hub.

Q26.

Quel paquet fournit le démon de gestion des sessions du protocole PPP sur le routeur Spoke ?

Rechercher dans le catalogue des paquets, la référence ppp.

apt search ^ppp
ppp/testing 2.5.0-1+2 amd64
  protocole point à point (PPP) - démon

ppp-dev/testing 2.5.0-1+2 all
  protocole point à point (PPP) – fichiers de développement

ppp-gatekeeper/testing 0.1.0-201406111015-1.1 all
  PPP manager for handling balanced, redundant and failover links

pppoe/testing 4.0-1 amd64
  Pilote PPP sur Ethernet

pppoeconf/testing 1.21+nmu3 all
  configures PPPoE/ADSL connections

wmppp.app/testing 1.3.2-2 amd64
  contrôle de connexion et surveillance de la charge réseau avec aspect NeXTStep

Le résultat de la commande apt show ppp montre que c'est bien ce paquet qui répond au besoin.

sudo apt -y install ppp

Q27.

Comment utiliser l'encapsulation des trames PPP dans Ethernet à partir du démon pppd fourni avec le paquet ppp ?

Rechercher dans le répertoire de documentation du paquet ppp.

Dans le répertoire /usr/share/doc/ppp/, on trouve le fichier README.pppoe qui indique que l'appel au module rp-pppoe.so permet d'encapsuler des trames PPP sur un réseau local Ethernet.

Toujours à partir du même répertoire, on trouve dans la liste des fichiers d'exemples de configuration un modèle adapté à notre contexte : peers-pppoe.

Q28.

Dans quel fichier sont stockés les paramètres d'identité et d'authentification utilisés par le protocole CHAP ?

Consulter les pages de manuels du démon pppd à la section AUTHENTICATION.

C'est le fichier /etc/ppp/chap-secrets qui contient les couples login/password utilisés lors de l'authentification.

Voici un exemple du contenu de ce fichier. Le nom du client ainsi que son mot de passe secret doivent être identiques à chaque extrémité de la session PPP.

# Secrets for authentication using CHAP
# client        server  secret                  IP addresses
"spoke_site0"   *               "5p0k3"                 *

Q29.

Quelles sont les options de configuration du démon pppd à placer dans le fichier /etc/ppp/peers/pppoe-provider pour assurer l'établissement de la session PPP entre les routeurs ?

Utiliser le fichier exemple PPPoE fourni avec la documentation du paquet ppp.

Voici comment créer un fichier /etc/ppp/peers/pppoe-provider avec les options correspondant au contexte de la maquette du routeur vert.

cat << 'EOF' | sudo tee /etc/ppp/peers/pppoe-provider
# Le nom d'utilisateur désigne l'entrée du fichier /etc/ppp/chap-secrets
user spoke_site0

# Chargement du module PPPoE avec les détails dans la journalisation
plugin rp-pppoe.so rp_pppoe_ac BRAS rp_pppoe_verbose 1

# Interface (VLAN) utilisé pour l'établissement de la session PPP
enp0s1.441

# Les adresses sont attribuées par le "serveur" PPPoE
noipdefault
# L'adresse de résolution DNS est aussi fournie par le serveur PPPoE
usepeerdns
# La session PPP devient la route par défaut du routeur Spoke
defaultroute

# Demande de réouverture de session automatique en cas de rupture
persist

# Le routeur Spoke n'exige pas que le routeur Hub s'authentifie
noauth

# Messages d'informations détaillés dans la journalisation
debug

# Utilisation du protocole IPv6
+ipv6

# Options préconisées par la documentation
noaccomp
default-asyncmap
nodeflate
nopcomp
novj
novjccomp
lcp-echo-interval 10
EOF

Q30.

Comment lancer le démon pppd pour qu'il prenne en compte les paramètres définis dans le fichier complété à la question précédente ?

Consulter les pages de manuels du démon pppd.

C'est l'outil pon qui permet de désigner le fichier de configuration à utiliser. Voici une copie d'écran du lancement du démon pppd.

sudo pon pppoe-provider

Cette commande individuelle est à utiliser pour faire un tout premier test. Pour rendre la configuration persistante au redémarrage nous avons besoin de créer un service systemd. Il ne faut donc pas oublier d'arrêter le processus avant de passer à la question suivante. Le paquet fournit un outil dédié : poff.

sudo poff -a pppoe-provider

Q31.

Quels sont les noms des deux sous-couches du protocole PPP qui apparaissent dans les journaux systèmes ? Quels sont les rôles respectifs de ces deux sous-couches ?

Consulter la page Point-to-Point Protocol.

La consultation des journaux système lors du dialogue PPP fait apparaître tous les détails. Voir les exemples de traces à l'adresse : Traces d'une ouverture de session PPPoE.

Q32.

Quels sont les en-têtes du dialogue qui identifient les requêtes (émises|reçues), les rejets et les acquittements ?

Consulter les journaux système contenant les traces d'une connexion PPP.

La copie d'écran donnée ci-dessus fait apparaître les directives Conf* pour chaque paramètre négocié.

  • ConfReq indique une requête.

  • ConfAck indique un acquittement.

  • ConfNak indique un rejet.

Q33.

Comment assurer une ouverture automatique de la session PPP à chaque réinitialisation système ?

Consulter la page systemd Services et rechercher la procédure à suivre pour ajouter un service au lancement du système.

On commence par la création du fichier de service appelé : /etc/systemd/system/ppp.service qui contient les appels aux outils pon et poff.

Voici l'instruction de création du fichier de service.

cat << EOF | sudo tee /etc/systemd/system/ppp.service
[Unit]
Description=PPPoE Client Connection
After=network.target
Wants=network.target
BindsTo=sys-subsystem-net-devices-enp0s1.441.device
After=sys-subsystem-net-devices-enp0s1.441.device

[Service]
Type=forking
ExecStart=/usr/bin/pon pppoe-provider
ExecStop=/usr/bin/poff pppoe-provider
Restart=on-failure
RestartSec=20

[Install]
WantedBy=multi-user.target
EOF

Q34.

Comment activer le nouveau service et contrôler son état après lancement ?

Consulter la page systemd Services et rechercher la procédure à suivre pour activer et lancer un service.

On commence par la relecture de la liste des services disponibles par le gestionnaire systemd.

sudo systemctl daemon-reload

On active le nouveau service.

sudo systemctl enable ppp.service

On lance ce nouveau service.

sudo systemctl start ppp.service

On vérifie que l'opération s'est déroulée correctement.

systemctl status ppp.service
● ppp.service - PPPoE Client Connection
     Loaded: loaded (/etc/systemd/system/ppp.service; enabled; preset: enabled)
     Active: active (running) since Sun 2024-09-22 08:21:32 CEST; 13min ago
 Invocation: 69386a40f7574821b3986ed6c6c242f7
   Main PID: 496 (pppd)
      Tasks: 1 (limit: 1086)
     Memory: 2.8M (peak: 4.9M)
        CPU: 56ms
     CGroup: /system.slice/ppp.service
             └─496 /usr/sbin/pppd call pppoe-provider

sept. 22 08:21:37 spoke pppd[496]: rcvd [IPCP ConfAck id=0x2 <addr 10.4.41.2> <ms-dns1 172.16.0.2> <ms-dns2 172.16.0.2>]
sept. 22 08:21:37 spoke pppd[496]: Script /etc/ppp/ip-pre-up started (pid 510)
sept. 22 08:21:37 spoke pppd[496]: Script /etc/ppp/ip-pre-up finished (pid 510), status = 0x0
sept. 22 08:21:37 spoke pppd[496]: local  IP address 10.4.41.2
sept. 22 08:21:37 spoke pppd[496]: remote IP address 10.4.41.1
sept. 22 08:21:37 spoke pppd[496]: primary   DNS address 172.16.0.2
sept. 22 08:21:37 spoke pppd[496]: secondary DNS address 172.16.0.2
sept. 22 08:21:37 spoke pppd[496]: Script /etc/ppp/ip-up started (pid 514)
sept. 22 08:21:37 spoke pppd[496]: Script /etc/ppp/ipv6-up finished (pid 509), status = 0x0
sept. 22 08:21:37 spoke pppd[496]: Script /etc/ppp/ip-up finished (pid 514), status = 0x0

Q35.

Comment utiliser la session PPP (le VLAN orange) comme lien unique de raccordement réseau du routeur Spoke ?

Maintenant que le fonctionnement de la session PPP est validé, nous n'avons plus besoin du raccordement temporaire sur le routeur Spoke. Il faut donc commenter les entrées du fichier /etc/netplan/enp0s1.yaml qui ne sont plus utiles et attribuer l'adresse de résolution DNS de secours.

Une fois ces opérations effectuées, on peut redémarre le routeur Spoke pour se placer en situation de raccordement distant.

Pour commencer, on commente les entrées inutile du fichier /etc/netplan/enp0s1.yaml.

cat /etc/netplan/enp0s1.yaml
network:
  version: 2
  ethernets:
    enp0s1:
      dhcp4: false
      dhcp6: false
      accept-ra: false
#     nameservers:
#       addresses:
#          - 172.16.0.2
#          - 2001:678:3fc:3::2

  vlans:
    enp0s1.440: # VLAN violet
      id: 440
      link: enp0s1
      addresses:
        - fe80:1b8::2/64
    enp0s1.441: # VLAN orange
      id: 441
      link: enp0s1
      addresses: []
#   enp0s1.52: # VLAN accès temporaire
#     id: 52
#     link: enp0s1
#     dhcp4: true
#     dhcp6: false
#     accept-ra: true

On peut appliquer directement les modifications à l'aide de la commande netplan.

sudo netplan apply
sudo netplan status
[Attention] Attention

L'affectation de l'adresse IPv4 ou IPv6 de résolution DNS pose problème. En effet, si le démon pppd propose bien deux adresses via l'option usepeerdns, ces propositions ne sont pas prises en charge par le service systemd-resolved.

On contourne cette difficulté en affectant une adresse IPv4 directement au service systemd-resolved.

On édite le fichier /etc/systemd/resolved.conf pour affecter directement l'adresse de résolution DNS. Voici une copie des lignes utiles du fichier modifié. Toutes les autres lignes sont commentées.

grep -Ev '(^#|^$)'  /etc/systemd/resolved.conf
[Resolve]
DNS=172.16.0.2

Il ne faut pas oublier de relancer le service pour prendre en compte les modifications du fichier.

sudo systemctl restart systemd-resolved

Le routeur Spoke est maintenant prêt à être redémarré pour utiliser le lien de raccordement distant comme seul canal d'accès aux autres réseaux.

sudo reboot

Pour visualiser les détails du fonctionnement du protocole point à point, voir la section « Traces d'une ouverture de session PPPoE » du document « Routage inter-VLAN et protocole PPPoE ».

4.2. Valider les communications

Après avoir vérifié que les quatre sessions PPP de la maquette sont actives, on peut lancer une série de tests ICMP suivant deux axes.

  1. Accéder à l'Internet depuis chaque routeur Spoke avec IPv4.

    L'accès via IPv6 n'est pas possible sachant qu'aucune adresse de type ULA ou GUA n'est présente sur les routeurs Spoke.

    etu@spoke4:~$ ping -qc2 9.9.9.9
    PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
    
    --- 9.9.9.9 ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1001ms
    rtt min/avg/max/mdev = 28.778/29.342/29.907/0.564 ms
  2. Accéder aux autres routeurs Spoke.

    Le script ci-dessous peut être exécuté sur n'importe quel routeur Spoke et permet de vérifier qu'aucun paquet n'est perdu.

    for addr in "10.47.2.2" "10.47.4.2" "10.47.6.2" "10.47.8.2"
    do
        ping -qc2 $addr
    done