3. Routeurs Spoke

Dans le scénario défini dans la Section 1, « Topologie Hub & 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é sur un site distant.

Cette section, comme la précédente, reprend les éléments du support Routage inter-VLAN et protocole PPPoE en dédoublant les routeurs d'extrémité.

Les routeurs Spoke utilisent un démon pppd dans le VLAN Data (Orange) pour établir une session PPP avec le routeur Hub.

Avant d'aborder les questions ci-dessous, il faut s'assurer que :

  • Le nom d'hôte est correctement attribué sur chaque routeur Spoke.

    • sudo hostnamectl hostname spoke_1
    • sudo hostnamectl hostname spoke_2
  • Le routage est configuré et activé.

    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
    sudo sysctl --system
  • Les paquets ppp sont installés sur chaque routeur Spoke via l'accès réseau temporaire. Il faut donc éditer et appliquer les modifications faites dans le fichier /etc/netplan/enp0s1.yaml.

    sudo apt -y install ppp
  • Le fichier /etc/ppp/chap-secrets contenant les authentifiants pour l'établissement de la session PPP est complété.

    • # 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"     *
  • Le fichier /etc/ppp/peers/pppoe-provider de définition du profil de session PPP est créé.

    [Avertissement] 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 !

    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é 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'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
  • Les unités systemd sont créées et activées sur chaque routeur Spoke.

    [Avertissement] Avertissement

    Le numéro de VLAN de la sous-interface doit désigner le bon côté du triangle de la topologie !

    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.VVV.device
    After=sys-subsystem-net-devices-enp0s1.VVV.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

    On active les nouvelles unités de service avec les instructions suivantes.

    sudo systemctl daemon-reload
    sudo systemctl enable --now ppp.service
  • Une fois la session PPP établie, n'oubliez pas de désactiver l'accès réseau temporaire et s'assurer que c'est bien cette session qui sert de route par défaut pour accéder à tous les autres réseaux.

    Il faut donc éditer à nouveau et appliquer les modifications faites dans le fichier /etc/netplan/enp0s1.yaml.

    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
  • On doit éditer le fichier /etc/systemd/resolved.conf sur chaque routeur Spoke pour affecter directement l'adresse de résolution DNS.

    [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.

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

    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 ?

Rechercher les options de la commande journalctl pour faire 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.

journalctl --grep pppoe | grep -i pad
spoke2 pppd[489]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
spoke2 pppd[489]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 44
spoke2 pppd[489]: Send PPPOE Discovery V1T1 PADR session 0x0 length 36
spoke2 pppd[489]: Recv PPPOE Discovery V1T1 PADS session 0x1 length 12

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érer 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.

    journalctl -u pppoe-server2.service -n 100  | grep -E '(LCP|EAP)'
    hub pppd[673]: sent [LCP ConfReq id=0x1 <mru 1492> <auth eap> <magic 0xef9c0d86>]
    hub pppd[673]: rcvd [LCP ConfAck id=0x1 <mru 1492> <auth eap> <magic 0xef9c0d86>]
    hub pppd[673]: rcvd [LCP ConfReq id=0x1 <mru 1492> <magic 0x8b9f1855>]
    hub pppd[673]: sent [LCP ConfAck id=0x1 <mru 1492> <magic 0x8b9f1855>]
    hub pppd[673]: sent [LCP EchoReq id=0x0 magic=0xef9c0d86]
    hub pppd[673]: sent [EAP Request id=0x95 Identity <Message "Name">]
    hub pppd[673]: rcvd [LCP EchoReq id=0x0 magic=0x8b9f1855]
    hub pppd[673]: sent [LCP EchoRep id=0x0 magic=0xef9c0d86]
    hub pppd[673]: rcvd [LCP EchoRep id=0x0 magic=0x8b9f1855]
    hub pppd[673]: rcvd [EAP Response id=0x95 Identity <Name "spoke_site2">]
    hub pppd[673]: EAP: unauthenticated peer name "spoke_site2"
    hub pppd[673]: EAP id=0x95 'Identify' -> 'MD5Chall'
    hub pppd[673]: sent [EAP Request id=0x96 MD5-Challenge <Value 14 d4 e2 ec 00 a1 26 ca f8 98 c5 7e d6 f4 a7 ef d7> <Name "hub">]
    hub pppd[673]: rcvd [EAP Response id=0x96 MD5-Challenge <Value cd 5d 07 6a 5b 59 2b 1c ec f8 d6 7f 9b 40 44 63> <Name "spoke_site2">]
    hub pppd[673]: sent [EAP Success id=0x97]
    hub pppd[673]: EAP id=0x97 'MD5Chall' -> 'Open'

    Dans l'exemple ci-dessus, on repère immédiatement le dernier message qui conclue 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.

    journalctl -u ppp -n 100 | grep -E '(LCP|EAP)'
    spoke2 pppd[489]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x8b9f1855>]
    spoke2 pppd[489]: rcvd [LCP ConfReq id=0x1 <mru 1492> <auth eap> <magic 0xef9c0d86>]
    spoke2 pppd[489]: sent [LCP ConfAck id=0x1 <mru 1492> <auth eap> <magic 0xef9c0d86>]
    spoke2 pppd[489]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x8b9f1855>]
    spoke2 pppd[489]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0x8b9f1855>]
    spoke2 pppd[489]: sent [LCP EchoReq id=0x0 magic=0x8b9f1855]
    spoke2 pppd[489]: rcvd [LCP EchoReq id=0x0 magic=0xef9c0d86]
    spoke2 pppd[489]: sent [LCP EchoRep id=0x0 magic=0x8b9f1855]
    spoke2 pppd[489]: rcvd [EAP Request id=0x95 Identity <Message "Name">]
    spoke2 pppd[489]: EAP: Identity prompt "Name"
    spoke2 pppd[489]: sent [EAP Response id=0x95 Identity <Name "spoke_site2">]
    spoke2 pppd[489]: rcvd [LCP EchoRep id=0x0 magic=0xef9c0d86]
    spoke2 pppd[489]: rcvd [EAP Request id=0x96 MD5-Challenge <Value 14 d4 e2 ec 00 a1 26 ca f8 98 c5 7e d6 f4 a7 ef d7> <Name "hub">]
    spoke2 pppd[489]: sent [EAP Response id=0x96 MD5-Challenge <Value cd 5d 07 6a 5b 59 2b 1c ec f8 d6 7f 9b 40 44 63> <Name "spoke_site2">]
    spoke2 pppd[489]: rcvd [EAP Success id=0x97]
    spoke2 pppd[489]: EAP authentication succeeded

    Comme dans l'extrait précédent, on retrouve les traces de l'identité utilisée et du succès de l'authentification.

  • On reprend le même travail pour la sous-couche NCP dans laquelle on recherche l'attribution des adresses des liaisons point à point côté Hub.

    Dans les journaux, la lettre N est remplacée par IP pour le protocole IPv4 et IPV6 pour le protocole IPv6.

    journalctl -u pppoe-server1.service -n 100  | grep -E '(IP.*CP|CCP)'
    pppd[1055]: peer from calling number b8:ad:ca:fe:00:06 authorized
    hub pppd[1055]: sent [CCP ConfReq id=0x1 <bsd v1 15>]
    hub pppd[1055]: sent [IPCP ConfReq id=0x1 <addr 10.44.1.1>]
    hub pppd[1055]: sent [IPV6CP ConfReq id=0x1 <addr fe80::0421:e270:de27:332c>]
    hub pppd[1055]: EAP id=0xaa 'MD5Chall' -> 'Open'
    hub pppd[1055]: rcvd [IPCP ConfReq id=0x3 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
    hub pppd[1055]: sent [IPCP ConfNak id=0x3 <addr 10.44.1.2> <ms-dns1 172.16.0.2> <ms-dns2 172.16.0.2>]
    hub pppd[1055]: rcvd [IPV6CP ConfReq id=0x2 <addr fe80::79ea:402e:6158:8922>]
    hub pppd[1055]: sent [IPV6CP ConfAck id=0x2 <addr fe80::79ea:402e:6158:8922>]
    hub pppd[1055]: rcvd [CCP ConfReq id=0x2]
    hub pppd[1055]: sent [CCP ConfAck id=0x2]
    hub pppd[1055]: rcvd [CCP ConfRej id=0x1 <bsd v1 15>]
    hub pppd[1055]: sent [CCP ConfReq id=0x2]
    hub pppd[1055]: rcvd [IPCP ConfAck id=0x1 <addr 10.44.1.1>]
    hub pppd[1055]: rcvd [IPV6CP ConfAck id=0x1 <addr fe80::0421:e270:de27:332c>]
    hub pppd[1055]: local  LL address fe80::0421:e270:de27:332c
    hub pppd[1055]: remote LL address fe80::79ea:402e:6158:8922
    hub pppd[1055]: Script /etc/ppp/ipv6-up started (pid 1061)
    hub pppd[1055]: rcvd [IPCP ConfReq id=0x4 <addr 10.44.1.2> <ms-dns1 172.16.0.2> <ms-dns2 172.16.0.2>]
    hub pppd[1055]: sent [IPCP ConfAck id=0x4 <addr 10.44.1.2> <ms-dns1 172.16.0.2> <ms-dns2 172.16.0.2>]
    hub pppd[1055]: Script /etc/ppp/ip-pre-up started (pid 1062)
    hub pppd[1055]: Script /etc/ppp/ip-pre-up finished (pid 1062), status = 0x0
    hub pppd[1055]: local  IP address 10.44.1.1
    hub pppd[1055]: remote IP address 10.44.1.2
    hub pppd[1055]: Script /etc/ppp/ip-up started (pid 1066)
    hub pppd[1055]: Script /etc/ppp/ipv6-up finished (pid 1061), status = 0x0
    hub pppd[1055]: rcvd [CCP ConfAck id=0x2]
    hub pppd[1055]: Script /etc/ppp/ip-up finished (pid 1066), status = 0x0
  • On poursuit la même démarche côté routeurs Spoke.

    Le point important ici, c'est relever 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 ça dans la partie suivante.

    journalctl -u ppp.service -n 100  -f
    pppd[496]: EAP authentication succeeded
    spoke1 pppd[496]: peer from calling number B8:AD:CA:FE:00:05 authorized
    spoke1 pppd[496]: sent [IPCP ConfReq id=0x3 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
    spoke1 pppd[496]: sent [IPV6CP ConfReq id=0x2 <addr fe80::79ea:402e:6158:8922>]
    spoke1 pppd[496]: rcvd [CCP ConfReq id=0x1 <bsd v1 15>]
    spoke1 pppd[496]: sent [CCP ConfReq id=0x2]
    spoke1 pppd[496]: sent [CCP ConfRej id=0x1 <bsd v1 15>]
    spoke1 pppd[496]: rcvd [IPCP ConfReq id=0x1 <addr 10.44.1.1>]
    spoke1 pppd[496]: sent [IPCP ConfAck id=0x1 <addr 10.44.1.1>]
    spoke1 pppd[496]: rcvd [IPV6CP ConfReq id=0x1 <addr fe80::0421:e270:de27:332c>]
    spoke1 pppd[496]: sent [IPV6CP ConfAck id=0x1 <addr fe80::0421:e270:de27:332c>]
    spoke1 pppd[496]: rcvd [IPCP ConfNak id=0x3 <addr 10.44.1.2> <ms-dns1 172.16.0.2> <ms-dns2 172.16.0.2>]
    spoke1 pppd[496]: sent [IPCP ConfReq id=0x4 <addr 10.44.1.2> <ms-dns1 172.16.0.2> <ms-dns2 172.16.0.2>]
    spoke1 pppd[496]: rcvd [IPV6CP ConfAck id=0x2 <addr fe80::79ea:402e:6158:8922>]
    spoke1 pppd[496]: local  LL address fe80::79ea:402e:6158:8922
    spoke1 pppd[496]: remote LL address fe80::0421:e270:de27:332c
    spoke1 pppd[496]: Script /etc/ppp/ipv6-up started (pid 1640)
    spoke1 pppd[496]: rcvd [CCP ConfAck id=0x2]
    spoke1 pppd[496]: rcvd [CCP ConfReq id=0x2]
    spoke1 pppd[496]: sent [CCP ConfAck id=0x2]
    spoke1 pppd[496]: rcvd [IPCP ConfAck id=0x4 <addr 10.44.1.2> <ms-dns1 172.16.0.2> <ms-dns2 172.16.0.2>]
    spoke1 pppd[496]: Script /etc/ppp/ip-pre-up started (pid 1642)
    spoke1 pppd[496]: Script /etc/ppp/ip-pre-up finished (pid 1642), status = 0x0
    spoke1 pppd[496]: local  IP address 10.44.1.2
    spoke1 pppd[496]: remote IP address 10.44.1.1
    spoke1 pppd[496]: primary   DNS address 172.16.0.2
    spoke1 pppd[496]: secondary DNS address 172.16.0.2
    spoke1 pppd[496]: Script /etc/ppp/ip-up started (pid 1645)
    spoke1 pppd[496]: Script /etc/ppp/ipv6-up finished (pid 1640), status = 0x0
    spoke1 pppd[496]: Script /etc/ppp/ip-up finished (pid 1645), status = 0x0