Exemple de configuration de GETVPN avec marquage en ligne TrustSec SGT et pare-feu basé sur une zone sensible aux balises SGT

Options de téléchargement

  • PDF     (279.9 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (119.5 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (112.2 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:17 novembre 2015
ID du document:200257

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Introduction

Cet article explique comment configurer GETVPN pour qu'il pousse les stratégies permettant l'envoi et la réception de l'étiquette de groupe de sécurité (SGT) insérée dans des paquets chiffrés. Par exemple, deux filiales marquent tout le trafic avec des balises SGT spécifiques et appliquent des stratégies ZBF (Zone Based Firewall) basées sur les balises SGT reçues.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

  • Connaissance de base de la configuration de l’interface de ligne de commande (CLI) IOS et de la configuration GETVPN
  • Connaissance de base des services Trustsec.
  • Connaissance de base du pare-feu basé sur les zones

Components Used

Les informations contenues dans ce document sont basées sur les versions de logiciel suivantes :

  • Routeur Cisco 2921 avec logiciel 15.3(2)T et ultérieur

Topologie

R3 - routeur périphérique dans Branch1, membre du groupe GETVPN

R4 - routeur périphérique dans Branch2, membre du groupe GETVPN

R1, R2 - Serveurs clés GETVPN sur le site central

OSPF exécuté sur tous les routeurs

Liste de contrôle d’accès envoyée de KS forçant le chiffrement pour le trafic entre 10.0.0.0/16 <-> 10.0.0.0/16

Le routeur R3 marque tout le trafic envoyé par Branch1 avec une balise SGT = 3

Le routeur R4 marque tout le trafic envoyé par Branch2 avec une balise SGT = 4

R3 supprime les balises SGT lors de l'envoi du trafic vers le LAN (en supposant que R5 ne prend pas en charge le balisage en ligne)

R4 supprime les balises SGT lors de l'envoi du trafic vers le LAN (en supposant que R6 ne prend pas en charge le balisage en ligne)

R4 ne dispose pas de pare-feu (acceptation de tous les paquets)

R3 est configuré avec ZBF avec les stratégies suivantes :

- accepter tout le trafic du LAN vers le WAN

- accepter uniquement le protocole ICMP balisé avec SGT=4 du WAN vers le LAN

Configuration

R1 (serveur de clés dans le site central)

Pour envoyer des stratégies permettant d'envoyer et de recevoir des paquets balisés, la commande tac cts sgt doit être présente :

interface Loopback0
 ip address 10.0.1.1 255.255.255.0
!
interface Ethernet0/0
 ip address 192.168.0.1 255.255.255.0

crypto ipsec transform-set TS esp-aes esp-sha256-hmac 
 mode tunnel
!
crypto ipsec profile prof1
 set transform-set TS 
!
crypto gdoi group group1
 identity number 1
 server local
  rekey authentication mypubkey rsa GETKEY
  rekey transport unicast
  sa ipsec 1
   profile prof1
   match address ipv4 GET-IPV4
   replay counter window-size 64
   tag cts sgt
  address ipv4 192.168.0.1
  redundancy
   local priority 100
   peer address ipv4 192.168.0.2

router ospf 1
 network 10.0.0.0 0.0.255.255 area 0
 network 192.168.0.0 0.0.0.255 area 0

ip access-list extended GET-IPV4
 permit icmp 10.0.0.0 0.0.255.255 10.0.0.0 0.0.255.255

La configuration de R2 est très similaire.

R3 (membre de groupe dans Branch1)

La configuration GETVPN est la même que pour le scénario sans balises SGT. L'interface LAN a été configurée avec une fiabilité manuelle :

  • « policy static sgt 3 trust » - étiquette tous les paquets reçus du LAN à l'aide de SGT=3
  • « no propagate sgt » : supprime toutes les balises SGT lors de la transmission des paquets vers le LAN.
crypto gdoi group group1
 identity number 1
 server address ipv4 192.168.0.1
 server address ipv4 192.168.0.2
!
!
crypto map cmap 10 gdoi 
 set group group1

interface Ethernet0/0
 ip address 192.168.0.3 255.255.255.0
 crypto map cmap
!
interface Ethernet0/1
 ip address 10.0.3.1 255.255.255.0
cts manual 
   no propagate sgt
   policy static sgt 3 trusted

router ospf 1
 network 10.0.0.0 0.0.255.255 area 0
 network 192.168.0.0 0.0.0.255 area 0

Configuration ZBF sur R3 :

Tous les paquets du réseau local seront acceptés. À partir du WAN, seuls les paquets ICMP balisés avec SGT=4 seront acceptés :

class-map type inspect match-all TAG_4_ICMP
match security-group source tag 4
 match protocol icmp
!
policy-map type inspect FROM_LAN
 class class-default
  pass log
policy-map type inspect FROM_WAN
 class type inspect TAG_4_ICMP
  pass log
 class class-default
  drop log
!
zone security lan
zone security wan
zone-pair security WAN-LAN source wan destination lan
 service-policy type inspect FROM_WAN
zone-pair security LAN-WAN source lan destination wan
 service-policy type inspect FROM_LAN

interface Ethernet0/0
 zone-member security wan
!
interface Ethernet0/1
 zone-member security lan

R4 dans la configuration de Branch2 est très similaire, sauf ZBF qui n'y est pas configuré.

Configuration de R5 et R6

R5 et R6 simulent le LAN local dans les deux filiales. Exemple de configuration pour R5 :

interface Ethernet0/0
 ip address 10.0.3.10 255.255.255.0
router ospf 1
 network 10.0.0.0 0.0.255.255 area 0

Vérification

Testez GETVPN sensible aux balises SGT

Vérification de la prise en charge du marquage SGT sur le membre de groupe dans Branch1 (R3) :

R3#show crypto gdoi feature cts-sgt 
       Version    Feature Supported
        1.0.8           Yes

Vérifier si les stratégies TEK poussées vers un membre de groupe dans Branch1 (R3) utilisent SGT :

R3#show crypto gdoi          
GROUP INFORMATION

<...some output ommited for clarity...>

TEK POLICY for the current KS-Policy ACEs Downloaded:
  Ethernet0/0:
    IPsec SA:
        spi: 0xD100D58E(3506492814)
        transform: esp-aes esp-sha256-hmac 
        sa timing:remaining key lifetime (sec): expired
        Anti-Replay(Counter Based) : 64
        tag method : cts sgt
        alg key size: 16 (bytes)
        sig key size: 32 (bytes)
        encaps: ENCAPS_TUNNEL

    IPsec SA:
        spi: 0x52B3CA86(1387514502)
        transform: esp-aes esp-sha256-hmac 
        sa timing:remaining key lifetime (sec): (1537)
        Anti-Replay(Counter Based) : 64
        tag method : cts sgt
        alg key size: 16 (bytes)
        sig key size: 32 (bytes)
        encaps: ENCAPS_TUNNEL

Envoi du trafic ICMP de R6 à R5 :

R6#ping 10.0.3.10 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.0.3.10, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 1/1/6 ms

Vérification de l'attachement de la balise SGT à des paquets chiffrés par R3 :

R3#show crypto ipsec sa detail 

interface: Ethernet0/0
    Crypto map tag: cmap, local addr 192.168.0.3

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (10.0.0.0/255.255.0.0/1/0)
   remote ident (addr/mask/prot/port): (10.0.0.0/255.255.0.0/1/0)
   Group: group1
   current_peer 0.0.0.0 port 848
     PERMIT, flags={}
    #pkts encaps: 39, #pkts encrypt: 39, #pkts digest: 39
    #pkts decaps: 39, #pkts decrypt: 39, #pkts verify: 39
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #pkts no sa (send) 0, #pkts invalid sa (rcv) 0
    #pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
    #pkts invalid prot (recv) 0, #pkts verify failed: 0
    #pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
    #pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
    ##pkts replay failed (rcv): 0
    #pkts tagged (send): 39, #pkts untagged (rcv): 39

    <...some output ommited for clarity...>

Vérification des compteurs du plan de données pour GETVPN sur le membre de groupe dans Branch2 (R3) :

R3#show crypto gdoi gm dataplane counters 

Data-plane statistics for group group1:
    #pkts encrypt            : 53       #pkts decrypt            : 53   
    #pkts tagged (send)      : 53       #pkts untagged (rcv)     : 53   
    #pkts no sa (send)       : 0        #pkts invalid sa (rcv)   : 0    
    #pkts encaps fail (send) : 0        #pkts decap fail (rcv)   : 0    
    #pkts invalid prot (rcv) : 0        #pkts verify fail (rcv)  : 0    
    #pkts not tagged (send)  : 0        #pkts not untagged (rcv) : 0    
    #pkts internal err (send): 0        #pkts internal err (rcv) : 0    

Selon la plate-forme, plus de détails peuvent être révélés à l'aide de débogages. Par exemple sur R3 :

R3#debug cts platform l2-sgt rx 
R3#debug cts platform l2-sgt tx

Les paquets reçus par R3 à partir du LAN doivent être étiquetés SGT :

01:48:08: cts-l2sgt_rx:l2cts-policysgt:[in=Ethernet0/1 src=0100.5e00.0005 dst=aabb.cc00.6800] Policy SGT Assign [pak=F1B00E00:flag=0x1:psgt=3]

Les paquets chiffrés envoyés via le tunnel sont également étiquetés :

01:49:28: cts_ether_cmd_handle_post_encap_feature:pak[36BF868]:size=106 in=Ethernet0/1 out=Ethernet0/0 enctype=1 encsize=0 sgt_offset=18 [adj]:idb=Ethernet0/0 is_dot1q=0 linktype=7 mac_length=22 SGT=3

Test de ZBF sensible aux balises SGT

R3 accepte uniquement les paquets ICMP balisés avec SGT=4 provenant du WAN. Lors de l’envoi de paquets ICMP de R6 à R5 :

R6#ping 10.0.3.10 repeat 11
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.3.10, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/6 ms

R3 recevra un paquet ESP étiqueté, puis le décryptera. ZBF acceptera ensuite le trafic :

*Mar 17 12:45:28.039: %FW-6-PASS_PKT: (target:class)-(WAN-LAN:TAG_4_ICMP) Passing icmp pkt 10.0.4.10:0 => 10.0.3.10:0 with ip ident 57

La carte de stratégie présente également les compteurs avec le nombre de paquets acceptés :

R3#show policy-firewall stats all
Global Stats:
        Session creations since subsystem startup or last reset 0
        Current session counts (estab/half-open/terminating) [0:0:0]
        Maxever session counts (estab/half-open/terminating) [0:0:0]
        Last session created never
        Last statistic reset never
        Last session creation rate 0
        Maxever session creation rate 0
        Last half-open session total 0

policy exists on zp WAN-LAN
  Zone-pair: WAN-LAN 

  Service-policy inspect : FROM_WAN

    Class-map: TAG_4_ICMP (match-all)  
      Match: security-group source tag 4
      Match: protocol icmp
      Pass
        18 packets, 1440 bytes

    Class-map: class-default (match-any)  
      Match: any 
      Drop
        3 packets, 72 bytes

policy exists on zp LAN-WAN
  Zone-pair: LAN-WAN 

  Service-policy inspect : FROM_LAN

    Class-map: class-default (match-any)  
      Match: any 
      Pass
        18 packets, 1440 bytes

Lors de la tentative de connexion Telnet de R6 à R5, cette opération sera abandonnée par R3 car telnet n’était pas autorisé :

*Mar 17 12:49:30.475: %FW-6-DROP_PKT: Dropping tcp session 10.0.4.10:37500 10.0.3.10:23 on zone-pair WAN-LAN class class-default due to  DROP action found in policy-map with ip ident 36123

Références

TAC Authored

Contribution d’experts de Cisco

  • Michal Garcarz
    Ingénieur TAC Cisco

Ce document vous est-il utile?

FeedbackCommentaires

Contacter Cisco

Ce document s’applique à ces produits