Pergunta

Por Que As Rotas Para Sites IPsec Ainda Existem No Socket Mesmo Quando Os Túneis IPsec Estão Descartados?

Por exemplo, um site IPsec foi configurado com um intervalo nativo de 10.80.80.0/24

Este site está atualmente desativado.

No CMA, em Monitoramento > Tabela de Roteamento, nós não vemos a rede 10.80.80.0/24

No entanto, na interface do usuário do Socket, ele ainda mostra a rota:

Responder

Os Sockets podem ser testados para alcançabilidade, com seus intervalos normalmente presentes nas tabelas de roteamento de outros Sockets somente se forem alcançáveis. Caso contrário, esses intervalos ficam acinzentados na página de monitoramento da interface do usuário do Socket. Esses intervalos que podem ser testados por ping são do tipo REMOTE_SITE, e a alcançabilidade é testada por pings que os Sockets enviam uns aos outros.

Em contraste, os sites IPsec não podem ser "testados por ping"; portanto, os Sockets consideram esses sites IPsec remotos como sempre conectados, e seus intervalos estáticos são sempre alcançáveis. Estes são vistos como REMOTE_RANGE. Esta é uma limitação conhecida, pois a alcançabilidade de REMOTE_RANGEs estáticos não pode ser testada.

Estudo de Caso

Este será um problema se o cliente tiver o seguinte projeto:

O site IPsec tem uma sub-rede de 10.10.10.0/24, e o site Socket tem uma sub-rede LAN BGP da rede 10.10.0.0/16. A intenção é que, quando o túnel IPsec estiver desativado, o tráfego destinado a 10.10.0.0/16 deva ser roteado através do site Socket. No entanto, isso não é viável. Como a tabela de roteamento do Socket ainda possui a rota 10.10.10.0/24 através do site IPsec (mesmo que o túnel IPsec esteja desativado), o Socket irá descartar o pacote. 

Solução Alternativa:

1. Publicar o intervalo 10.10.10.0/24 dinamicamente via o BGP
2. OU, usar uma faixa nativa no site IPsec que não se sobreponha com a faixa de rede de outro site