Question

Pourquoi les routes vers les sites IPsec existent-elles toujours dans Socket même si les tunnels IPsec sont interrompus ?

Par exemple, un site IPsec a été configuré avec une plage native de 10.80.80.0/24

Ce site est actuellement hors service.

Dans le CMA, sous Monitoring > Table de Routage, nous ne voyons pas le réseau 10.80.80.0/24

Cependant, dans l'interface utilisateur de Socket, elle affiche toujours la route :

Réponse

Les Sockets peuvent être testés pour leur accessibilité, avec leurs plages normalement présentes dans les tables de routage d'autres Sockets uniquement s'ils sont accessibles. Sinon, ces plages sont grisées sur la page de surveillance de l'interface utilisateur de Socket. Ces plages accessibles par ping sont du type REMOTE_SITE, et l'accessibilité est testée par des pings que les Sockets s'envoient mutuellement.

En revanche, les sites IPsec ne peuvent pas être "pingés"; par conséquent, les Sockets considèrent ces sites IPsec distants comme toujours connectés, et leurs plages statiques sont toujours accessibles. Ceux-ci sont considérés comme REMOTE_RANGE. C'est une limitation connue, car l'accessibilité des REMOTE_RANGEs statiques ne peut pas être testée.

Étude de cas

Cela posera un problème si le client a la conception suivante :

Le site IPsec a un sous-réseau de 10.10.10.0/24, et le site Socket a un sous-réseau LAN BGP du réseau 10.10.0.0/16. L'intention est que lorsque le tunnel IPsec est interrompu, le trafic destiné à 10.10.0.0/16 doit être dirigé par le site Socket. Cependant, ce n'est pas faisable. Comme la table de routage de Socket contient toujours la route 10.10.10.0/24 via le site IPsec (même si le tunnel IPsec est interrompu), le Socket abandonnera le paquet. 

Contournement :

1. Publier la plage 10.10.10.0/24 dynamiquement via le BGP
2. OU, utiliser une plage native sur le site IPsec qui ne chevauche pas la plage de réseau d'un autre site