test

Guide d'administration système : services IP

ProcedureProtection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4

En mode Tunnel, le paquet IP interne détermine la stratégie IPsec qui protège son contenu.

Cette procédure prolonge la procédure Sécurisation du trafic entre deux systèmes à l'aide d'IPsec. La configuration est décrite à la section Description de la topologie réseau requise par les tâches IPsec afin de protéger un VPN.

Remarque –

Effectuez cette procédure sur les deux systèmes.

Outre la connexion de deux systèmes, vous connectez deux intranets qui leur sont connectés. Les systèmes de cette procédure fonctionnent comme des passerelles.

Avant de commencer

Vous devez vous trouver dans la zone globale pour configurer la stratégie IPsec pour le système ou pour une zone IP partagée. Dans une zone IP exclusive, vous devez configurer la stratégie IPsec dans la zone non globale.

  1. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

    Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

    Remarque –

    En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.

  2. Contrôlez le flux de paquets avant de configurer IPsec.

    1. Assurez-vous que le transfert IP et le routage dynamique IP sont désactivés.


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
IPv4 forwarding     disabled           disabled
   IPv4 routing     default (enabled)   enabled
…

      Si le transfert IP et le routage dynamique IP sont activés, vous pouvez les désactiver en tapant :


      # routeadm -d ipv4-routing -d ipv4-forwarding
# routeadm -u

      La désactivation du transfert IP évite le transfert des paquets d'un réseau à un autre via ce système. La commande routeadm est décrite à la page de manuel routeadm(1M).

    2. Activez le multiréseau de destination strict IP.


      # ndd -set /dev/ip ip_strict_dst_multihoming 1

      L'activation du multiréseau de destination strict IP assure que les paquets de l'une des adresses de destination du système arrivent à l'adresse de destination adéquate.

      Lorsque le multiréseau de destination strict est activé, les paquets arrivant sur une interface particulière doivent être adressés à l'une des adresses IP locales de cette interface. Tous les autres paquets sont abandonnés, même les paquets envoyés vers d'autres adresses locales du système.

      Attention – Attention –

      Par défaut, lors de l'initialisation du système, la valeur multiréseau est désélectionnée. Pour rendre persistante la valeur modifiée, reportez-vous à la section Protection contre l'usurpation d'adresse IP.

    3. Désactivez la plupart des services réseau, voire tous les services réseau.

      Remarque –

      Si le système a été installé avec le profil SMF "limité", vous pouvez ignorer cette étape. Tous les services réseau sont désactivés, à l'exception de Solaris Secure Shell.

      La désactivation des services réseau évite que le système soit affecté par les paquets IP. Par exemple, vous pouvez utiliser un démon SNMP, une connexion telnet ou une connexion rlogin.

      Procédez de l'une des manières suivantes :

      • Si vous exécutez Solaris10 11/06 ou une version supérieure, exécutez le profil SMF "limité".


        # netservices limited

      • Dans le cas contraire, désactivez les services réseau un à un.


        # svcadm disable network/ftp:default
# svcadm disable network/finger:default
# svcadm disable network/login:rlogin
# svcadm disable network/nfs/server:default
# svcadm disable network/rpc/rstat:default
# svcadm disable network/smtp:sendmail
# svcadm disable network/telnet:default

    4. Assurez-vous que la plupart des services réseau sont désactivés.

      Assurez-vous que les montages en loopback et le service ssh sont en cours d'exécution.


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
…
online         Aug_09   svc:/network/ssh:default

  3. Ajoutez une paire de SA entre les deux systèmes.

    Procédez de l'une des manières suivantes :

  4. Ajoutez une stratégie IPsec.

    Modifiez le fichier /etc/inet/ipsecinit.conf afin d'ajouter la stratégie IPsec pour le VPN. Pour renforcer la stratégie, reportez-vous à l'Exemple 20–12. Vous trouverez d'autres exemples à la section Protection d'un VPN à l'aide d'IPsec via des tunnels en mode Tunnel (exemple).

    Dans cette stratégie, la protection IPsec n'est pas requise entre les systèmes du réseau local et l'adresse IP interne de la passerelle, d'où l'ajout d'une déclaration bypass.

    1. Sur le système enigma, saisissez l'entrée suivante dans le fichier ipsecinit.conf :


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.16.16.6 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. Sur le système partym, tapez l'entrée suivante dans le fichier ipsecinit.conf :


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

  5. (Facultatif) Vérifiez la syntaxe du fichier de stratégie IPsec. 


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. Pour configurer le tunnel et le protéger à l'aide d'IPsec, suivez les étapes en fonction de la version de Solaris utilisée :

    • À partir de la version Solaris 10 4/09, suivez les étapes Étape 7 à Étape 13, puis exécutez le protocole de routage tel qu'indiqué à l'Étape 22.

    • Si vous exécutez une version antérieure à la version Solaris 10 4/09, suivez les étapes Étape 14 à Étape 22.

  7. Configurez le tunnel ip.tun0 dans le fichier /etc/hostname.ip.tun0.

    La syntaxe du fichier est la suivante :


    system1-point system2-point tsrc system1-taddr tdst system2-taddr router up

    1. Sur le système enigma, ajoutez l'entrée suivante au fichier hostname.ip.tun0 :


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

    2. Sur le système partym, ajoutez l'entrée suivante au fichier hostname.ip.tun0 :


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

  8. Protégez le tunnel à l'aide de la stratégie IPsec créée.


    # svcadm refresh svc:/network/ipsec/policy:default

  9. Pour lire les informations du fichier de configuration du tunnel, redémarrez les services réseau.


    # svcadm restart svc:/network/initial:default

  10. Activez le transfert IP pour l'interface hme1.

    1. Sur le système enigma, ajoutez l'entrée de routeur au fichier /etc/hostname.hme1.


      192.168.116.16 router

    2. Sur le système partym, ajoutez l'entrée de routeur au fichier /etc/hostname.hme1.


      192.168.13.213 router

    Le transfert IP signifie que les paquets arrivant peuvent être transférés. Le transfert IP signifie également que les paquets quittant l'interface peuvent provenir d'un autre emplacement. Pour que le transfert de paquet s'effectue sans erreur, vous devez activer le transfert IP à la fois sur l'interface réceptrice et sur l'interface émettrice.

    Étant donné que l'interface hme1 se trouve dans l'intranet, le transfert IP doit être activé pour hme1. Comme ip.tun0 connecte les deux systèmes via Internet, le transfert IP doit être activé pour ip.tun0.

    Le transfert IP de l'interface hme0 est désactivé afin d'éviter toute injection de paquets par un concurrent externe dans l'intranet protégé. Le terme externe fait référence à Internet.

  11. Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.

    1. Sur le système enigma, ajoutez l'indicateur private au fichier /etc/hostname.hme0. 


      10.16.16.6 private

    2. Sur le système partym, ajoutez l'indicateur private au fichier /etc/hostname.hme0. 


      10.1.3.3 private

    Même si le transfert de l'IP de hme0 est désactivé, l'implémentation d'un protocole de routage peut permettre d'annoncer l'interface. Par exemple, le protocole in.routed peut encore annoncer que hme0 est disponible pour transférer des paquets à ses homologues dans l'intranet. Pour éviter ces annonces, définissez l'indicateur private de l'interface.

  12. Ajoutez manuellement une route par défaut sur l'interface hme0.

    La route par défaut doit correspondre à un routeur bénéficiant d'un accès direct à Internet.

    1. Sur le système enigma, ajoutez la route suivante :


      # route add default 192.168.116.4

    2. Sur le système partym, ajoutez la route suivante :


      # route add default 192.168.13.5

      Même si l'interface hme0 ne fait pas partie de l'intranet, hme0 n'a pas besoin de passer par Internet pour atteindre le système homologue. Pour trouver son homologue, hme0 requiert des informations sur le routage Internet. Pour le reste d'Internet, le système VPN apparaît comme étant un hôte, non un routeur. Par conséquent, vous pouvez utiliser un routeur par défaut ou exécuter le protocole de recherche de routeur pour rechercher le système. Pour de plus amples informations, reportez-vous aux pages de manuel route(1M) et in.routed(1M).

  13. Pour terminer la procédure, passez à l'Étape 22 pour exécuter un protocole de routage.

  14. Configurez le tunnel ip.tun0.

    Remarque –

    Les étapes suivantes permettent de configurer un tunnel sur un système exécutant une version antérieure à la version Solaris 10 4/09.

    Utilisez les commandes ifconfig pour créer l'interface point à point :


    # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 system1-point system2-point \
tsrc system1-taddr tdst system2-taddr

    1. Sur le système enigma, saisissez les commandes ci-dessous :


      # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.16.16.6 10.1.3.3 \
tsrc 192.168.116.16 tdst 192.168.13.213

    2. Sur le système partym, tapez les commandes ci-dessous :


      # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.1.3.3 10.16.16.6  \
tsrc 192.168.13.213 tdst 192.168.116.16

  15. Protégez le tunnel à l'aide de la stratégie IPsec créée.


    # ipsecconf

  16. Affichez le routeur pour le tunnel.


    # ifconfig ip.tun0 router up

  17. Activez le transfert IP pour l'interface hme1.


    # ifconfig hme1 router

    Le transfert IP signifie que les paquets arrivant peuvent être transférés. Le transfert IP signifie également que les paquets quittant l'interface peuvent provenir d'un autre emplacement. Pour que le transfert de paquet s'effectue sans erreur, vous devez activer le transfert IP à la fois sur l'interface réceptrice et sur l'interface émettrice.

    Comme l'interface hme1 se trouve dans l'intranet, le transfert IP doit être activé pour hme1. Comme ip.tun0 connecte les deux systèmes via Internet, le transfert IP doit être activé pour ip.tun0.

    Le transfert IP de l'interface hme0 est désactivé afin d'éviter toute injection de paquets par un concurrent externe dans l'intranet protégé. Le terme externe fait référence à Internet.

  18. Assurez-vous que les protocoles de routage n'indiquent pas la route par défaut sur l'intranet.


    # ifconfig hme0 private

    Même si le transfert IP de hme0 est désactivé, l'implémentation d'un protocole de routage est susceptible d'annoncer l'interface. Par exemple, le protocole in.routed peut encore annoncer que hme0 est disponible pour transférer des paquets à ses homologues dans l'intranet. Pour éviter ces annonces, définissez l'indicateur private de l'interface.

  19. Ajoutez manuellement une route par défaut à travers hme0.

    La route par défaut doit correspondre à un routeur bénéficiant d'un accès direct à Internet.

    1. Sur le système enigma, ajoutez la route suivante :


      # route add default 192.168.116.4

    2. Sur le système partym, ajoutez la route suivante :


      # route add default 192.168.13.5

      Même si l'interface hme0 ne fait pas partie de l'intranet, hme0 n'a pas besoin de passer par Internet pour atteindre le système homologue. Pour trouver son homologue, hme0 requiert des informations sur le routage Internet. Pour le reste d'Internet, le système VPN apparaît comme étant un hôte, non un routeur. Par conséquent, vous pouvez utiliser un routeur par défaut ou exécuter le protocole de recherche de routeur pour rechercher le système. Pour de plus amples informations, reportez-vous aux pages de manuel route(1M) et in.routed(1M).

  20. Assurez-vous que le VPN démarre à la réinitialisation en ajoutant une entrée au fichier /etc/hostname.ip.tun0.


    system1-point system2-point tsrc system1-taddr tdst system2-taddr router up

    1. Sur le système enigma, ajoutez l'entrée suivante au fichier hostname.ip.tun0 :


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

    2. Sur le système partym, ajoutez l'entrée suivante au fichier hostname.ip.tun0 :


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

  21. Configurez les fichiers d'interface afin de transmettre les paramètres adéquats au démon de routage.

    1. Sur le système enigma, modifiez les fichiers /etc/hostname. interface.


      # cat /etc/hostname.hme0
## enigma
10.16.16.6 private
      		 

      # cat /etc/hostname.hme1
## enigma
192.168.116.16 router

    2. Sur le système partym, modifiez les fichiers /etc/hostname. interface.


      # cat /etc/hostname.hme0
## partym
10.1.3.3 private
      		 

      # cat /etc/hostname.hme1
## partym
192.168.13.213 router

  22. Exécutez un protocole de routage.


    # routeadm -e ipv4-routing
# routeadm -u

    Vous devrez peut-être configurer le protocole de routage avant de l'exécuter. Pour plus d'informations, reportez-vous à la section Protocoles de routage dans Oracle Solaris. La procédure est décrite à la section Configuration d'un routeur IPv4.

Exemple 20–10 Création temporaire des tunnels lors du test

Dans cet exemple, l'administrateur teste la création d'un tunnel sur un système Solaris 10 4/09. Par la suite, l'administrateur utilise la procédure Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4 pour rendre les tunnels permanents. Lors du test, l'administrateur effectue les séries d'actions suivantes sur les systèmes system1 et system2 :

Exemple 20–11 Création d'un tunnel sur un système Solaris de version antérieure en utilisant la ligne de commande

Dans la version Solaris 10 7/07, la syntaxe de la commande ifconfig a été simplifiée. Dans cet exemple, l'administrateur teste la création d'un tunnel sur un système exécutant une version de Solaris antérieure à la version Solaris 10 7/07. À l'aide de la syntaxe d'origine de la commande ifconfig, l'administrateur peut utiliser les mêmes commandes sur les deux systèmes communicants. Ensuite, l'administrateur doit effectuer la procédure de la section Protection d'un VPN à l'aide d'un tunnel IPsec en mode Tunnel sur IPv4 pour rendre les tunnels permanents.

Lors du test, l'administrateur doit effectuer les étapes suivantes sur les systèmes system1 et system2 :

Exemple 20–12 Requête de stratégie IPsec sur tous les systèmes sur un LAN

Dans cet exemple, l'administrateur met en commentaire la stratégie bypass configurée à l'Étape 4, ce qui renforce la protection. Avec cette configuration de stratégie, chaque système du LAN doit activer IPsec afin de communiquer avec le routeur.


# LAN traffic must implement IPsec.
# {laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} ipsec {encr_algs aes encr_auth_algs sha1}
Exemple 20–13 Utilisation d'IPsec pour protéger le trafic Telnet différemment du trafic SMTP

Dans cet exemple, la première règle protège le trafic telnet sur le port 23 avec Blowfish et SHA-1. La deuxième règle protège le trafic SMTP sur le port 25 avec AES et MD5.


{laddr 10.1.3.3 ulp tcp dport 23 dir both} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa unique}
{laddr 10.1.3.3 ulp tcp dport 25 dir both} 
 ipsec {encr_algs aes encr_auth_algs md5 sa unique}
Exemple 20–14 Utilisation d'un tunnel IPsec en mode Tunnel pour protéger un sous-réseau différemment d'un autre trafic réseau

La configuration de tunnel ci-dessous protège l'intégralité du trafic du sous-réseau 10.1.3.0/24 via le tunnel :


{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

Les configurations de tunnel ci-dessous protègent le trafic du sous-réseau 10.1.3.0/24 vers d'autres sous-réseaux via le tunnel. Les sous-réseaux dont le numéro commence par 10.2.x.x traversent le tunnel.


{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.1.0/24} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
 

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.2.0/24} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
 

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.3.0/24} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}