Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Étape 2 : Configuration et vérification d’un VPN IPsec

Ça a été une grosse journée, on le sait. Avant de rentrer chez vous, il y a encore une demande pour la nouvelle filiale. Vous devrez établir un tunnel VPN IPsec sécurisé vers le bureau distant. Ce tunnel permet aux membres de la trust zone d’atteindre en toute sécurité des ressources d’entreprise spécifiques sur le sous-réseau 172.16.200.0/24 sur Internet.

Les tunnels sécurisés sont une fonctionnalité clé des plates-formes SRX. Pouvoir envoyer du trafic sensible sur l’Internet public sans se préoccuper des interceptions ou du vol de données n’est pas une mince affaire. Un VPN IPsec vous permet de tunneliser en toute sécurité le trafic via l’Internet public. Étant donné que le trafic est tunnelisé, il n’est pas nécessaire d’effectuer un NAT source.

Ne vous inquiétez pas, nous vous faciliterons la tâche !

Cette étape vous explique comment :

  • Configuration des interfaces tunnel st0
  • Configuration du routage statique pour diriger le trafic vers le tunnel IPsec
  • Configurer les paramètres IKE et IPsec pour un VPN dynamique basé sur le routage
  • Ajustez les stratégies de sécurité pour vous assurer que seul le trafic provenant de la trust zone envoyée à 172.16.200.0/24 est présenté au tunnel IPsec
  • Utiliser l’interface DE ligne de commande Junos pour vérifier le fonctionnement du VPN IPsec
Figure 1 : Un VPN IPsec pour une connectivité sécurisée entre les filiales et les bureaux distants An IPsec VPN for Secure Branch to Remote Office Connectivity

Présentation du VPN IPsec

Dans cet exemple, le trafic envoyé de la trust zone vers 172.16.200.0/24 utilise le tunnel IPsec. Ce trafic dérive de la règle NAT source et sort de l’extrémité distante avec l’ADRESSE IP source d’origine du sous-réseau 192.168.2.0/24 trust-vlan .

Le tunnel fonctionne point à point entre la filiale et le bureau distant. L’attribution d’adresses IP est donc facultative. Dans cet exemple, nous assignons des adresses aux points de terminaison du tunnel pour autoriser les tests ping comme aide au diagnostic. Une route statique est utilisée à chaque extrémité pour diriger le trafic vers le tunnel. Notez que la route statique à l’emplacement distant correspond au sous-réseau 192.168.2.0/24 de la trust zone. Vous devez correspondre à cette adresse car le NAT source ne se produit pas pour le trafic à l’aide du tunnel.

Note:

La topologie montre un cloud entre la filiale et l’emplacement distant. En règle générale, ce cloud est l’Internet. Pour réduire le nombre d’équipements de notre topologie, nous disposons d’une connexion directe entre les filiales et les sites distants. En conséquence, nous disposons d’un seul sous-réseau 172.16.1.0/24 qui s’étend sur le cloud Internet.

Cela signifie que lorsque vous définissez les passerelles locales et distantes IKE (Internet Key Exchange), les deux points de terminaison partagent le sous-réseau 172.16.1.0/24. Il n’y a aucune différence de configuration ou de fonctionnement si les passerelles IKE se trouvent sur des sous-réseaux distants. La spécification d’une passerelle IKE distante est le cas d’utilisation typique lorsque les deux sites disposent de sauts intermédiaires via Internet.