802.1Q para gerenciamento GOST L2VPN ou como economizar dinheiro em atualizações de software





Situação



Eu tenho que abrir uma conexão VPN entre dois sites na rede. Na sala do servidor, ao que parece, havia gateways de segurança C-Terra Gateway versão 4.2. O esquema é simples. O fornecedor até postou um script de configuração recomendado. Mas ... o script do fornecedor usa três interfaces de rede e meus gateways têm apenas duas.



Eu faço café, lembro do meu CCNA e tento usar o que tenho - portas livres em switches gerenciados.



Minha rede



Minha rede é composta por dois sites separados geograficamente em um domínio de transmissão. Endereço: 10.10.205.0/24:







Em mãos de dois gateways de segurança C-Terra Gateway versão 4.2 com pacote C-Terra L2.

Sobre o



pacote C-Terra L2 O pacote permite mudar uma ou mais interfaces de gateway para o modo PROMISC. A interface PROMISC intercepta frames de enlace de dados, e C-Terra L2 os encapsula em UDP.

Em seguida, os pacotes UDP são criptografados (encapsulados no ESP). Isso cria uma conexão VPN L2 sobre L3. C-Terra L2 vem pré-instalado em todos os gateways de segurança e é ativado com uma licença separada.


No cenário recomendado, os gateways de segurança estão localizados na extremidade da rede e uma interface separada é alocada para gerenciamento:







Para facilitar a descrição das interfaces:



  • Gi0 / 0 - interfaces PROMISC;
  • Gi0 / 1 - interfaces WAN L3;
  • Gi0 / 2 - interfaces de gerenciamento dedicadas. Eu entendo que tenho que gerenciar o segundo gateway de segurança por meio do túnel VPN.


Decisão



A primeira caneca de café acabou enquanto eu lia no Habré sobre o 802.1Q - me lembrei do CCNA. A segunda caneca esfriou (vou aquecê-la no micro-ondas) durante a troca do equipamento, conforme mostrado na figura:







Distingo três tipos de tráfego:



  • Tráfego principal entre os dispositivos R1 e R2. Vou designá-lo como BULK DATA e colocá-lo na VLAN 205. BULK DATA deve ser criptografado antes da transmissão entre sites;
  • Tráfego de gerenciamento de gateway - MGMT. Vou levá-lo para a VLAN 10. O tráfego MGMT para o gateway no site remoto deve ser criptografado;
  • BULK DATA e MGMT após a criptografia irei designar como ESP DATA e colocá-lo na VLAN 100.


De acordo com minhas estimativas, a transmissão BULK DATA / ESP DATA na rede será semelhante a esta (as linhas verdes representam o tráfego não criptografado, vermelho - tráfego criptografado):







Transmissão MGMT para controle de gateway no site local:







Transmissão MGMT / ESP DATA para controle de gateway no site remoto:







5 etapas de configuração



Etapa 1. Lidando com BULK DATA



Eu seleciono uma VLAN 205 separada para BULK DATA. Para isso, eu defino a interface Gi0 / 2 dos dispositivos SW1 e SW2 para o modo de acesso com VLAN 205:



sw1(config)#
interface gi0/2
    description BULK_TO_R1
    switchport access vlan 205
    no shutdown

sw2(config)#
interface gi0/2
  description BULK_TO_R2
  switchport access vlan 205
  no shutdown


Eu faço as interfaces Gi0 / 0 dos gateways GW1 e GW2 PROMISC interfaces. Para passar BULK DATA para a interface PROMISC, eu configuro o tronco para a interface PROMISC:



sw1(config)#
interface gi0/0
  description LINK_TO_PROMISC_GW1
  switchport mode trunk
  switchport trunk allowed vlan 205
  switchport trunk encapsulation dot1q
  no shutdown

sw2(config)#
interface gi0/0
  description LINK_TO_PROMISC_GW2
  switchport mode trunk
  switchport trunk allowed vlan 205
  switchport trunk encapsulation dot1q
  no shutdown






Etapa 2. Lidando com o MGMT local



De acordo com o plano, o tráfego MGMT transporta a VLAN 10. Espaço de endereço para a VLAN 10: 10.76.76.128/28.



No dispositivo SW1 e SW2, crio interfaces virtuais vlan10:



sw1(config)#
interface vlan10
  ip address 10.76.76.129 255.255.255.240
  no shutdown 

sw2(config)#
interface vlan10
  ip address 10.76.76.142 255.255.255.240
  no shutdown


Eu crio a VLAN 10 VLAN nativa para não configurar interfaces 802.1Q no gateway:



sw1(config)#
interface gi0/1
  description LINK_TO_WAN_GW1
  switchport mode trunk
  switchport trunk allowed vlan 10
  switchport trunk native vlan 10
  switchport trunk encapsulation dot1q
  no shutdown

sw2(config)#
interface gi0/1
  description LINK_TO_WAN_GW2
  switchport mode trunk
  switchport trunk allowed vlan 10
  switchport trunk native vlan 10
  switchport trunk encapsulation dot1q
  no shutdown






Eu configuro as interfaces Gi0 / 1 dos gateways de segurança:



GW1(config)#
interface gi0/1
   ip address 10.76.76.137 255.255.255.240
   no shutdown

GW2(config)#
interface gi0/1
  ip address 10.76.76.138 255.255.255.240
  no shutdown


Agora GW1 está disponível via SSH a partir do dispositivo SW1:



sw1#ssh –l root 10.76.76.137
Password:
S-Terra Gate 4.2.18201 (amd64)
root@GW1~#


Da mesma forma, GW2 pode ser acessado via SSH a partir do dispositivo SW2:



sw2#ssh –l root 10.76.76.138
Password:
S-Terra Gate 4.2.18201 (amd64)
root@GW2~#


Legal, servi outra xícara de café.



Etapa 3. Lidando com o MGMT para o gateway no site remoto O



tráfego MGMT para o gateway no site remoto deve ser criptografado. Para fazer isso, vou lançar a VLAN 10 por meio da VPN. Todo o tráfego interceptado da interface PROMISC entrará no túnel VPN. Vou adicionar ao tronco para a interface PROMISC VLAN 10:



sw1(config)#
interface gi0/0
  description LINK_TO_PROMISC_GW1  
  switchport trunk allowed vlan 10, 205

sw2(config)#
interface gi0/0
  description LINK_TO_PROMISC_GW1  
  switchport trunk allowed vlan 10, 205


Não perca meia hora solucionando problemas!



A interface PROMISC não deve obter ESP DATA, por isso é importante excluir a VLAN 100 dos troncos LINK_TO_PROMISC_GW1 e LINK_TO_PROMISC_GW2 nas seguintes opções:



switchport trunk allowed vlan 1-99,101-4096


Etapa 4. Cheguei ao ESP DATA



, selecionei ESP DATA na VLAN 100 nos gateways GW1 e GW2. Espaço de endereço para VLAN 100: 192.168.10.0/30



Para fazer isso, na interface WAN Gi0 / 1 dos gateways GW1 e GW2, crio uma interface 802.1Q Gi0 / 1.100.

O tráfego de saída dessa interface pertencerá à VLAN 100:



GW1(config)#
interface gi0/1.100
   ip address 192.168.10.1 255.255.255.252
   no shutdown

GW2(config)#
interface gi0/1.100
  ip address 192.168.10.2 255.255.255.252
  no shutdown






Eu permito a passagem da VLAN 100 para o tronco LINK_TO_WAN_GW1 e LINK_TO_WAN_GW2:



sw1(config)#
interface gi0/1
  description LINK_TO_WAN_GW1
  switchport trunk allowed vlan 10,100

sw2(config)#
interface gi0/1
  description LINK_TO_WAN_GW2
  switchport trunk allowed vlan 10,100


O link entre os dispositivos SW1 e SW2 também deve transmitir o tráfego VLAN 100 marcado:



sw1(config)#
interface gi0/3
  description LINK_TO_SW2
  switchport mode trunk
  switchport trunk allowed vlan 100
  switchport trunk encapsulation dot1q
  no shutdown

sw2(config)#
interface gi0/3
  description LINK_TO_SW1
  switchport mode trunk
  switchport trunk allowed vlan 100
  switchport trunk encapsulation dot1q
  no shutdown


Passo 5. Configurando C-Terra L2 e VPN IPsec com GOST



C-Terra L2 é configurado no sistema operacional usando o arquivo de configuração /opt/VPNagent/etc/l2.conf. Para GW1:



vif tap0
bridge br0
capture eth0
remote 192.168.10.2
mssfix 1400
passtos


onde:



capture eth0 - selecione a interface PROMISC, remote 192.168.10.2 - endereço IP do peer IPsec (interface Gi0 / 1.100 do gateway GW2).



Para GW2:



vif tap0
bridge br0
capture eth0
remote 192.168.10.1
mssfix 1400
passtos


Configurando parâmetros IKE / IPsec. Para GW1: os

gateways usarão nomes de host como identificadores, defina uma chave predefinida para autenticação (as Regras de Uso para autenticação precisam usar certificados digitais, vou alterá-los mais tarde):



GW1(config)#
crypto isakmp identity hostname
ip host GW2 192.168.10.2
crypto isakmp key KEY hostname GW2


Configurando os parâmetros de detecção de ponto morto (DPD):



GW1(config)#
crypto isakmp keepalive 10 2
crypto isakmp keepalive retry-count 5


Eu defino os parâmetros IPsec Fase I:



GW1(config)#
crypto isakmp policy 1
  encr gost
  hash gost3411-256-tc26
  auth pre-share
  group vko2


Eu defino os parâmetros IPsec Fase II:



GW1(config)#
crypto ipsec transform-set TSET esp-gost28147-4m-imit
   mode tunnel


Como os quadros interceptados pela interface PROMISC L2 são encapsulados em UDP, a lista de acesso que define o tráfego para criptografia:



GW1(config)#
ip access-list extended LIST
   permit udp host 192.168.10.1 host 192.168.10.2


Eu crio um mapa criptográfico e o vinculo a Gi0 / 1.100:



GW1(config)#
crypto map CMAP 1 ipsec-isakmp
  match address LIST
  set transform-set TSET
  set peer 192.168.10.2
interface gi0/1.100
  crypto map CMAP


Eu especifico a rota padrão por meio do endereço IP do par IPsec:



GW1(config)#
ip route 0.0.0.0 0.0.0.0 192.168.10.2 	


Configuração do gateway GW2:



GW2(config)#
crypto isakmp identity hostname
ip host GW1 192.168.10.1
crypto isakmp key KEY hostname GW1
crypto isakmp keepalive 10 2
crypto isakmp keepalive retry-count 5
crypto isakmp policy 1
  encr gost
  hash gost3411-256-tc26
  auth pre-share
  group vko2
crypto ipsec transform-set TSET esp-gost28147-4m-imit
  mode tunnel
ip access-list extended LIST
  permit udp host 192.168.10.2 host 192.168.10.1
crypto map CMAP 1 ipsec-isakmp
  match address LIST
  set transform-set TSET
  set peer 192.168.10.1
interface gi0/1.100
  crypto map CMAP
ip route 0.0.0.0 0.0.0.0 192.168.10.1


Aconteceu?



Do dispositivo R1, faço ping para R2:



R1#ping 10.10.205.2 
Type escape sequence to abort. 

Sending 5, 100-byte ICMP Echos to 10.10.205.2, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms</code>

R2   ICMP.  ?  ARP   R1  R2:

<source>R1#show arp 
Protocol  Address          Age (min)  Hardware Addr   Type   Interface 
Internet  10.10.205.1             -   aabb.cc00.5020  ARPA   GigabitEthernet0/2 
Internet  10.10.205.2            54   aabb.cc00.6020  ARPA   GigabitEthernet0/2

R2#show arp 
Protocol  Address          Age (min)  Hardware Addr   Type   Interface 
Internet  10.10.205.1            52   aabb.cc00.5020  ARPA   GigabitEthernet0/2 
Internet  10.10.205.2             -   aabb.cc00.6020  ARPA   GigabitEthernet0/2


Os dispositivos R1 e R2 presumem que estão na mesma sub-rede de broadcast.



Os dispositivos SW1 e SW2 consideram que estão conectados um ao outro por dois links:



sw1#show cdp neighbors
Device ID    Local Intrfce   Holdtme     Capability  Platform  Port ID 
sw2          Gi0/0           146             R S I  Linux Uni Gi0/0 
sw2          Gi0/3           146             R S I  Linux Uni Gi0/3 
R1           Gi0/2           156              R B   Linux Uni Gi0/2

sw2#show cdp neighbors
Device ID    Local Intrfce   Holdtme     Capability  Platform  Port ID 
sw1          Gi0/0           140             R S I  Linux Uni Gi0/0 
sw1          Gi0/3           140             R S I  Linux Uni Gi0/3 
R2           Gi0/2           156              R B   Linux Uni Gi0/2


Tentando conectar ao GW2 via SSH do dispositivo SW1:



sw1#ssh –l root 10.76.76.138
Password:
S-Terra Gate 4.2.18201 (amd64)
root@GW2~#


Conclusão: os sites 1 e 2 estão ligados de forma transparente em um único domínio de broadcast. Vou verificar se o canal tem criptografia:



estatísticas do túnel IPsec no dispositivo GW1:



root@GW1:~# sa_mgr show 
ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections: 
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd 
1 2 (192.168.10.1,500)-(192.168.10.2,500) active 31378 31502

IPsec connections: 
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd 
1 2 (192.168.10.1,*)-(192.168.10.2,*) 17 ESP tunn 508224 27672


Um túnel IPsec foi estabelecido entre 192.168.10.1 e 192.168.10.2.



Verifiquei se apenas o tráfego ESP é transmitido entre os dispositivos SW1 e SW2, sem contar o STP. Aqui está um despejo de tráfego da interface gi0 / 3 de SW1:







Eventualmente



Bebi três xícaras de café - depois não dormi a noite toda, mas não precisei comprar novo hardware e atualizar. Talvez tenha valido a pena, na versão 4.3 o fornecedor trouxe à mente o L2. Estou pensando em pegar a versão 4.3 para teste.



Engenheiro anônimo

t.me/anonimous_engineer



All Articles