↓ Skip to main content
Background Image

TP1 - Correction

·1811 words
EduTiko
Author
EduTiko
Keep Cool
Table of Contents

Corrigé TP VyOS multi-sites (Paris, Rennes, Marseille, ISP)
#

1. Configuration de base
#

VyOS-Paris

configure
Interfaces
set interfaces ethernet eth0 address 1.1.1.251/24     # Vers ISP
set interfaces ethernet eth1 address 10.0.1.250/24    # LAN Paris

Nom d’hôte
set system host-name Paris

commit
save
exit

VyOS-Rennes

configure
set interfaces ethernet eth0 address 1.1.1.252/24     # Vers ISP
set interfaces ethernet eth1 address 10.0.2.250/24    # LAN Rennes
set system host-name Rennes
commit
save
exit

VyOS-Marseille

configure
set interfaces ethernet eth0 address 1.1.1.253/24     # Vers ISP
set interfaces ethernet eth1 address 10.0.3.250/24    # LAN Marseille
set system host-name Marseille
commit
save
exit

VyOS-ISP

configure
set interfaces ethernet eth0 address 1.1.1.250/24
set interfaces ethernet eth1 address dhcp           # Simuler Internet (optionnel)
set system host-name ISP
commit
save
exit

2. Routage dynamique avec OSPF
#

Paris

configure
set protocols ospf area 0 network 1.1.1.0/24
set protocols ospf area 0 network 10.0.1.0/24
commit
save

Rennes

configure
set protocols ospf area 0 network 1.1.1.0/24
set protocols ospf area 0 network 10.0.2.0/24
commit
save

Marseille

configure
set protocols ospf area 0 network 1.1.1.0/24
set protocols ospf area 0 network 10.0.3.0/24
commit
save

Vérification

show ip ospf neighbor
show ip route ospf

3. Firewall & NAT
#

NAT sur Paris pour accès Internet des machines LAN 10.0.1.0/24

configure
set nat source rule 100 outbound-interface eth0
set nat source rule 100 source address 10.0.1.0/24
set nat source rule 100 translation address masquerade
commit
save

Firewall (bloquer pings de Marseille → Paris)

Définir l’action et la description de la règle
#

Nous utilisons l’action drop

set firewall ipv4 forward filter rule 10 description "Bloquer Ping de Marseille vers Paris"
set firewall ipv4 forward filter rule 10 action drop

Spécifier le protocole
#

Le ping utilise le protocole ICMP.

set firewall ipv4 forward filter rule 10 protocol icmp

Spécifier les adresses source et destination
#

Nous définissons le réseau source (Marseille LAN) et le réseau destination (Paris LAN)

set firewall ipv4 forward filter rule 10 source address 10.0.3.0/24
set firewall ipv4 forward filter rule 10 destination address 10.0.1.0/24

Spécifier le type ICMP: Echo Request (Type 8)
#

set firewall ipv4 forward filter rule 10 icmp type 8

Récapitulatif

configure
set firewall ipv4 forward filter rule 10 action drop
set firewall ipv4 forward filter rule 10 description "Bloquer Ping de Marseille vers Paris"
set firewall ipv4 forward filter rule 10 protocol icmp
set firewall ipv4 forward filter rule 10 source address 10.0.3.0/24
set firewall ipv4 forward filter rule 10 destination address 10.0.1.0/24
commit
save

4. Configuration du Tunnel IPsec Site-to-Site
#

La configuration IPsec se déroule en plusieurs étapes clés pour chaque routeur.

Le protocole IPsec utilise deux phases : la Phase 1 (IKE) pour établir un canal sécurisé et la Phase 2 (ESP/AH) pour négocier les associations de sécurité (SAs) qui protègent le trafic de données

Nous utiliserons l’authentification par clé pré-partagée (Pre-shared key), qui nécessite que les deux pairs aient la même clé Nous suivrons la structure de configuration Policy-based VPN et IKEv1

Étape 1 : Configuration du Groupe IKE (Phase 1)
#

Cette phase établit l’Association de Sécurité IKE (IKE SA) .Les paramètres IKE doivent correspondre sur les deux pairs

Explications :

  • Nous définissons un groupe IKE (IKE-GROUP)
  • Nous utilisons la version IKEv1, bien que IKEv2 soit souvent recommandé, IKEv1 est utilisé dans l’exemple de configuration Policy-Based
  • Les algorithmes de chiffrement et de hachage sont définis dans une proposition (ici, proposition 10)
  • L’action close-action et le dead-peer-detection (DPD) sont essentiels pour maintenir la stabilité du tunnel, surtout selon que le routeur est l’initiateur ou le répondeur

Sur VyOS-Paris (Initiateur)

L’initiateur essaie activement d’établir le tunnel En cas de fermeture inattendue du CHILD_SA, close-action ‘start’ tente de le recréer immédiatement

1.1 Définition du Groupe IKE

set vpn ipsec ike-group IKE-GROUP key-exchange 'ikev1'
set vpn ipsec ike-group IKE-GROUP lifetime '28800'
set vpn ipsec ike-group IKE-GROUP proposal 10 dh-group '14'
set vpn ipsec ike-group IKE-GROUP proposal 10 encryption 'aes256'
set vpn ipsec ike-group IKE-GROUP proposal 10 hash 'sha256'

1.2 Configuration de la Détection de Pair Mort (DPD) et Action de Fermeture

set vpn ipsec ike-group IKE-GROUP close-action 'start'
set vpn ipsec ike-group IKE-GROUP dead-peer-detection action 'restart'
set vpn ipsec ike-group IKE-GROUP dead-peer-detection interval '30'

Sur VyOS-Rennes (Répondeur) Le répondeur attend passivement l’initiation close-action ’none’ et dead-peer-detection action ‘clear’ sont recommandés pour le répondeur

1.1 Définition du Groupe IKE (identique à Paris)

set vpn ipsec ike-group IKE-GROUP key-exchange 'ikev1'
set vpn ipsec ike-group IKE-GROUP lifetime '28800'
set vpn ipsec ike-group IKE-GROUP proposal 10 dh-group '14'
set vpn ipsec ike-group IKE-GROUP proposal 10 encryption 'aes256'
set vpn ipsec ike-group IKE-GROUP proposal 10 hash 'sha256'

1.2 Configuration de la Détection de Pair Mort (DPD) et Action de Fermeture

set vpn ipsec ike-group IKE-GROUP close-action 'none'
set vpn ipsec ike-group IKE-GROUP dead-peer-detection action 'clear'
set vpn ipsec ike-group IKE-GROUP dead-peer-detection interval '30'

Étape 2 : Configuration du Groupe ESP (Phase 2)
#

Cette phase définit les paramètres pour l’Association de Sécurité IPsec (IPsec SA), qui protège le trafic de données Nous utilisons le mode tunnel (par défaut) pour l’encapsulation du paquet IP original

Explications :

  • Nous définissons un groupe ESP (ESP-GROUP)
  • Le mode par défaut pour le VPN Site-to-Site est tunnel
  • Le Perfect Forward Secrecy (PFS) est activé (pfs ’enable’) pour que la clé ESP soit indépendante de la clé IKE
  • La durée de vie (lifetime) par défaut est de 3600 secondes

Sur VyOS-Paris et VyOS-Rennes (Doit être identique)

2.1 Définition du Groupe ESP

set vpn ipsec esp-group ESP-GROUP lifetime '3600'
set vpn ipsec esp-group ESP-GROUP mode 'tunnel'
set vpn ipsec esp-group ESP-GROUP pfs 'enable'
set vpn ipsec esp-group ESP-GROUP proposal 10 encryption 'aes256'
set vpn ipsec esp-group ESP-GROUP proposal 10 hash 'sha256'

Étape 3 : Spécification de l’Interface WAN
#

Nous spécifions l’interface physique utilisée pour l’établissement du VPN (l’interface publique WAN, par exemple eth0)

Sur VyOS-Paris et VyOS-Rennes

set vpn ipsec interface 'eth0'

Étape 4 : Configuration de l’Authentification PSK
#

Nous configurons la clé pré-partagée (PSK) et les identifiants pour l’authentification

Nous utiliserons les adresses WAN comme identifiants (IDs)

Explications :

  • id et remote-id sont utilisés pour sélectionner la bonne clé PSK
  • Le secret (la clé) doit être le même sur les deux routeurs

Sur VyOS-Paris et VyOS-Rennes

4.1 Définition de la clé PSK et des IDs

set vpn ipsec authentication psk AUTH-PSK id '1.1.1.251' # ID de Paris
set vpn ipsec authentication psk AUTH-PSK id '1.1.1.252' # ID de Rennes
set vpn ipsec authentication psk AUTH-PSK secret 'MON_SECRET_VYOS'

Étape 5 : Configuration du Pair (Peer)
#

Nous définissons les informations spécifiques du pair distant (adresse distante, groupes utilisés, rôle)

Sur VyOS-Paris (Initiateur) Paris se connecte au pair Rennes (1.1.1.252) et initie la connexion (connection-type ‘initiate’)

5.1 Configuration du Pair Paris (PEER2)

set vpn ipsec site-to-site peer RENNES authentication local-id '1.1.1.251'
set vpn ipsec site-to-site peer RENNES authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer RENNES authentication remote-id '1.1.1.252'
set vpn ipsec site-to-site peer RENNES connection-type 'initiate'
set vpn ipsec site-to-site peer RENNES default-esp-group 'ESP-GRPOUP'
set vpn ipsec site-to-site peer RENNES ike-group 'IKE-GROUP'
set vpn ipsec site-to-site peer RENNES local-address '1.1.1.251'
set vpn ipsec site-to-site peer RENNES remote-address '1.1.1.252'

Sur VyOS-Rennes (Répondeur) Lyon se connecte au pair Paris (1.1.1.251) et attend la connexion (connection-type ‘respond’)

5.1 Configuration du Pair Rennes (PEER1)

set vpn ipsec site-to-site peer PARIS authentication local-id '1.1.1.252'
set vpn ipsec site-to-site peer PARIS authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer PARIS authentication remote-id '1.1.1.251'
set vpn ipsec site-to-site peer PARIS connection-type 'respond'
set vpn ipsec site-to-site peer PARIS default-esp-group 'ESP-GRPOUP'
set vpn ipsec site-to-site peer PARIS ike-group 'IKE-GROUP'
set vpn ipsec site-to-site peer PARIS local-address '1.1.1.252'
set vpn ipsec site-to-site peer PARIS remote-address '1.1.1.251'

Étape 6 : Configuration des Tunnels (Traffic Selectors)
#

Puisque nous utilisons un VPN basé sur des politiques (Policy-based VPN) , nous devons spécifier quels réseaux locaux seront protégés par le tunnel (les traffic selectors ou préfixes locaux/distants)

Explications :

  • Le tunnel 1 définit l’Association de Sécurité (SA) qui sera créée
  • Le local prefix est le réseau LAN derrière le routeur VyOS actuel.
  • Le remote prefix est le réseau LAN du site distant.

Sur VyOS-Paris Le trafic de 10.0.1.0/24 (Paris) vers 10.0.2.0/24 (Lyon) sera chiffré.

6.1 Définition du tunnel Policy-Based vers Rennes

set vpn ipsec site-to-site peer RENNES tunnel 1 local prefix '10.0.1.0/24'
set vpn ipsec site-to-site peer RENNES tunnel 1 remote prefix '10.0.2.0/24'

Sur VyOS-Rennes Le trafic de 10.0.3.0/24 (Lyon) vers 10.0.1.0/24 (Paris) sera chiffré. Notez que les préfixes sont inversés par rapport à la configuration de Paris.

6.1 Définition du tunnel Policy-Based vers Paris

set vpn ipsec site-to-site peer PARIS tunnel 1 local prefix '10.0.2.0/24'
set vpn ipsec site-to-site peer PARIS tunnel 1 remote prefix '10.0.1.0/24'

Attention Il faut initier une connection entre LAN PARIS et LAN RENNES

Étape 7 : Exclusion NAT (Si nécessaire)
#

Si les routeurs VyOS effectuent du NAT Source (SNAT) sur leur interface WAN (eth0), il est impératif d’ajouter des règles d’exclusion pour que le trafic entre les réseaux LAN (10.0.1.0/24 et 10.0.3.0/24) ne soit pas traduit en adresse WAN

Explications :

  • L’exclusion NAT est nécessaire pour que les paquets des LANs conservent leurs adresses IP privées lorsqu’ils sont chiffrés et envoyés sur le tunnel, garantissant que le pair distant peut les acheminer correctement

Sur VyOS-Paris

set nat source rule 10 destination address '10.0.3.0/24'
set nat source rule 10 'exclude' [39]
set nat source rule 10 outbound-interface name 'eth0'
set nat source rule 10 source address '10.0.1.0/24'

Sur VyOS-Rennes

set nat source rule 10 destination address '10.0.1.0/24'
set nat source rule 10 'exclude'
set nat source rule 10 outbound-interface name 'eth0'
set nat source rule 10 source address '10.0.3.0/24'

Projet Pour IKE v2

Le changement principal pour IKEv2 se trouve ici, où nous spécifions la version du protocole d’échange de clés. Explications :

  • Nous définissons key-exchange ‘ikev2’
  • La configuration du mode (mode main ou mode aggressive) n’est plus pertinente car elle s’applique uniquement à IKEv1
  • Le paramètre dead-peer-detection timeout n’est utilisé que pour IKEv1 et est donc omis.

Validation et Dépannage
#

Une fois toutes les configurations entrées (et un commit), Paris (l’initiateur) tentera d’établir le tunnel. Pour vérifier l’état du tunnel, vous pouvez utiliser les commandes opérationnelles :

  1. Vérifier l’état de l’IKE SA (Phase 1) :

    • show vpn ike sa
    • Si le statut est up, la phase 1 est établie

  2. Vérifier l’état de l’IPsec SA (Phase 2) :

    • show vpn ipsec sa show vpn ipsec sa detail
    • Si le statut du tunnel est up, la phase 2 est établie et le trafic peut circuler

  3. Vérifier les connexions détaillées :

    • show vpn ipsec connections

  4. Dépannage : Si le tunnel n’est pas établi (down), la vérification des logs est cruciale :

    • show log ipsec
    • Des messages comme NO_PROPOSAL_CHOSEN indiquent un désaccord sur les algorithmes (Phase 1 ou Phase 2)
    • AUTHENTICATION_FAILED signifie que la clé PSK ou les IDs ne correspondent pas
    • TS_UNACCEPTABLE signifie que les préfixes de réseau (Local TS/Remote TS) ne correspondent pas entre les deux routeurs
monitor traffic interface eth0