Neste artigo, gostaria de fornecer instruções passo a passo sobre como você pode implantar rapidamente o esquema mais escalável no momento. VPN de acesso remoto baseado em acesso AnyConnect e Cisco ASA - Cluster de balanceamento de carga VPN.
Introdução: Muitas empresas ao redor do mundo, diante da atual situação com o COVID-19, estão fazendo esforços para transferir seus funcionários para o trabalho remoto. Devido à transição em massa para o trabalho remoto, a carga nos gateways VPN existentes das empresas está aumentando criticamente e é necessária uma capacidade muito rápida de dimensioná-los. Por outro lado, muitas empresas são forçadas a dominar apressadamente o conceito de trabalho remoto do zero.
Para ajudar as empresas a obter acesso VPN conveniente, seguro e escalável para funcionários no menor tempo possível, a Cisco está licenciando o cliente SSL-VPN rico em recursos AnyConnect por até 13 semanas. .
.
Eu preparei um guia passo a passo para uma implantação simples do VPN Load-Balancing Cluster como a tecnologia VPN mais escalável.
O exemplo abaixo será bastante simples em relação aos algoritmos de autenticação e autorização utilizados, mas será uma boa opção para um início rápido (que atualmente não é suficiente para muitos) com possibilidade de adaptação aprofundada às suas necessidades durante a implantação processo.
Informações breves: A tecnologia VPN Load Balancing Cluster não é um failover e nem uma função de clustering em seu sentido nativo, essa tecnologia pode combinar modelos ASA completamente diferentes (com certas restrições) para balancear a carga das conexões VPN de acesso remoto. Não há sincronização de sessões e configurações entre os nós de tal cluster, mas é possível balancear automaticamente a carga das conexões VPN e garantir a tolerância a falhas das conexões VPN até que pelo menos um nó ativo permaneça no cluster. A carga no cluster é balanceada automaticamente dependendo da carga de trabalho dos nós pelo número de sessões VPN.
Para failover de nós específicos do cluster (se necessário), um arquivador pode ser usado, então a conexão ativa será tratada pelo nó Primário do arquivador. O fileover não é uma condição necessária para garantir a tolerância a falhas dentro do cluster de balanceamento de carga, o próprio cluster, em caso de falha de um nó, transferirá a sessão do usuário para outro nó ativo, mas sem salvar o status da conexão, que é precisamente fornecido pelo arquivador. Assim, é possível, se necessário, combinar essas duas tecnologias.
Um cluster de balanceamento de carga VPN pode conter mais de dois nós.
O cluster de balanceamento de carga VPN é suportado no ASA 5512-X e superior.
Como cada ASA dentro do cluster de balanceamento de carga VPN é uma unidade independente em termos de configurações, realizamos todas as etapas de configuração individualmente em cada dispositivo individual.
A topologia lógica do exemplo dado:
Implantação primária:
-
Implantamos instâncias ASAv dos modelos que precisamos (ASAv5/10/30/50) da imagem.
-
Atribuímos as interfaces INSIDE / OUTSIDE às mesmas VLANs (Outside em sua própria VLAN, INSIDE em sua própria, mas geralmente dentro do cluster, veja a topologia), é importante que interfaces do mesmo tipo estejam no mesmo segmento L2.
-
Licenças:
- No momento, a instalação do ASAv não terá nenhuma licença e será limitada a 100kbps.
- Para instalar uma licença, você precisa gerar um token em sua Smart-Account: -> Licenciamento de Software Inteligente
- Na janela que se abre, clique no botão Novo token
- Certifique-se de que na janela que se abre haja um campo ativo e uma marca de seleção marcada 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 com uma solicitação de ativação.
- Depois de pressionar o botão Criar token, será criado um token que usaremos para obter uma licença para ASAv, copie-o:
- Repita as etapas 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 no ASA-1). O telnet não funciona com o exterior, se você realmente precisar, altere o nível de segurança para 100 para fora e retorne-o de volta.
! 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 um token na nuvem Smart-Account, você deve fornecer acesso à Internet para ASA, .
Resumindo, o ASA é necessário:
- acesso via HTTPS à Internet;
- sincronização de tempo (mais corretamente, via NTP);
- servidor DNS registrado;
- Nós telnet para nosso ASA e fazemos configurações para ativar a licença através de 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 ! ! Проверим работу 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: !!!!! ! ! Проверим синхронизацию 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 (synced), # master (unsynced), + selected, - candidate, ~ configured ! ! Установим конфигурацию нашей ASAv для Smart-Licensing (в соответствии с Вашим профилем, в моем случае 100М для примера) ! ciscoasa(config)# license smart ciscoasa(config-smart-lic)# feature tier standard ciscoasa(config-smart-lic)# throughput level 100M ! ! В случае необходимости можно настроить доступ в Интернет через прокси используйте следующий блок команд: !call-home ! http-proxy ip_address port port ! ! Далее мы вставляем скопированный из портала Smart-Account токен (<token>) и регистрируем лицензию ! ciscoasa(config)# end ciscoasa# license smart register idtoken <token>- Verificamos se o dispositivo registrou com sucesso uma licença e as opções de criptografia estão disponíveis:
-
Configure um SSL-VPN básico em cada gateway
- Em seguida, configure 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 ! ! Поднимем сервер HTTPS для ASDM на порту 445 чтобы не пересекаться с SSL-VPN порталом ! vpn-demo-1(config)# http server enable 445 !- Para o ASDM funcionar, você deve primeiro fazer o download do site cisco.com, no meu caso é o seguinte arquivo:
- Para que o cliente AnyConnect funcione, você precisa fazer upload de uma imagem para cada ASA para cada sistema operacional cliente de desktop usado (planejado para usar Linux / Windows / MAC), você precisará de um arquivo com Pacote de implantação de headend No título:
- Os arquivos baixados podem ser carregados, por exemplo, para um servidor FTP e carregados para cada ASA individual:
- Configuramos o certificado ASDM e autoassinado para SSL-VPN (recomenda-se usar um certificado confiável em produção). O FQDN definido do endereço do cluster virtual (vpn-demo.ashes.cc), bem como cada FQDN associado ao endereço externo de cada nó do cluster, deve resolver na zona DNS externa para o endereço IP da interface OUTSIDE (ou para o endereço mapeado se o encaminhamento de porta udp/443 for usado (DTLS) e tcp/443(TLS)). Informações detalhadas sobre os requisitos para o certificado são especificadas na seção Verificação de 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 % The fully-qualified domain name in the certificate will be: vpn-demo.ashes.cc Generate Self-Signed Certificate? [yes/no]: yes vpn-demo-1(config)# ! vpn-demo-1(config)# sh cry ca certificates Certificate Status: Available Certificate Serial Number: 4d43725e Certificate Usage: General Purpose Public Key Type: RSA (4096 bits) Signature Algorithm: SHA256 with RSA Encryption Issuer Name: serialNumber=9A439T02F95 hostname=vpn-demo.ashes.cc cn=*.ashes.cc ou=ashes-lab o=ashes c=ru Subject Name: serialNumber=9A439T02F95 hostname=vpn-demo.ashes.cc cn=*.ashes.cc ou=ashes-lab o=ashes c=ru Validity Date: start date: 00:16:17 MSK Mar 19 2020 end date: 00:16:17 MSK Mar 17 2030 Storage: config Associated Trustpoints: SELF CA Certificate Status: Available Certificate Serial Number: 0509 Certificate Usage: General Purpose Public Key Type: RSA (4096 bits) Signature Algorithm: SHA1 with RSA Encryption Issuer Name: cn=QuoVadis Root CA 2 o=QuoVadis Limited c=BM Subject Name: cn=QuoVadis Root CA 2 o=QuoVadis Limited c=BM Validity Date: start date: 21:27:00 MSK Nov 24 2006 end date: 21:23:33 MSK Nov 24 2031 Storage: config Associated Trustpoints: _SmartCallHome_ServerCA- Não se esqueça de especificar a porta para verificar se o ASDM está funcionando, por exemplo:
- Vamos realizar as configurações básicas do túnel:
- Vamos disponibilizar a rede corporativa pelo túnel, e deixar a Internet ir direto (não é o método mais seguro se não houver proteções no host conectado, é possível penetrar por um host infectado e exibir dados corporativos, opção política de túnel dividido tunnelall permitirá que todo o tráfego do host entre no túnel. No entanto túnel dividido torna possível descarregar o gateway VPN e não processar o tráfego de Internet do host)
- Vamos emitir endereços da sub-rede 192.168.20.0/24 para hosts no túnel (pool de 10 a 30 endereços (para o nó nº 1)). Cada nó do cluster VPN deve ter seu próprio pool.
- Faremos a autenticação básica com um usuário criado localmente no ASA (isso não é recomendado, esse é o método mais fácil), é melhor fazer a autenticação através LDAP/RAIO, ou melhor ainda, amarre Autenticação Multifator (MFA), V.g. CiscoDUO.
! 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, usamos um usuário local na ITU para autenticar usuários remotos, o que obviamente, exceto no laboratório, é pouco aplicável. Vou dar um exemplo de como adaptar rapidamente a configuração de autenticação para RAIO servidor, usado como exemplo Mecanismo de serviços de identidade da Cisco:
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 possibilitou não apenas integrar rapidamente o procedimento de autenticação com o serviço de diretório AD, mas também distinguir se o computador conectado pertence ao AD, entender se esse dispositivo é corporativo ou pessoal e avaliar o status do dispositivo conectado .
- Vamos configurar o Transparent NAT para que o tráfego entre o cliente e os recursos da rede corporativa não seja rabiscado:
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 expor nossos clientes à Internet através do ASA (ao usar tudo em túnel opções) usando PAT, bem como sair pela mesma interface OUTSIDE de onde estão conectados, você precisa 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 !- Ao utilizar um cluster, é extremamente importante habilitar a rede interna para entender qual ASA rotear o tráfego de retorno aos usuários, para isso é necessário redistribuir as rotas/32 endereços emitidos para os clientes.
No momento, ainda não configuramos o cluster, mas já temos gateways VPN funcionando que podem ser conectados individualmente via FQDN ou IP.
Vemos o cliente conectado na tabela de roteamento do primeiro ASA:
Para que todo o nosso cluster VPN e toda a rede corporativa conheçam a rota para o nosso cliente, iremos redistribuir o prefixo do cliente em um 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 para 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 diretamente por um softphone corporativo, bem como retornar o tráfego dos recursos solicitados pelo usuário. venha para o gateway VPN desejado:
-
Vamos configurar o cluster de balanceamento de carga.
O endereço 192.168.31.40 será usado como um IP Virtual (VIP - todos os clientes VPN inicialmente se conectarão a ele), a partir deste endereço o cluster Master fará um REDIRECIONAMENTO para um nó de cluster menos carregado. Não se esqueça de escrever encaminhar e reverter registro DNS 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)#- Verificamos o funcionamento do cluster com dois clientes conectados:
- Vamos tornar a experiência do cliente mais conveniente com o perfil AnyConnect carregado automaticamente via 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, este perfil será automaticamente baixado e instalado no cliente AnyConnect, portanto, caso precise conectar, basta selecioná-lo na lista:
Como criamos este perfil em apenas um ASA usando ASDM, não esqueça de repetir as etapas nos outros ASAs do cluster.
Conclusão: Assim, implantamos rapidamente um cluster de vários gateways VPN com balanceamento de carga automático. Adicionar novos nós ao cluster é fácil, com escala horizontal simples, implementando novas máquinas virtuais ASAv ou usando ASAs de hardware. O cliente AnyConnect rico em recursos pode aprimorar muito a conexão remota segura usando o Postura (estimativas do estado), usado de forma mais eficaz em conjunto com o sistema de controle centralizado e contabilidade de acesso Mecanismo de Serviços de Identidade.
Fonte: habr.com