4. Routeurs Spoke (vert)

Dans le scénario défini dans la Section 2, « 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.

Dans le contexte de ces manipulations, le réseau local de site est représenté par des conteneurs LXD raccordés à un commutateur virtuel.

Cette section, comme la précédente, reprend la partie Routeur Spoke (vert) du support Routage inter-VLAN et protocole PPPoE “contexte Cloud“.

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 routage est activé.

  • Le paquet ppp est installé.

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

  • Le fichier /etc/ppp/peers/pppoe-provider de définition du profil de session PPP est créé.

    Attention au nom d'utilisateur qui doit correspondre à l'entrée du fichier /etc/ppp/chap-secrets !

    Attention au numéro de VLAN de la sous-interface qui doit désigner la bon côté du triangle !

  • Le fichier /etc/network/interfaces doit contenir une définition d'interface qui appelle le profil de session pppoe-provider.

Q11.

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.

sur le routeur Spoke-1 de la maquette, on relève les messages suivants à l'aide de l'une des deux commandes suivantes :

grep -i ppp /var/log/syslog
journalctl /usr/sbin/pppd
  • Lancement du démon pppd.

    ifup[668]: Plugin rp-pppoe.so loaded.
    Spoke-1 kernel: [    6.973809] PPP generic driver version 2.4.2
    Spoke-1 pppd[670]: pppd 2.4.9 started by root, uid 0
    Spoke-1 kernel: [    7.032091] NET: Registered PF_PPPOX protocol family
  • Reconnaissance des extrémités de la liaison point à point avec le protocole PPPoE

    pppd[670]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
    pppd[670]:  dst ff:ff:ff:ff:ff:ff  src b8:ad:ca:fe:00:c9
    pppd[670]:  [service-name] [host-uniq  9e 02 00 00]
    pppd[670]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 44
    pppd[670]:  dst b8:ad:ca:fe:00:c9  src b8:ad:ca:fe:00:c8
    pppd[670]:  [AC-name BRAS] [service-name] [AC-cookie  0f 2a 7b 0a 70 6e 44 fb f5 6d 81 5f 8b 21 bd 3b e2 17 00 00] [host-uniq  9e 02 00 00]
    pppd[670]: Send PPPOE Discovery V1T1 PADR session 0x0 length 36
    pppd[670]:  dst b8:ad:ca:fe:00:c8  src b8:ad:ca:fe:00:c9
    pppd[670]:  [service-name] [host-uniq  9e 02 00 00] [AC-cookie  0f 2a 7b 0a 70 6e 44 fb f5 6d 81 5f 8b 21 bd 3b e2 17 00 00]
    pppd[670]: Recv PPPOE Discovery V1T1 PADS session 0x1 length 12
    pppd[670]:  dst b8:ad:ca:fe:00:c9  src b8:ad:ca:fe:00:c8
    pppd[670]:  [service-name] [host-uniq  9e 02 00 00]
    pppd[670]: PADS: Service-Name: ''
    pppd[670]: PPP session is 1
    pppd[670]: Connected to b8:ad:ca:fe:00:c8 via interface enp0s1.441
  • Négociation des paramètres et authentification dans la sous-couche LCP.

    pppd[670]: using channel 1
    pppd[670]: Using interface ppp0
    pppd[670]: Connect: ppp0 <--> enp0s1.441
    pppd[670]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x4569d495>]
    pppd[670]: rcvd [LCP ConfReq id=0x1 <mru 1492> <auth chap MD5> <magic 0x26452256>]
    pppd[670]: sent [LCP ConfAck id=0x1 <mru 1492> <auth chap MD5> <magic 0x26452256>]
    pppd[670]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x4569d495>]
    pppd[670]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0x4569d495>]
    pppd[670]: sent [LCP EchoReq id=0x0 magic=0x4569d495]
    pppd[670]: rcvd [LCP EchoReq id=0x0 magic=0x26452256]
    pppd[670]: sent [LCP EchoRep id=0x0 magic=0x4569d495]
    pppd[670]: rcvd [CHAP Challenge id=0xe9 <4d86c0171d670c9a2aa94a15af489c0185>, name = "Hub"]
    pppd[670]: sent [CHAP Response id=0xe9 <3eb3fe9ab25da4b1536cbfa8c24583ba>, name = "5p0k3_1"]
    pppd[670]: rcvd [LCP EchoRep id=0x0 magic=0x26452256]
    pppd[670]: rcvd [CHAP Success id=0xe9 "Access granted"]
    pppd[670]: CHAP authentication succeeded: Access granted
    pppd[670]: CHAP authentication succeeded
    pppd[670]: peer from calling number B8:AD:CA:FE:00:C8 authorized
  • Attribution des adresses dans la sous-couche NCP. Ici, la lettre N est remplacée par IP pour le protocole IPv4 et IPV6 pour le protocole IPv6.

    En fin de copie d'écran, on relève le statut des scripts d'application des routes par défaut vers la liaison PPP.

    pppd[670]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
    pppd[670]: sent [IPV6CP ConfReq id=0x1 <addr fe80::98cd:4c17:10de:cd80>]
    pppd[670]: rcvd [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
    pppd[670]: sent [CCP ConfReq id=0x1]
    pppd[670]: sent [CCP ConfRej id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
    pppd[670]: rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 10.44.1.1>]
    pppd[670]: sent [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
    pppd[670]: rcvd [IPV6CP ConfReq id=0x1 <addr fe80::6d60:51b9:d944:ff96>]
    pppd[670]: sent [IPV6CP ConfAck id=0x1 <addr fe80::6d60:51b9:d944:ff96>]
    pppd[670]: rcvd [IPCP ConfNak id=0x1 <addr 10.44.1.2> <ms-dns1 172.16.0.2> <ms-dns2 172.16.0.2>]
    pppd[670]: sent [IPCP ConfReq id=0x2 <addr 10.44.1.2> <ms-dns1 172.16.0.2> <ms-dns2 172.16.0.2>]
    pppd[670]: rcvd [IPV6CP ConfAck id=0x1 <addr fe80::98cd:4c17:10de:cd80>]
    pppd[670]: local  LL address fe80::98cd:4c17:10de:cd80
    pppd[670]: remote LL address fe80::6d60:51b9:d944:ff96
    pppd[670]: Script /etc/ppp/ipv6-up started (pid 698)
    pppd[670]: rcvd [CCP ConfAck id=0x1]
    pppd[670]: rcvd [CCP ConfReq id=0x2]
    pppd[670]: sent [CCP ConfAck id=0x2]
    pppd[670]: rcvd [IPCP ConfReq id=0x2 <addr 10.44.1.1>]
    pppd[670]: sent [IPCP ConfAck id=0x2 <addr 10.44.1.1>]
    pppd[670]: rcvd [IPCP ConfAck id=0x2 <addr 10.44.1.2> <ms-dns1 172.16.0.2> <ms-dns2 172.16.0.2>]
    pppd[670]: Script /etc/ppp/ip-pre-up started (pid 700)
    pppd[670]: Script /etc/ppp/ip-pre-up finished (pid 700), status = 0x0
    pppd[670]: local  IP address 10.44.1.2
    pppd[670]: remote IP address 10.44.1.1
    pppd[670]: primary   DNS address 172.16.0.2
    pppd[670]: secondary DNS address 172.16.0.2
    pppd[670]: Script /etc/ppp/ip-up started (pid 703)
    pppd[670]: Script /etc/ppp/ipv6-up finished (pid 698), status = 0x0
    pppd[670]: Script /etc/ppp/ip-up finished (pid 703), status = 0x0

Q12.

Comment installer et configurer le commutateur virtuel qui permet de raccorder les conteneurs dans le réseau dédié (vert) ?

Reprendre les traitements réalisés dans la section sur l'activation du commutateur virtuel du support Routage inter-VLAN et protocole PPPoE “contexte Cloud“.

Pour traiter cette question, il faut :

  • Installer le paquet openvswitch-switch pour créer les commutateurs.

  • Ajouter les définitions des commutateurs dans le fichier de configuration /etc/network/interfaces.

  • Activer les nouvelles interfaces réseau SVI (Switched Virtual Interface).

On obtient les résultats suivants pour le routeur Spoke-1 avec le VLAN numéro 10.

  • Configuration du commutateur virtuel asw-host.

    sudo ovs-vsctl show
    338deea5-c400-4250-8c2b-02d38b8138b8
        Bridge asw-host
            Port sw-vlan10
                tag: 10
                Interface sw-vlan10
                    type: internal
            Port asw-host
                Interface asw-host
                    type: internal
        ovs_version: "2.17.2"
  • Table de routage IPv4.

    ip route ls
    default dev ppp0 scope link
    10.0.10.0/24 dev sw-vlan10 proto kernel scope link src 10.0.10.1
    10.44.1.1 dev ppp0 proto kernel scope link src 10.44.1.2
  • Table de routage IPv6.

    ip -6 route ls dev sw-vlan10
    fda0:7a62:a::/64 proto kernel metric 256 pref medium
    fe80::/64 proto kernel metric 256 pref medium

Q13.

Comment configurer le gestionnaire de conteneur LXD pour que tous les conteneurs soient automatiquement placés dans le bon VLAN avec un adressage IPv6 de type SLAAC et un adressage IPv4 automatisé à l'aide de scripts ?

Reprendre les traitements réalisés dans les sections sur l'installation et la configuration du gestionnaire de conteneur LXD du support Routage inter-VLAN et protocole PPPoE “contexte Cloud“.

Pour traiter cette question, il faut :

  • Installer le paquet snapd.

  • Installer le snap lxd.

  • Initialiser la configuration du gestionnaire de conteneur avec la commande lxd init.

  • Installer et configurer le service radvd qui assure l'adressage automatique IPv6 SLAAC.

Pour valider le résultat, on affiche le profil de configuration par défaut des conteneurs qui montre que le raccordement au commutateur se fera dans le bon VLAN.

lxc profile show default
config: {}
description: Default LXD profile
devices:
  eth0:
    name: eth0
    nictype: bridged
    parent: sw-vlan10
    type: nic
  root:
    path: /
    pool: default
    type: disk
name: default
used_by: []

Pour l'adressage automatique IPv6, on doit se contenter de l'état du service à ce stade.

systemctl status radvd
• radvd.service - Router advertisement daemon for IPv6
     Loaded: loaded (/lib/systemd/system/radvd.service; enabled; preset: enabled)
     Active: active (running) since Sat 2022-10-22 15:15:00 CEST; 9s ago
       Docs: man:radvd(8)
    Process: 5022 ExecStartPre=/usr/sbin/radvd --logmethod stderr_clean --configtest (code=exited, status=0/SUCCESS)
    Process: 5023 ExecStart=/usr/sbin/radvd --logmethod stderr_clean (code=exited, status=0/SUCCESS)
   Main PID: 5024 (radvd)
      Tasks: 2 (limit: 1114)
     Memory: 516.0K
        CPU: 30ms
     CGroup: /system.slice/radvd.service
             ├─5024 /usr/sbin/radvd --logmethod stderr_clean
             └─5025 /usr/sbin/radvd --logmethod stderr_clean

oct. 22 15:15:00 Spoke-1 systemd[1]: Starting Router advertisement daemon for IPv6...
oct. 22 15:15:00 Spoke-1 radvd[5022]: config file, /etc/radvd.conf, syntax ok
oct. 22 15:15:00 Spoke-1 radvd[5023]: version 2.18 started
oct. 22 15:15:00 Spoke-1 systemd[1]: Started Router advertisement daemon for IPv6.

Q14.

Comment lancer la création et relever les adresses utilisées par les conteneurs LXD après installation et configuration de 3 conteneurs dans le VLAN vert ?

Là encore on reprend les traitements réalisés dans le support Routage inter-VLAN et protocole PPPoE “contexte Cloud“.

Après exécution de la boucle de création des conteneurs, voici une copie du premier résultat avec adressage IPv6 uniquement.

lxc ls
+------+---------+------+-----------------------------------------+-----------+-----------+
| NAME |  STATE  | IPV4 |                  IPV6                   |   TYPE    | SNAPSHOTS |
+------+---------+------+-----------------------------------------+-----------+-----------+
| c0   | RUNNING |      | fda0:7a62:a:0:216:3eff:feb6:f7fd (eth0) | CONTAINER | 0         |
+------+---------+------+-----------------------------------------+-----------+-----------+
| c1   | RUNNING |      | fda0:7a62:a:0:216:3eff:fe91:e2e2 (eth0) | CONTAINER | 0         |
+------+---------+------+-----------------------------------------+-----------+-----------+
| c2   | RUNNING |      | fda0:7a62:a:0:216:3eff:feb0:ba39 (eth0) | CONTAINER | 0         |
+------+---------+------+-----------------------------------------+-----------+-----------+

Pour compléter l'adressage, on exécute la boucle de création des fichiers /etc/systemd/network/eth0.network de chaque conteneur dans le bon VLAN.

for i in {0..2}
do
        echo ">>>>>>>>>>>>>>>>> c$i"
config=$(cat << EOF
[Match]
Name=eth0

[Network]
DHCP=false
Address=10.0.10.$((i + 10))/24
Address=fda0:7a62:a::$(printf "%x" $((i + 10)))/64
Gateway=10.0.10.1
DNS=172.16.0.2
EOF
)
        lxc exec c$i -- bash -c "echo \"${config}\" | tee /etc/systemd/network/eth0.network"
        lxc exec c$i -- systemctl restart systemd-networkd
done

L'adressage complet donne le résultat suivant :

lxc ls
+------+---------+-------------------+-----------------------------------------+-----------+-----------+
| NAME |  STATE  |       IPV4        |                  IPV6                   |   TYPE    | SNAPSHOTS |
+------+---------+-------------------+-----------------------------------------+-----------+-----------+
| c0   | RUNNING | 10.0.10.10 (eth0) | fda0:7a62:a::a (eth0)                   | CONTAINER | 0         |
|      |         |                   | fda0:7a62:a:0:216:3eff:feb6:f7fd (eth0) |           |           |
+------+---------+-------------------+-----------------------------------------+-----------+-----------+
| c1   | RUNNING | 10.0.10.11 (eth0) | fda0:7a62:a::b (eth0)                   | CONTAINER | 0         |
|      |         |                   | fda0:7a62:a:0:216:3eff:fe91:e2e2 (eth0) |           |           |
+------+---------+-------------------+-----------------------------------------+-----------+-----------+
| c2   | RUNNING | 10.0.10.12 (eth0) | fda0:7a62:a::c (eth0)                   | CONTAINER | 0         |
|      |         |                   | fda0:7a62:a:0:216:3eff:feb0:ba39 (eth0) |           |           |
+------+---------+-------------------+-----------------------------------------+-----------+-----------+

On peut maintenant lancer des boucles de tests ICMP depuis les conteneurs.

for i in {0..2}
do
        echo ">>>>>>>>>>>>>>>>> c$i"
        ping -q -c2 9.9.9.9
done

Q15.

Quelles sont les opérations à effectuer pour installer un service Web dans chaque conteneur ? Une fois l'installation du service effectuée, comment vérifier que ce service est bien en écoute ?

Installer le paquet nginx dans chaque conteneur et donner la liste des ports en écoute dans chaque conteneur.

On reprend l'exécution d'une boucle qui réalise les mêmes actions dans chaque conteneur.

for i in {0..2}
do
        echo ">>>>>>>>>>>>>>>>> c$i"
        lxc exec c$i -- apt -y update
        lxc exec c$i -- apt -y full-upgrade
        lxc exec c$i -- apt -y install nginx
        lxc exec c$i -- apt clean
done

Dans chaque conteneur, le port TCP/80 est ouvert pour les protocoles réseau IPv4 et IPv6. La liste des ports de la couche transport en écoute est obtenue à l'aide de la commande ss.

for i in {0..2}
do
        echo ">>>>>>>>>>>>>>>>> c$i"
        lxc exec c$i -- ss -at '( dport = :http or sport = :http )';
done

Voici un exemple de résultat.

>>>>>>>>>>>>>>>>> c0
State      Recv-Q    Send-Q     Local Address:Port    Peer Address:Port    Process
LISTEN     0         511              0.0.0.0:http         0.0.0.0:*
LISTEN     0         511                 [::]:http            [::]:*
>>>>>>>>>>>>>>>>> c1
State      Recv-Q    Send-Q     Local Address:Port    Peer Address:Port    Process
LISTEN     0         511              0.0.0.0:http         0.0.0.0:*
LISTEN     0         511                 [::]:http            [::]:*
>>>>>>>>>>>>>>>>> c2
State      Recv-Q    Send-Q     Local Address:Port    Peer Address:Port    Process
LISTEN     0         511              0.0.0.0:http         0.0.0.0:*
LISTEN     0         511                 [::]:http            [::]:*

Q16.

Comment valider l'accès à ces services Web à partir du routeur Spoke ?

Il s'agit de faire un test au niveau de la couche application. À la console, les deux outils adaptés sont wget et curl.

Voici un exemple de test pour chaque protocole de la couche réseau avec wget dans le contexte de la maquette.

for addr in {10..12}
do
        wget -O /dev/null http://10.0.10.$addr 2>&1 | grep "HTTP "
done
requête HTTP transmise, en attente de la réponse… 200 OK
requête HTTP transmise, en attente de la réponse… 200 OK
requête HTTP transmise, en attente de la réponse… 200 OK
for addr in {10..12}
do
        wget -O /dev/null http://[fda0:7a62:a::$(printf "%x" $addr)] 2>&1 | grep "HTTP "
done
requête HTTP transmise, en attente de la réponse… 200 OK
requête HTTP transmise, en attente de la réponse… 200 OK
requête HTTP transmise, en attente de la réponse… 200 OK