Dans le scénario défini dans la Section 2, « Topologie Hub and Spoke - Protocole PPPoE », un routeur de site d'extrémité ou Spoke ne peut accéder aux autres réseaux que via le routeur Hub. Son interface WAN joue donc le rôle de route par défaut pour le réseau local des hôtes hébergés sur un site distant.
Les routeurs Spoke utilisent un démon pppd dans le VLAN Data (de couleur orange sur la représentation graphique de la topologie) pour établir une session PPP avec le routeur Hub.
Avant d'aborder les questions ci-dessous, assurez-vous que les éléments de configuration suivants sont en place.
Attribuez un nom d'hôte explicite sur chaque routeur Spoke.
sudo hostnamectl hostname spoke1
sudo hostnamectl hostname spoke2
Configurez et activez le routage au niveau système.
Les paquets ppp doivent être installés sur chaque routeur Spoke via l'accès réseau temporaire. Éditez le fichier /etc/netplan/spokeX.yaml et ouvrez l'accès Internet via le VLAN temporaire si nécessaire.
Installez le paquet ppp.
sudo apt -y install ppp
Éditez le fichier /etc/ppp/chap-secrets et ajoutez les authentifiants pour l'établissement de la session PPP.
Voici un exemple d'entrée ajoutée pour chacun des deux sites distants.
# Secrets for authentication using CHAP
# client server secret IP addresses
"spoke_site1" * "0r4ng3_1" *
# Secrets for authentication using CHAP
# client server secret IP addresses
"spoke_site2" * "0r4ng3_2" *
Créez un fichier /etc/ppp/peers/pppoe-provider de définition du profil de session PPP sur chaque routeur Spoke.
Avertissement
Le nom d'utilisateur doit correspondre à l'entrée du fichier /etc/ppp/chap-secrets !
Le numéro de VLAN de la sous-interface doit désigner le bon côté du triangle de la topologie !
Voici un exemple de création de profil de connexion PPP :
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_siteX
# 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ée pour l'établissement de la session PPP
enp0s1.VVV
# 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'information 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
Créez et activez un service systemd sur chaque routeur Spoke pour ouvrir les connexions PPP automatiquement.
Avertissement
Le numéro de VLAN de la sous-interface doit désigner le bon côté du triangle de la topologie !
N'oubliez pas de désactiver l'accès réseau temporaire une fois la session PPP établie. Assurez-vous que c'est bien cette session qui sert de route par défaut pour accéder à tous les autres réseaux.
Éditez à nouveau le fichier /etc/netplan/spokeX.yaml et appliquez les modifications faites.
Voici un exemple de test lancé sur le second routeur Spoke de la maquette.
ip route get 9.9.9.9
9.9.9.9 dev ppp0 src 10.44.3.2 uid 1000
cache
Éditez le fichier /etc/systemd/resolved.conf sur chaque routeur Spoke pour affecter directement l'adresse de résolution DNS.
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.
N'oubliez pas de relancer le service pour prendre en compte les modifications du fichier.
sudo systemctl restart systemd-resolved
À ce stade de la configuration, les sessions PPP des deux routeurs Spoke sont en place et on peut analyser les messages présents dans les journaux système et identifier les traitements réalisés par les différentes fonctions des protocoles.
Q97.
Comment vérifier que le protocole PPPoE a bien permis d'identifier les extrémités en communication dans le réseau de diffusion (VLAN orange) avant de lancer l'ouverture de session PPP ?
Recherchez les options de la commande journalctl pour afficher les messages utiles de la journalisation système.
Dans le but de minimiser le nombre de lignes affichées, on peut combiner les commandes journalctl et grep. Les possibilités sont très diverses. Voici un exemple côté routeur Spoke.
L'extrait ci-dessus montre la séquence spécifique au protocole PPPoE :
Découverte avec émission de la trame PADI depuis le routeur Spoke.
Offre avec réception de la trame PADO depuis le routeur Hub.
Requête avec émission de la trame PADR depuis le routeur Spoke pour accepter l'offre.
Ouverture de session avec la trame PADS quand les deux extrémités de la liaison point à point sont en accord.
Côté routeur Hub, les journaux de chaque unité de service pppoe-serverX permettent de vérifier que les adresses MAC correspondent bien au bon routeur Spoke pour chaque côté du triangle de la topologie.
Voici deux exemples pour la maquette de rédaction de ce document.
journalctl -u pppoe-server1.service -n 100 | grep created
hub pppoe-server[621]: Session 1 created for client b8:ad:ca:fe:00:06 (10.44.1.2) on enp0s1.441 using Service-Name ''
journalctl -u pppoe-server2.service -n 100 | grep created
hub pppoe-server[673]: Session 1 created for client b8:ad:ca:fe:00:07 (10.44.3.2) on enp0s1.443 using Service-Name ''
Q98.
Quels sont les messages des journaux système qui montrent que la session PPP a bien été établie ?
Après avoir consulté la page Point-to-Point Protocol repérez les messages relatifs aux deux sous-couches LCP et NCP du protocole PPP.
Les messages PPP sont présents sur tous les routeurs de la topologie. Voici deux exemples prélevés côté Hub et côté Spoke.
Extrait des négociations de paramètres et de l'authentification dans la sous-couche LCP côté Hub.
Dans l'exemple ci-dessus, on repère immédiatement le dernier message qui conclut la phase d'authentification du routeur Spoke auprès du routeur Hub avec succès.
Plus haut, on repère aussi l'identité utilisée pour cette authentification : spoke_site2.
Extrait des mêmes négociations de paramètres et de l'authentification dans la sous-couche LCP côté Spoke.
Relevez le statut des scripts d'application des routes par défaut vers la liaison PPP pour les routeurs Spoke. En l'état actuel de la configuration, l'attribution de la route par défaut IPv6 ne se fait pas. Il faudra donc corriger ce point dans la partie suivante.
Au terme de cette partie, chaque routeur Spoke a établi sa session PPP avec le routeur Hub après la découverte PPPoE et l'authentification EAP. Ils ont obtenu leurs adresses via la sous-couche NCP et utilisent ce lien comme route par défaut IPv4. L'analyse des journaux révèle cependant l'absence de route par défaut IPv6, problème qui devra être corrigé dans la partie suivante.
![[Avertissement]](/images/warning.png)
![[Attention]](/images/caution.png)