O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este artigo mostrará como configurar o GETVPN para enviar e receber políticas que permitam enviar e receber a Security Group Tag (SGT) inserida em pacotes criptografados. O exemplo envolverá duas filiais que marcaram todo o tráfego com marcas SGT específicas e aplicam políticas de firewall baseado em zona (ZBF - Zone Based Firewall) com base em marcas SGT recebidas.
A Cisco recomenda que você tenha conhecimento destes tópicos:
As informações neste documento são baseadas nestas versões de software:
R3 - roteador de borda em Branch1, membro do grupo GETVPN
R4 - roteador de borda na Filial2, membro do grupo GETVPN
R1,R2 - Servidores de Chave GETVPN no Site Central
OSPF em execução em todos os roteadores
ACL enviada do KS forçando a criptografia para o tráfego entre 10.0.0.0/16 <-> 10.0.0.0/16
O roteador R3 está marcando todo o tráfego enviado de Branch1 com tag SGT = 3
O roteador R4 está marcando todo o tráfego enviado da Filial2 com tag SGT = 4
R3 está removendo as tags SGT ao enviar tráfego para a LAN (supondo que R5 não esteja suportando marcação em linha)
O R4 está removendo tags SGT ao enviar tráfego para a LAN (supondo que o R6 não esteja suportando marcação em linha)
R4 não tem firewall (aceitando todos os pacotes)
R3 está configurado com ZBF com as seguintes políticas:
- aceitar todo o tráfego da LAN para a WAN
- aceitar apenas ICMP marcado com SGT=4 da WAN para a LAN
Para enviar políticas que permitam enviar e receber pacotes marcados, o comando "tac cts sgt" precisa estar presente:
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
A configuração de R2 é muito semelhante.
A configuração de GETVPN é a mesma do cenário sem tags SGT. A interface de LAN foi configurada com confiabilidade manual:
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
Configuração de ZBF em R3:
Todos os pacotes da LAN serão aceitos. Somente da WAN os pacotes ICMP marcados com SGT=4 serão aceitos:
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
A configuração de R4 em Branch2 é muito semelhante, exceto ZBF que não está configurado lá.
R5 e R6 simulam a LAN local em ambas as filiais. Exemplo de configuração para 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
Verificando se a marcação SGT é suportada no membro do grupo em Branch1 (R3):
R3#show crypto gdoi feature cts-sgt
Version Feature Supported
1.0.8 Yes
Verificando se as políticas TEK enviadas para o membro do grupo em Branch1 (R3) estão usando 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
Enviando tráfego ICMP de R6 para 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
Verificando se R3 está anexando a tag SGT a pacotes criptografados:
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...>
Verificando contadores de painel de dados para GETVPN no membro do grupo em 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
Dependendo da plataforma, mais detalhes podem ser revelados usando depurações. Por exemplo em R3:
R3#debug cts platform l2-sgt rx
R3#debug cts platform l2-sgt tx
Os pacotes recebidos por R3 da LAN devem ser marcados com 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]
Além disso, os pacotes criptografados enviados pelo túnel serão marcados:
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
R3 aceitará somente pacotes ICMP marcados com SGT=4 provenientes da WAN. Ao enviar pacotes ICMP de R6 para 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 receberá o pacote ESP marcado, descriptografando-o. Em seguida, o ZBF aceitará o tráfego:
*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
Além disso, o mapa de políticas apresentará aos contadores os números de pacotes aceitos:
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
Ao tentar executar telnet de R6 para R5 - isso será descartado por R3 porque telnet não foi permitido:
*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