Après quelques jours d’absence voici un petit post rapide pour aider tous ceux qui doivent mettre en oeuvre des tunnels dans leur réseau. A l’heure où les entreprises multiplient les demandes pour un accès direct à internet sur les sites distants, on constate de fortes demandes pour interconnecter les sites via des tunnels sécurisés sur cette connexion internet. Celle-ci devient un complément essentiel de la connexion MPLS-VPN souvent en place: augmentation de la bande-passante, redondance des accès, et également en bonus une connexion directe vers le “cloud”. Un point qui peut se révéler assez pénible quand on met en place un tunnel (GRE, mGRE, avec éventuellement un IPsec en-dessous…) est le routage. La front-door VRF se révèle être une solution efficace. Quelques détails ci-dessous…
Au niveau “underlay”, sur le réseau physique, le routage doit permettre aux extrémités du tunnel (TEP – Tunnel End Points) de communiquer. Et généralement, on va aussi configurer un protocole au niveau overlay (ie. dans le tunnel). Combiner les 2 peut se révéler complexe: on veut s’assurer que chaque mécanisme de routage reste à sa place (par exemple le BGP avec l’opérateur, et un OSPF dans le tunnel). Comment faire coexister une route par défaut dans le tunnel et la route par défaut configurée sur l’accès internet? Généralement on va mettre en place quelques configurations spécifiques pour s’assurer qu’il n’y a pas de redistribution de routes et on va s’assurer que les distances administratives sont les bonnes. Idem on va configurer les filtres qui vont bien pour que les données qui doivent passer par le tunnel ne se retrouvent pas soudainement sur l’internet. Autre challenge: si par erreur l’adresse IP de l’extrémité du tunnel distante est vue par le tunnel, on se retrouve avec des logs indiquant une encapsulation infinie et plus rien ne fonctionne. Normal: on veut envoyer le paquet dans le tunnel, et pour joindre l’extrémité du tunnel on va devoir passer dans est le même tunnel, etc etc…
Une solution simple et élégante pour résoudre cette problématique, disponible depuis longtemps, consiste à utiliser une “front-door” VRF. On va simplement placer la liaison physique qui accueille le tunnel, interface où est configurée l’adresse IP du tunnel end point, dans une VRF. Cette VRF n’aura pas d’autre fonction que de segmenter cette interface du reste du réseau interne. Le tunnel et le réseau interne resteront dans la GRT (Global Routing table). Ainsi le routage de l’entreprise (overlay) sera naturellement disjoint du routage sous-jacent (underlay). La commande “tunnel vrf”, au niveau de l’interface tunnel, va simplement permettre d’indiquer dans quelle VRF on va chercher l’extrémité du tunnel.
On comprend immédiatement que les protocoles de routage underlay et overlay sont naturellement disjoints, chacun travaillant dans sa VRF. Un autre avantage est que la connexion internet se retrouve naturellement isolée du reste du réseau d’entreprise. D’un point de vue sécurité cela peut rassurer. Et si vous avez par exemple à configurer un réseau d’invités, il suffit de placer ce dernier dans la front-door VRF et vos invités auront accès simplement à Internet tout en étant isolés de vos ressources internes.
Plus de détails dans le CVD IWAN (Cisco Validated Design Intelligent WAN) ici.
@JeromeDurand
Authors
