Escale as sessões VPN por função e depois verifique a margem de falha

Você adiciona um segundo gateway, o console mostra dois membros saudáveis e o teto de sessões quase não se move, porque nada disse aos clientes como chegar à nova caixa. Escalar um serviço VPN são duas decisões em sequência: qual mecanismo distribui clientes para este tipo de conexão e quanta capacidade resta após a pior perda individual. Se as tomar na ordem inversa, obtém um projeto que parece redundante e falha exatamente quando é necessário. Comece pelo console e depois faça a aritmética.

Faça corresponder o mecanismo ao tipo de sessão

Os usuários remotos, os pares entre locais e os túneis de dispositivo sempre ativos não são sessões intercambiáveis. Uma função de distribuição criada para uma delas normalmente redireciona um cliente durante a negociação, o que não significa nada para um par que já tem um endereço fixo e uma configuração estática.

O guia de alta disponibilidade do ASA da Cisco mantém três capacidades separadas: o balanceamento de carga de VPN de acesso remoto, o failover com estado e o clustering entre locais. Apenas a primeira move um cliente elegível de uma entrada de grupo para um membro, e as conexões LAN a LAN ficam fora dessa distribuição. Um balanceador TCP genérico não substitui a etapa de redirecionamento do próprio protocolo, porque o handshake do túnel não é HTTP simples que um proxy possa reescrever. O resultado prático é um balanceador que aceita a conexão e ainda assim deixa o cliente sem conseguir criar o túnel.

Leia a lista de recursos em relação ao seu tipo de sessão antes de encomendar um segundo aparelho. A linha de licença e a linha de mecanismo são entradas separadas, e uma não implica a outra.

Trabalhe o exemplo em vez de adivinhar

Suponha que três gateways sejam validados cada um a 800 túneis simultâneos com a carga que aprovou, o que dá 2,400 no total. Uma meta de 1,650 na hora de pico parece confortável até uma unidade ser perdida, e então o par sobrevivente precisa manter 1,650 contra um 1,600 rígido. O projeto já falhou, e nenhum ajuste de failover conserta a aritmética.

Defina a meta de modo que o conjunto sobrevivente ainda a cumpra, o que, para um grupo de três membros, significa ficar abaixo de dois terços do total. Essa proporção é uma propriedade da aritmética e não de qualquer produto, por isso recalcule-a sempre que o número validado de um membro mudar. Mantenha a contagem licenciada, o máximo documentado e o seu próprio número medido em três colunas, porque raramente coincidem e o menor manda. Uma quarta coluna para o pico observado na hora de pico mantém o plano honesto depois do primeiro mês.

Orçamente a rajada de reconexão, não apenas o estado estável

As sessões de um membro falhado não reaparecem discretamente noutro lugar. Conforme o mecanismo, comutam com estado, renegociam do zero ou esperam que a aplicação tente novamente segundo o seu próprio calendário.

Alguns milhares de clientes a tentar novamente dentro de um minuto são um evento diferente de 1,650 estáveis, e os servidores de autenticação sentem-no primeiro. Verifique também o espaço do pool, pois o redirecionamento não o consulta: um membro que não consegue alocar um endereço ainda aceita o cliente e depois descarta o seu tráfego.

Verifique a capacidade com o pool e a rota à mão

A verificação é um exercício apenas de leitura que apanha a maioria dos erros de projeto antes de uma janela de manutenção abrir. Recolha o pool por membro, a contagem de sessões ativas e a rota de volta para a sub-rede do cliente, e depois compare cada um com o plano. O esgotamento do pool e uma rota de retorno ausente aparecem ambos como um cliente que se autentica e depois perde tráfego.

show vpn-sessiondb summary
show running-config ip local pool
show vpn load-balancing
show route 10.40.12.0 255.255.255.0

Execute essas leituras em cada membro durante uma hora de pico normal e não uma calma. Um membro que relata sessões mas não tem endereços livres já está no seu limite prático, diga o que disser a licença. Anote a versão do firmware ao lado de cada saída, porque os nomes dos comandos mudam entre versões.

Ensaie a perda uma vez de propósito, fora do horário de trabalho, e registe o que os membros sobreviventes relatam enquanto acontece. Um membro que aceita o redirecionamento mas não tem espaço no pool aparece como alocação falhada, o que a largura de banda extra nunca corrige. Guarde os números validados com a data ao lado do plano, para que a próxima revisão de capacidade comece com provas e não com uma folha de licenças. Acrescente o resultado desse ensaio à mesma página, mesmo quando os números coincidam com o plano.