Neste artigo, gostaria de apresentar um guia passo a passo sobre como implantar rapidamente a arquitetura mais escalável até o momento. VPN de Acesso Remoto de acesso baseado em AnyConnect e Cisco ASA – Cluster de Balanceamento de Carga VPN.
Introdução: Muitas empresas em todo o mundo, devido à atual situação com a COVID-19, estão fazendo esforços para transferir seus funcionários para o trabalho remoto. Devido à grande quantidade de transições para o trabalho remoto, a carga sobre os gateways VPN existentes das empresas aumenta significativamente, sendo necessária uma escalabilidade rápida. Por outro lado, muitas empresas se veem forçadas a aprender às pressas um conceito como o trabalho remoto.
Para ajudar as empresas a implementar rapidamente uma solução de acesso VPN conveniente, segura e escalável para seus funcionários, a Cisco oferece licenças por até 13 semanas para o cliente multifuncional SSL-VPN AnyConnect. .
.
Preparei um guia passo a passo para uma opção simples de implantação de um cluster de balanceamento de carga VPN como a tecnologia de VPN mais escalável.
O exemplo abaixo será bastante simples em termos dos algoritmos de autenticação e autorização aplicados, mas será uma boa opção para um rápido início (do que muitos estão precisando atualmente), com a possibilidade de ajustes mais profundos conforme necessário durante a implantação.
Resumo: A tecnologia Cluster de Balanceamento de Carga VPN não é failover nem uma função de clusterização em seu entendimento nativo; essa tecnologia pode combinar modelos totalmente diferentes de ASA (com certas limitações) para balancear a carga de conexões VPN de Acesso Remoto. A sincronização de sessões e configurações entre os nós desse cluster não existe, mas é possível realizar o balanceamento automático da carga de conexões VPN e garantir a continuidade das conexões VPN enquanto pelo menos um nó ativo permanecer no cluster. A carga no cluster é balanceada automaticamente com base na utilização dos nós pelo número de sessões VPN.
Para a alta disponibilidade de nós específicos do cluster (se necessário), pode-se utilizar um file server, assim, a conexão ativa será processada pelo nó primário do file server. O file server não é um requisito necessário para garantir a alta disponibilidade dentro do cluster de balanceamento de carga, pois o próprio cluster, em caso de falha de um nó, transferirá a sessão do usuário para outro nó ativo, no entanto, sem manter o status da conexão, que é precisamente garantido pelo file server. Assim, é possível combinar essas duas tecnologias, se necessário.
Um cluster de VPN Load-Balancing pode conter mais de dois nós.
O cluster de VPN Load-Balancing é suportado em ASA 5512-X e superiores.
Uma vez que cada ASA dentro do cluster de VPN Load-Balancing é uma unidade independente em termos de configurações realizadas, todos os passos de configuração serão realizados individualmente em cada dispositivo.
Topologia lógica do exemplo fornecido:
Implantação inicial:
Implantamos instâncias ASAv a partir da imagem dos templates necessários (ASAv5/10/30/50).
Atribuímos interfaces INSIDE/OUTSIDE a VLANs iguais (Outside em sua própria VLAN, INSIDE em sua própria VLAN, mas comum dentro do cluster – veja a topologia), sendo importante que as interfaces do mesmo tipo estejam no mesmo segmento L2.
Licenças:
- No momento da instalação, o ASAv não terá nenhuma licença e estará limitado a um desempenho de 100 kbit/s.
- Para instalar a licença, você precisará gerar um token em sua conta Smart-Account: -> Licenciamento de Software Inteligente
- Na janela que se abrir, clique no botão Novo Token
- Certifique-se de que o campo ativo e a caixa de seleção Permitir funcionalidade controlada por exportação… Sem este campo ativo, você não poderá usar as funções de criptografia forte e, consequentemente, VPN. Se este campo não estiver ativo, entre em contato com sua equipe de conta para solicitar a ativação.
- Após clicar no botão Criar Token, um token será criado, que usaremos para obter a licença para o ASAv, vamos copiá-lo:
- Repetiremos os passos C, D, E para cada ASAv implantado.
- Para facilitar a cópia do token, vamos permitir temporariamente o telnet. Vamos configurar cada ASA (o exemplo abaixo ilustra as configurações na ASA-1). O telnet com o outside não funciona; se for realmente necessário, mude o nível de segurança para 100 no outside e depois retorne.
! ciscoasa(config)# int gi0/0 ciscoasa(config)# nameif outside ciscoasa(config)# ip address 192.168.31.30 255.255.255.0 ciscoasa(config)# no shut ! ciscoasa(config)# int gi0/1 ciscoasa(config)# nameif inside ciscoasa(config)# ip address 192.168.255.2 255.255.255.0 ciscoasa(config)# no shut ! ciscoasa(config)# telnet 0 0 inside ciscoasa(config)# username admin password cisco priv 15 ciscoasa(config)# ena password cisco ciscoasa(config)# aaa authentication telnet console LOCAL ! ciscoasa(config)# route outside 0 0 192.168.31.1 ! ciscoasa(config)# wr !- Para registrar o token na nuvem Smart-Account, é necessário fornecer acesso à Internet para o ASA. .
Em resumo, o ASA é necessário para:
- acesso via HTTPS à Internet;
- sincronização de tempo (preferencialmente via NTP);
- servidor DNS configurado;
- Conecte-se via telnet ao nosso ASA e faça as configurações necessárias para ativar a licença através do Smart-Account.
! ciscoasa(config)# clock set 19:21:00 Mar 18 2020 ciscoasa(config)# clock timezone MSK 3 ciscoasa(config)# ntp server 192.168.99.136 ! ciscoasa(config)# dns domain-lookup outside ciscoasa(config)# DNS server-group DefaultDNS ciscoasa(config-dns-server-group)# name-server 192.168.99.132 ! ! Vamos verificar a funcionalidade do DNS: ! ciscoasa(config-dns-server-group)# ping ya.ru Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 87.250.250.242, timeout is 2 seconds: !!!!! ! ! Vamos verificar a sincronização NTP: ! ciscoasa(config)# show ntp associations address ref clock st when poll reach delay offset disp *~192.168.99.136 91.189.94.4 3 63 64 1 36.7 1.85 17.5 * master (sincronizado), # master (não sincronizado), + selecionado, - candidato, ~ configurado ! ! Vamos configurar nosso ASAv para Smart-Licensing (de acordo com seu perfil, no meu caso 100M como exemplo) ! ciscoasa(config)# license smart ciscoasa(config-smart-lic)# feature tier standard ciscoasa(config-smart-lic)# throughput level 100M ! ! Se necessário, pode-se configurar o acesso à Internet através de um proxy; utilize o seguinte bloco de comandos: !call-home ! http-proxy ip_address port port ! ! Em seguida, inserimos o token copiado do portal Smart-Account (<token>) e registramos a licença ! ciscoasa(config)# end ciscoasa# license smart register idtoken <token>- Verificamos se o dispositivo registrou a licença com sucesso e se as opções de criptografia estão disponíveis:
Configurando o SSL-VPN básico em cada gateway
- Em seguida, configuramos o acesso via SSH e ASDM:
ciscoasa(config)# ssh ver 2 ciscoasa(config)# aaa authentication ssh console LOCAL ciscoasa(config)# aaa authentication http console LOCAL ciscoasa(config)# hostname vpn-demo-1 vpn-demo-1(config)# domain-name ashes.cc vpn-demo-1(config)# cry key gen rsa general-keys modulus 4096 vpn-demo-1(config)# ssh 0 0 inside vpn-demo-1(config)# http 0 0 inside ! ! Vamos iniciar o servidor HTTPS para ASDM na porta 445 para não haver conflito com o portal SSL-VPN ! vpn-demo-1(config)# http server enable 445 !- Para usar o ASDM, primeiro é preciso baixá-lo do site cisco.com; no meu caso, este é o seguinte arquivo:
- Para que o cliente AnyConnect funcione, é necessário carregar em cada ASA a imagem para cada sistema operacional de desktop a ser utilizado (Linux/Windows/MAC) e um arquivo com Pacote de Implantação do Headend no nome:
- Os arquivos baixados podem ser disponibilizados, por exemplo, em um servidor FTP e transferidos para cada ASA individual:
- Configuramos o ASDM e o certificado Self-Signed para SSL-VPN (em produção, é recomendável usar um certificado confiável). O FQDN configurado para o endereço virtual do cluster (vpn-demo.ashes.cc), assim como cada FQDN associado ao endereço externo de cada nó do cluster, deve ser resolvido na zona externa do DNS para o endereço IP da interface OUTSIDE (ou no endereço mapeado, se estiver utilizando a redirecionamento da porta udp/443 (DTLS) e tcp/443(TLS)). Informações detalhadas sobre os requisitos do certificado estão na seção Verificação do Certificado documentação.
! vpn-demo-1(config)# crypto ca trustpoint SELF vpn-demo-1(config-ca-trustpoint)# enrollment self vpn-demo-1(config-ca-trustpoint)# fqdn vpn-demo.ashes.cc vpn-demo-1(config-ca-trustpoint)# subject-name cn=*.ashes.cc, ou=ashes-lab, o=ashes, c=ru vpn-demo-1(config-ca-trustpoint)# serial-number vpn-demo-1(config-ca-trustpoint)# crl configure vpn-demo-1(config-ca-crl)# cry ca enroll SELF % O nome de domínio totalmente qualificado no certificado será: vpn-demo.ashes.cc Gerar Certificado Autoassinado? [yes/no]: yes vpn-demo-1(config)# ! vpn-demo-1(config)# sh cry ca certificates Certificado Status: Disponível Número de Série do Certificado: 4d43725e Uso do Certificado: Uso Geral Tipo de Chave Pública: RSA (4096 bits) Algoritmo de Assinatura: SHA256 com Criptografia RSA Nome do Emitente: serialNumber=9A439T02F95 hostname=vpn-demo.ashes.cc cn=*.ashes.cc ou=ashes-lab o=ashes c=ru Nome do Assunto: serialNumber=9A439T02F95 hostname=vpn-demo.ashes.cc cn=*.ashes.cc ou=ashes-lab o=ashes c=ru Data de Validade: data de início: 00:16:17 MSK Mar 19 2020 data de término: 00:16:17 MSK Mar 17 2030 Armazenamento: config Pontos de Confiança Associados: SELF Certificado CA Status: Disponível Número de Série do Certificado: 0509 Uso do Certificado: Uso Geral Tipo de Chave Pública: RSA (4096 bits) Algoritmo de Assinatura: SHA1 com Criptografia RSA Nome do Emitente: cn=QuoVadis Root CA 2 o=QuoVadis Limited c=BM Nome do Assunto: cn=QuoVadis Root CA 2 o=QuoVadis Limited c=BM Data de Validade: data de início: 21:27:00 MSK Nov 24 2006 data de término: 21:23:33 MSK Nov 24 2031 Armazenamento: config Pontos de Confiança Associados: _SmartCallHome_ServerCA- Para verificar o funcionamento do ASDM, não esqueça de indicar a porta, por exemplo:
- Vamos realizar as configurações básicas do túnel:
- Tornaremos a rede corporativa acessível através do túnel, enquanto o acesso à internet será feito diretamente (não é o método mais seguro na ausência de medidas de proteção no host conectado, podendo ocorrer infiltração através de um host infectado e vazamento de dados corporativos, a opção split-tunnel-policy tunnelall irá direcionar todo o tráfego do host para o túnel. No entanto, Split-Tunnel oferece a possibilidade de aliviar o gateway VPN e não processar o tráfego da internet do host)
- Vamos atribuir aos hosts no túnel endereços da sub-rede 192.168.20.0/24 (pool de 10 a 30 endereços (para o nó #1)). Em cada nó do cluster VPN, o pool deve ser específico.
- Faremos autenticação básica com um usuário criado localmente no ASA (não é recomendado fazer isso, é o método mais simples), o ideal é realizar a autenticação através de LDAP/RADIUS, e ainda melhor vincular Autenticação de Múltiplos Fatores (MFA), por exemplo Cisco DUO.
! vpn-demo-1(config)# ip local pool vpn-pool 192.168.20.10-192.168.20.30 mask 255.255.255.0 ! vpn-demo-1(config)# access-list split-tunnel standard permit 192.168.0.0 255.255.0.0 ! vpn-demo-1(config)# group-policy SSL-VPN-GROUP-POLICY internal vpn-demo-1(config)# group-policy SSL-VPN-GROUP-POLICY attributes vpn-demo-1(config-group-policy)# vpn-tunnel-protocol ssl-client vpn-demo-1(config-group-policy)# split-tunnel-policy tunnelspecified vpn-demo-1(config-group-policy)# split-tunnel-network-list value split-tunnel vpn-demo-1(config-group-policy)# dns-server value 192.168.99.132 vpn-demo-1(config-group-policy)# default-domain value ashes.cc vpn-demo-1(config)# tunnel-group DefaultWEBVPNGroup general-attributes vpn-demo-1(config-tunnel-general)# default-group-policy SSL-VPN-GROUP-POLICY vpn-demo-1(config-tunnel-general)# address-pool vpn-pool ! vpn-demo-1(config)# username dkazakov password cisco vpn-demo-1(config)# username dkazakov attributes vpn-demo-1(config-username)# service-type remote-access ! vpn-demo-1(config)# ssl trust-point SELF vpn-demo-1(config)# webvpn vpn-demo-1(config-webvpn)# enable outside vpn-demo-1(config-webvpn)# anyconnect image disk0:/anyconnect-win-4.8.03036-webdeploy-k9.pkg vpn-demo-1(config-webvpn)# anyconnect enable !- (OPCIONAL): No exemplo acima, utilizamos um usuário local no MCE para autenticar usuários remotos, o que, claro, tem aplicação muito limitada além de laboratórios. Vou dar um exemplo de como adaptar rapidamente a configuração para autenticação em RADIUS servidor, utilizando como exemplo Cisco Identity Services Engine:
vpn-demo-1(config-aaa-server-group)# dynamic-authorization vpn-demo-1(config-aaa-server-group)# interim-accounting-update vpn-demo-1(config-aaa-server-group)# aaa-server RADIUS (outside) host 192.168.99.134 vpn-demo-1(config-aaa-server-host)# key cisco vpn-demo-1(config-aaa-server-host)# exit vpn-demo-1(config)# tunnel-group DefaultWEBVPNGroup general-attributes vpn-demo-1(config-tunnel-general)# authentication-server-group RADIUS !Essa integração permitiu não apenas implementar rapidamente o procedimento de autenticação com o serviço de diretórios AD, mas também diferenciar se o computador conectado pertence ao AD, entendendo se é um dispositivo corporativo ou pessoal, e avaliando o estado do dispositivo conectado.
- Faremos a configuração de NAT Transparente para que o tráfego entre o cliente e os recursos da rede corporativa não seja traduzido:
vpn-demo-1(config-network-object)# subnet 192.168.20.0 255.255.255.0 ! vpn-demo-1(config)# nat (inside,outside) source static any any destination static vpn-users vpn-users no-proxy-arp- (OPCIONAL): Para liberar nossos clientes para a Internet através do ASA (usando tunnelall As opções) usando PAT e também saindo através da mesma interface OUTSIDE, da qual eles se conectam, é necessário fazer as seguintes configurações
vpn-demo-1(config-network-object)# nat (outside,outside) source dynamic vpn-users interface vpn-demo-1(config)# nat (inside,outside) source dynamic any interface vpn-demo-1(config)# same-security-traffic permit intra-interface !- É extremamente importante, ao usar um cluster, permitir que a rede interna entenda para qual ASA rotear o tráfego de retorno aos usuários, para isso é necessário redistribuir rotas para endereços /32 concedidos aos clientes.
Atualmente, ainda não configuramos o cluster, mas já temos gateways VPN funcionando, aos quais podemos nos conectar individualmente por FQDN ou IP.
Podemos ver o cliente conectado na tabela de roteamento do primeiro ASA:
Para que todo nosso cluster VPN e toda a rede corporativa conheçam a rota até nosso cliente, faremos a redistribuição do prefixo do cliente para o protocolo de roteamento dinâmico, por exemplo, OSPF:
! vpn-demo-1(config)# route-map RMAP-VPN-REDISTRIBUTE permit 1 vpn-demo-1(config-route-map)# match ip address VPN-REDISTRIBUTE ! vpn-demo-1(config)# router ospf 1 vpn-demo-1(config-router)# network 192.168.255.0 255.255.255.0 area 0 vpn-demo-1(config-router)# log-adj-changes vpn-demo-1(config-router)# redistribute static metric 5000 subnets route-map RMAP-VPN-REDISTRIBUTEAgora temos uma rota até o cliente a partir do segundo gateway ASA-2 e os usuários conectados a diferentes gateways VPN dentro do cluster podem, por exemplo, se comunicar através do softphone corporativo diretamente, assim como o tráfego de retorno dos recursos solicitados pelos usuários chegará ao gateway VPN correto:
Vamos para a configuração de Load-Balancing do cluster.
O endereço 192.168.31.40 será usado como IP Virtual (VIP — todos os clientes VPN se conectarão a ele inicialmente), a partir deste endereço o Master do cluster fará o REDIRECT para o nó menos carregado do cluster. Não se esqueça de definir as entradas DNS direta e reversa tanto para cada endereço externo/FQDN de cada nó do cluster, quanto para o VIP.
vpn-demo-1(config)# vpn load-balancing vpn-demo-1(config-load-balancing)# interface lbpublic outside vpn-demo-1(config-load-balancing)# interface lbprivate inside vpn-demo-1(config-load-balancing)# priority 10 vpn-demo-1(config-load-balancing)# cluster ip address 192.168.31.40 vpn-demo-1(config-load-balancing)# cluster port 4000 vpn-demo-1(config-load-balancing)# redirect-fqdn enable vpn-demo-1(config-load-balancing)# cluster key cisco vpn-demo-1(config-load-balancing)# cluster encryption vpn-demo-1(config-load-balancing)# cluster port 9023 vpn-demo-1(config-load-balancing)# participate vpn-demo-1(config-load-balancing)#- Estamos verificando o funcionamento do cluster com dois clientes conectados:
- Tornaremos a experiência do cliente mais conveniente com o perfil qualquer-connect carregado automaticamente através do ASDM.
Nomeamos o perfil de maneira conveniente e associamos nossa política de grupo a ele:
Após a próxima conexão do cliente, esse perfil será baixado e instalado automaticamente no cliente qualquer-connect, assim, será apenas necessário selecioná-lo na lista caso precise se conectar:
Como, ao usar o ASDM, criamos esse perfil apenas em um ASA, não se esqueça de repetir as etapas nos outros ASAs do cluster.
Conclusão: Dessa forma, implantamos rapidamente um cluster de vários gateways VPN com balanceamento de carga automático. Adicionar novos nós ao cluster não é difícil, obtendo uma simples escalabilidade horizontal através da implantação de novas máquinas virtuais ASAv ou utilizando ASAs físicos. O cliente multifuncional qualquer-connect pode expandir muito as capacidades de conexão remota segura utilizando a função Postura (avaliação de estado), aplicada de forma mais eficaz em conjunto com o sistema de controle e auditoria de acesso centralizado Identity Services Engine.
Fonte: habr.com
