A opção Virtual Connect ajuda a estender com segurança a rede privada pela Internet usando túneis IP VPN ponto a ponto.
Introdução
O Virtual Connect é uma opção de complemento adicional da Conectividade em nuvem para a Instância dedicada do Webex Calling (Instância dedicada). O Virtual Connect permite que os clientes estendam com segurança sua rede privada pela Internet usando túneis IP VPN ponto a ponto. Essa opção de conectividade fornece um estabelecimento rápido de conexão de rede privada usando o equipamento de premissa do cliente (CPE) existente e conectividade com a Internet.
A Cisco hospeda, gerencia e garante túneis IP VPN redundantes e o acesso à Internet necessário nas regiões do centro de dados de Instância dedicado da Cisco onde o serviço é necessário. Da mesma forma, o Administrador é responsável por seus serviços de CPE e Internet correspondentes, necessários para o estabelecimento do Virtual Connect.
Cada pedido do Virtual Connect em uma região de Instância dedicada específica inclui dois túneis de encapsulamento de roteamento genérico (GRE) protegidos por criptografia IPSec (GRE sobre IPSec), um para cada centro de dados da Cisco na região selecionada.
O Virtual Connect tem um limite de largura de banda de 250 Mbps por túnel e é recomendado para implantações menores. Como dois túneis VPN ponto a ponto são usados, todo o tráfego para a nuvem tem que passar pelo CPE do headend do cliente e, portanto, pode não ser adequado onde há muitos sites remotos. Para outras opções de emparelhamento alternativas, consulte Conectividade em nuvem .
 |
Antes de enviar a solicitação de emparelhamento do Virtual Connect, verifique se o serviço de Instância dedicado está ativado na respectiva região. |
Pré-requisitos
Os pré-requisitos para estabelecer o Virtual Connect incluem:
O cliente fornece
Conexão à Internet com largura de banda disponível suficiente para suportar a implantação
endereço IP público para dois túneis IPSec
Endereços de IP de transporte GRE do lado do cliente para os dois túneis GRE
Parceiro e cliente
Trabalhe em conjunto para avaliar os requisitos de largura de banda
Garantir que os dispositivo de rede suportam o roteamento do Border Gateway Protocol (BGP) e um projeto de túnel GRE sobre IPSec
O parceiro ou cliente fornece
Equipe de rede com conhecimento de tecnologias de túnel VPN site a site
Equipe de rede com conhecimento de BGP, eBGP e princípios gerais de roteamento
Cisco
A Cisco atribuiu números de sistema autônomos privados (ASNs) e endereçamento IP transitório para interfaces de túnel GRE
A Cisco atribuiu uma rede Classe C (/24) pública, mas não roteável pela Internet, para endereçamento de nuvem de instância dedicado
|
Se um cliente tiver apenas 1 dispositivo CPE, os 2 túneis para os centros de dados da Cisco (DC1 e DC2) em cada região serão a partir desse dispositivo CPE. O cliente também tem uma opção para 2 dispositivos CPE; em seguida, cada dispositivo CPE deve se conectar a 1 túnel apenas para os centros de dados da Cisco (DC1 e DC2) em cada região. Redundância adicional pode ser obtida terminando cada túnel em um local físico separado dentro da infraestrutura do Cliente. |
Detalhes técnicos
Modelo de implantação
O Virtual Connect usa uma arquitetura de headend de camada dupla, em que os planos de roteamento e de controle GRE são fornecidos por um dispositivo e o plano de controle IPSec é fornecido por outro.
Após a conclusão do Conexão virtual conectividade, dois túneis GRE sobre IPSec serão criados entre a rede corporativa do Cliente e os centros de dados da Cisco da Instância dedicada. Um para cada centro de dados redundante na respectiva região. Elementos de rede adicionais necessários para o emparelhamento são trocados pelo parceiro ou cliente para a Cisco através do formulário de ativação do Control Hub Virtual Connect.
A Figura 1 mostra um exemplo do modelo de implantação do Virtual Connect para a opção de 2 concentradores no lado do cliente.
Virtual Connect - VPN é um design de Hub, em que os Sites de Hub do cliente são conectados ao DC1 e DC2 dos centros de dados da Instância dedicado dentro de uma região específica.
Dois sites Hub são recomendados para melhor redundância, mas o site One Hub com dois túneis também é um modelo de implantação compatível.
|
A largura de banda por túnel é limitada a 250 Mbps. |
 |
Os sites remotos do Cliente dentro da mesma região precisariam se conectar de volta aos sites do Hub através da WAN do Cliente e não é responsabilidade da Cisco por essa conectividade. |
Espera-se que os Parceiros trabalhem em estreita colaboração com os Clientes, garantindo que o caminho mais ideal seja escolhido para a região de serviço 'Virtual Connect'.
A Figura 2 mostra as regiões de emparelhamento de conectividade em nuvem da instância dedicada.
Roteamento
O roteamento para o complemento do Virtual Connect é implementado usando o BGP externo (eBGP) entre a Instância dedicada e o equipamento de premissa do cliente (CPE). A Cisco anunciará sua respectiva rede para cada DC redundante dentro de uma região para o CPE do Cliente, e o CPE é necessário para anunciar uma rota padrão para a Cisco.
A Cisco mantém e atribui
Endereçamento IP de interface de túnel (link transitório para roteamento) que a Cisco atribui de um espaço de endereçamento compartilhado designado (roteável não publicamente)
Endereço de destino do transporte do túnel (lado da Cisco)
Números de sistema autônomo (ASNs) privados para configuração de roteamento do BGP do cliente
A Cisco atribui a partir do intervalo de uso privado designado: 64512 a 65534
eBGP usado para trocar rotas entre a Instância dedicada e o CPE
A Cisco vai dividir a rede /24 atribuída em 2 /25 uma para cada DC na respectiva região
No Virtual Connect, cada rede /25 é anunciada de volta para o CPE pela Cisco nos respectivos túneis VPN ponto a ponto (link temporário)
O CPE deve ser configurado com os vizinhos eBGP apropriados. Se estiver usando um CPE, dois vizinhos eBGP serão usados, um apontando para cada túnel remoto. Se estiver usando dois CPE, cada CPE terá um vizinho eBGP apontando para o único túnel remoto do CPE.
O lado da Cisco de cada túnel GRE (IP da interface de túnel) é configurado como o vizinho BGP no CPE
O CPE é necessário para anunciar uma rota padrão em cada um dos túneis
O CPE é responsável por redistribuir, conforme necessário, as rotas aprendidas dentro da rede corporativa do cliente.
Na condição de falha de link sem falha, um único CPE terá dois túneis ativos/ativos. Para dois nós CPE, cada CPE terá um túnel ativo e ambos os nós CPE devem estar ativos e passando o tráfego. Em um cenário de não falha, o tráfego deve ser dividido em dois túneis que vão para os destinos /25 corretos. Se um dos túneis ficar inativo, o túnel restante poderá transportar o tráfego para ambos. Em tal cenário de falha, quando a rede /25 está fora do ar, a rede /24 é usada como uma rota de backup. A Cisco enviará o tráfego do cliente através de sua WAN interna para o DC que perdeu a conectividade.
Processo de conectividade
| 1 | |
| 2 | |
| 3 | |
| 4 |
Passo 1: Pedido CCW
O Virtual Connect é um complemento para Instância dedicado no CCW.
| 1 | Navegue até o site de pedidos do CCW e clique em Logon para iniciar sessão no site: |
||
| 2 | Criar estimativa. |
||
| 3 | Adicione a SKU "A-FLEX-3". |
||
| 4 | Selecione Editar opções. |
||
| 5 | Na guia de assinatura exibida, selecione Opções e Complementos. |
||
| 6 | Em Complementos adicionais, marque a caixa de seleção ao lado de "Conexão virtual para instância dedicada". O nome da SKU é "A-FLEX-DI-VC". |
||
| 7 | Insira a quantidade e o número de regiões em que o Virtual Connect é necessário.
|
||
| 8 | Quando estiver satisfeito com suas seleções, clique em Verificar e salvar na parte superior direita da página. |
||
| 9 | Clique em Salvar e continuar para finalizar seu pedido. Seu pedido finalizado aparece agora na grade de pedidos. |
Passo 2: Ativação do Virtual Connect no Control Hub
| 1 | Iniciar sessão no Control Hubhttps://admin.webex.com/login . |
||||||||
| 2 | No Serviços seção, navegue até Chamadas > Instância dedicada > Conectividade em nuvem . |
||||||||
| 3 | No cartão do Virtual Connect, a quantidade do Virtual Connect adquirida é listada. O administrador pode agora clicar em Ativar para iniciar a ativação do Virtual Connect. 
|
||||||||
| 4 | Ao clicar no Ativar botão, Ativar o Virtual Connect é exibido para que o administrador forneça os detalhes técnicos do Virtual Connect necessários para as configurações de emparelhamento no lado da Cisco.
|
||||||||
| 5 | Clique no Ativar botão depois que todos os campos obrigatórios forem preenchidos. |
||||||||
| 6 | Depois que o formulário de Ativação do Virtual Connect for preenchido para uma região específica, o cliente poderá Exportar o formulário de ativação do Control Hub, Chamadas > Instância dedicada > Conectividade em nuvem, e clicar em Exportar configurações. 
|
Passo 2: A Cisco executa a configuração de rede
| 1 | Assim que o formulário de Ativação do Virtual Connect for preenchido, o status será atualizado para Ativação em andamento em Chamadas > Instância dedicado > Conectividade em nuvem Virtual Connect card. |
| 2 | A Cisco concluirá as configurações necessárias no equipamento secundário da Cisco dentro 5 dias úteis . Após a conclusão bem-sucedida, o status será atualizado para "Ativado" nessa região específica no Control Hub. |
Passo 4: O cliente executa a configuração de rede
O status é alterado para "Ativado" para notificar o administrador do Cliente de que o lado da Cisco das configurações para a conectividade IP VPN foi concluído com base nas entradas fornecidas pelo Cliente. Mas, espera-se que o administrador de clientes complete seu lado das configurações nos CPEs e teste as rotas de conectividade para que o túnel do Virtual Connect fique on-line. Em caso de quaisquer problemas enfrentados no momento da configuração ou conectividade, o cliente pode entrar em contato com o CAT da Cisco TAC para obter assistência. |
Solução de problemas
Solução de problemas e validação da primeira fase do IPsec (negociação IKEv2)
A negociação do túnel IPsec envolve duas fases, a fase IKEv2 e a fase IPsec. Se a negociação da fase IKEv2 não for concluída, não haverá iniciação de uma segunda fase IPsec. Primeiro, emita o comando "show crypto ikev2 sa" (no equipamento Cisco) ou um comando semelhante no equipamento de terceiros para verificar se a sessão IKEv2 está ativa. Se a sessão IKEv2 não estiver ativa, os possíveis motivos podem ser:
Tráfego interessante não aciona o túnel IPsec.
A lista de acesso do túnel IPsec está configurada incorretamente.
Não há conectividade entre o cliente e o IP do ponto de extremidade do túnel IPsec da instância dedicada.
Os parâmetros de sessão IKEv2 não estão sendo correspondentes entre o lado da Instância dedicado e o lado do cliente.
Um firewall está bloqueando os pacotes UDP IKEv2.
Primeiro, verifique os logs de IPsec para ver se há mensagens que mostrem o andamento da negociação do túnel IKEv2. Os registros podem indicar onde há um problema com a negociação IKEv2. A falta de mensagens de registro também pode indicar que a sessão IKEv2 não está sendo ativada.
As configurações do IKEv2 no lado do CPE não correspondem ao lado da Cisco, verifique novamente as configurações mencionadas:
Verifique se a versão do IKE é a versão 2.
Verifique se os parâmetros de Criptografia e Autenticação correspondem à criptografia esperada no lado da Instância dedicado.
Quando a cifra "GCM" está em uso, o protocolo GCM trata a autenticação e define o parâmetro de autenticação como NULL.
Verifique a configuração da vida útil.
Verifique o grupo de módulo Diffie Hellman.
Verifique as configurações da função pseudoaleatória.
A lista de acesso para o mapa de criptografia não está definida para:
Permissão GRE (local_tunnel_transport_ip ) 255.255.255.255 (remote_tunnel_transport_ip ) 255.255.255.255" (ou comando equivalente)
A lista de acesso deve ser especificamente para o protocolo "GRE" e o protocolo "IP" não funcionará.
Se as mensagens de registro não estiverem mostrando qualquer atividade de negociação para a fase IKEv2, uma captura de pacotes pode ser necessária.
|
O lado da Instância dedicado pode nem sempre iniciar a troca IKEv2 e, às vezes, pode esperar que o lado do CPE do cliente seja o iniciador. Verifique a configuração do lado do CPE para obter os seguintes pré-requisitos para a iniciação da sessão IKEv2:
|
Quando configurado corretamente, o seguinte inicia o túnel IPsec e a negociação IKEv2 de primeira fase:
Keepalives de GRE da interface do túnel GRE do lado do CPE para a interface do túnel GRE do lado da Instância dedicado.
Sessão TCP do vizinho BGP do vizinho BGP do lado do CPE para o vizinho BGP do lado da instância dedicada.
Faça ping do endereço de IP do túnel do lado do CPE para o endereço IP do túnel do lado da Instância dedicado.
O ping não pode ser o IP de transporte do túnel para o IP de transporte do túnel, ele deve ser o IP do túnel para IP.
Se um rastreamento de pacote for necessário para o tráfego IKEv2, defina o filtro para UDP e a porta 500 (quando nenhum dispositivo NAT estiver no meio dos terminais IPsec) ou a porta 4500 (quando um dispositivo NAT for inserido no meio do IPsec terminais).
Verifique se os pacotes UDP IKEv2 com porta 500 ou 4500 são enviados e recebidos de e para o endereço IP do DI IPsec.
|
O data center de Instância dedicado nem sempre pode iniciar o primeiro pacote IKEv2. O requisito é que o dispositivo CPE seja capaz de iniciar o primeiro pacote IKEv2 em direção ao lado da Instância dedicado. Se o firewall local permitir, tente também um ping para o endereço IPsec remoto. Se o ping não for bem-sucedido do endereço IPsec local para o remoto, execute uma rota de rastreamento para ajudar e determine onde o pacote será descartado. Alguns firewalls e equipamentos de Internet podem não permitir a rota de rastreamento. |
Solução de problemas e validação da segunda fase do IPsec (negociação do IPsec)
Verifique se a primeira fase do IPsec (ou seja, associação de segurança IKEv2) está ativa antes de solucionar problemas da segunda fase do IPsec. Execute um comando "show crypto ikev2 sa" ou equivalente para verificar a sessão IKEv2. No resultado, verifique se a sessão IKEv2 está ativa há mais de alguns segundos e se não está sendo rejeitada. O tempo de atividade da sessão aparece como a sessão "Horário ativo" ou equivalente no resultado.
Assim que a sessão IKEv2 for verificada como ativa e ativa, investigue a sessão IPsec. Tal como acontece com a sessão IKEv2, execute um "show crypto ipsec sa" ou comando equivalente para verificar a sessão IPsec. A sessão IKEv2 e a sessão IPsec devem estar ativas antes que o túnel GRE seja estabelecido. Se a sessão IPsec não aparecer como ativa, verifique os registros IPsec para mensagens de erro ou erros de negociação.
Alguns dos problemas mais comuns que podem ser encontrados durante as negociações IPsec são:
As configurações no lado do CPE não correspondem ao lado da Instância dedicado. Verifique novamente as configurações:
Verifique se os parâmetros de Criptografia e Autenticação correspondem às configurações no lado da Instância dedicado.
Verifique as configurações do Perfect Forward Secrecy e se as configurações correspondem às da Instância dedicada.
Verifique as configurações de vida útil.
Verifique se o IPsec foi configurado em modo de túnel.
Verifique os endereços IPsec de origem e destino.
Solução de problemas e validação da interface do túnel
Quando as sessões IPsec e IKEv2 são verificadas como ativadas e ativas, os pacotes de manutenção de atividade do túnel GRE são capazes de fluir entre a Instância dedicada e os terminais do túnel CPE. Se a interface do túnel não estiver exibindo o status, alguns problemas comuns são:
A VRF de transporte da interface de túnel não corresponde à VRF da interface de loopback (se a configuração de VRF é usada na interface de túnel).
Se a configuração VRF não for usada na interface do túnel, esta verificação poderá ser ignorada.
Keepalives não estão ativados na interface do túnel do lado do CPE
Se as atividades de manutenção não forem suportadas no equipamento CPE, a Cisco deverá ser notificada para que as atividades de manutenção padrão no lado da Instância dedicado também sejam desativadas.
Se os keepalives forem suportados, verifique se os keepalives estão ativados.
A máscara ou o endereço IP da interface do túnel não estão corretos e não correspondem aos valores esperados da Instância dedicado.
O endereço de transporte do túnel de origem ou destino não está correto e não corresponde aos valores esperados da Instância dedicado.
Um firewall está bloqueando o envio de pacotes GRE pelo túnel IPsec ou recebidos do túnel IPsec (o túnel GRE é transportado pelo túnel IPsec)
Um teste de ping deve verificar se a interface do túnel local está ativa e se a conectividade é boa para a interface do túnel remoto. Execute a verificação de ping do IP do túnel (não do IP de transporte) para o IP do túnel remoto.
|
A lista de acesso criptográfico para o túnel IPsec que está transportando o tráfego do túnel GRE permite que apenas os pacotes GRE se cruzem. Como resultado, os pings não funcionarão do IP de transporte de túnel para o IP de transporte de túnel remoto. |
A verificação de ping resulta em um pacote GRE que é gerado do IP de transporte do túnel de origem para o IP de transporte do túnel de destino, enquanto a carga do pacote GRE (o IP interno) será o IP do túnel de origem e destino.
Se o teste de ping não for bem-sucedido e os itens anteriores forem verificados, uma captura de pacotes pode ser necessária para garantir que o ping icmp esteja resultando em um pacote GRE que é então encapsulado em um pacote IPsec e, em seguida, enviado do endereço IPsec de origem para o endereço IPsec de destino. Os contadores na interface do túnel GRE e os contadores de sessão IPsec também podem ajudar a mostrar. se os pacotes de envio e recebimento estão sendo incrementados.
Além do tráfego de ping, a captura também deve mostrar pacotes GRE de manutenção de atividade, mesmo durante o tráfego ocioso. Finalmente, se o BGP estiver configurado, os pacotes de manutenção de atividade do BGP também deverão ser enviados como pacotes GRE encapsulados em pacotes IPSEG, bem como através da VPN.
Solução de problemas e validação do BGP
Sessões BGP
O BGP é necessário como o protocolo de roteamento no túnel IPsec da VPN. O vizinho BGP local deve estabelecer uma sessão eBGP com o vizinho BGP da instância dedicado. Os endereços IP do vizinho eBGP são os mesmos que os endereços IP do túnel local e remoto. Primeiro, certifique-se de que a sessão BGP está ativa e, em seguida, verifique se as rotas corretas estão sendo recebidas da Instância dedicada e se a rota padrão correta é enviada para a Instância dedicada.
Se o túnel GRE estiver ativo, verifique se um ping é bem-sucedido entre o IP do túnel GRE local e o remoto. Se o ping for bem-sucedido, mas a sessão BGP não estiver sendo iniciada, investigue o log do BGP para ver se há erros de estabelecimento do BGP.
Alguns dos problemas mais comuns de negociação do BGP são:
O número de AS remoto não corresponde ao número de AS configurado no lado da Instância dedicado; verifique novamente a configuração do AS vizinho.
O número do AS local não corresponde ao que o lado da Instância dedicado está esperando. Verifique se o número do AS local corresponde aos parâmetros da Instância dedicado esperado.
Um firewall está bloqueando os pacotes TCP BGP encapsulados em pacotes GRE de serem enviados para o túnel IPsec ou serem recebidos do túnel IPSEG
O IP do vizinho BGP remoto não corresponde ao IP do túnel GRE remoto.
Troca de rota BGP
Depois que a sessão BGP for verificada para ambos os túneis, certifique-se de que as rotas corretas estão sendo enviadas e recebidas do lado da Instância dedicado.
A solução de Instância dedicada VPN espera que dois túneis sejam estabelecidos do lado do cliente/parceiro. O primeiro túnel aponta para o centro de dados da Instância dedicado A e o segundo túnel aponta para o centro de dados da Instância dedicado B. Ambos os túneis devem estar em estado ativo e a solução requer uma implantação ativa/ativa. Cada centro de dados de Instância dedicado anunciará sua rota local /25, bem como uma rota de backup /24. Ao verificar as rotas BGP de entrada da Instância dedicada, certifique-se de que a sessão BGP associada com o túnel que aponta para o data center A da Instância dedicado receba a rota local do centro de dados A da Instância dedicado /25, bem como a rota de backup /24. Além disso, certifique-se de que o túnel que aponta para o centro de dados da Instância dedicado B receba a rota local do centro de dados da Instância dedicado B/25, bem como a rota de backup /24. Observe que a rota de backup /24 será a mesma rota anunciada para fora do data center de Instância dedicado A e do data center de Instância dedicado B.
A redundância será fornecida para um centro de dados de Instância dedicado se a interface do túnel para esse centro de dados ficar inativa. Se a conectividade com o centro de dados A da Instância dedicado for perdida, o tráfego será encaminhado do centro de dados B da Instância dedicado para o centro de dados A. Neste cenário, o túnel para o centro de dados B usará a rota do centro de dados B/25 para enviar tráfego para o centro de dados B e o túnel para o data center B usará a rota de backup /24 para enviar tráfego para o data center A através do data center B.
É importante que, quando ambos os túneis estiverem ativos, o túnel do centro de dados A não seja usado para enviar tráfego para o centro de dados B e vice-versa. Neste cenário, se o tráfego for enviado para o centro de dados A com um destino do centro de dados B, o centro de dados A encaminhará o tráfego para o centro de dados B e, em seguida, o centro de dados B tentará enviar o tráfego de volta para a origem através do túnel do centro de dados B. Isso resultará em roteamento abaixo do ideal e também poderá quebrar os firewalls de passagem de tráfego. Portanto, é importante que os dois túneis estejam em uma configuração ativo/ativo durante a operação normal.
A rota 0.0.0.0/0 deve ser anunciada do lado do cliente para o lado do datacenter da Instância dedicado. Rotas mais específicas não serão aceitas pelo lado da Instância dedicado. Certifique-se de que a rota 0.0.0.0/0 é anunciada para fora do túnel do data center A da Instância dedicado e do túnel do data center B da Instância dedicado.
Configuração MTU
No lado da Instância dedicado, dois recursos são ativados para ajustar dinamicamente a MTU para tamanhos de pacotes grandes. O túnel GRE adiciona mais cabeçalhos aos pacotes IP que fluem através da sessão VPN. O túnel IPsec adiciona os cabeçalhos extras sobre os cabeçalhos GRE e reduz ainda mais a maior MTU permitida no túnel.
O túnel GRE ajusta o recurso MSS e o caminho do túnel GRE no recurso de descoberta MTU é ativado no lado da Instância dedicado. Configure "ip tcp ajuste-mss 1350" ou comando equivalente, bem como "caminho do túnel\u0002mtu-discovery" ou comando equivalente no lado do cliente para ajudar com o ajuste dinâmico da MTU do tráfego através do túnel VPN.
