OSPF: comment annoncer le sous-réseau d'un serveur OpenVPN?

J'ai réussi à configurer OSPF sur tous nos routeurs HP ProCurve 7102 et la plupart de nos routeurs Linux internes. Les itinéraires sont annoncés, et tout est peachy.

Sauf pour les routes dans les sous-réseaux gérés par divers services OpenVPN et d'autres connexions VPN autour de l'entreprise. Veuillez considérer l'image ci-dessous, qui montre une partie du réseau de l'entreprise:

Entrez la description de l'image ici

Les flèches rouges sont des connexions VPN. La zone bleue en bas représente la zone OSPF 0 (le squelette), qui comprend des routeurs dans tous les autres bureaux. La zone rose représente la zone OSPF 177 pour l'un de nos bureaux. Le rectangle orange est le réseau OpenVPN en question, hébergé sur le routeur Linux indiqué par l'icône bleue avec les flèches.

Le sous-réseau 10.177.0.0/16 est correctement annoncé dans toutes les autres zones OSPF. Cependant, malgré le fait que le réseau 10.180.1.0/24 est inclus dans la configuration OSPF, l'interface tun0 est incluse dans la zone 177 (en tant qu'interface passive), ce sous-réseau n'est pas annoncé.

Est-ce parce que c'est un itinéraire externe? Si oui, comment dirais-je au démon OSPF de publier cette route?

La première pensée qui vient à l'esprit est que vous devez redistribuer les routes du noyau en plus des itinéraires connectés dans Quagga / Zebra OSPF. Parce que OpenVPN ajoute les itinéraires lui-même, Zebra ne les redistribuera pas si vous ne disposez que d'une "redistribution statique" dans votre configuration.

J'utilise OpenVPN dans les environnements OSPF aussi, et tout redistribue très bien.

Remarque: vous devrez peut-être ajouter des filtres de liste de redistribution pour empêcher la redistribution d'autres voies du noyau qui ne devraient pas être annoncées.

Une autre option consiste à ajouter une route statique dans Zebra pour le 10.180.1.0/24 qui va au null ou au périphérique loopback.

Je me suis retrouvé avec un problème similaire après une orgie "se débarrasser de l'kernel et des itinéraires statiques".

La solution pour mon cas est de mettre le réseau OpenVPN dans une zone OSPF différente, puis d'utiliser l'astuce propre de remplacer le préfixe / 32 associé à l'adresse du point de terminaison du serveur par un préfixe de sous-réseau / 24. par exemple

192.168.22.0/24 est le sous-réseau OpenvVPN sur mon serveur FreeBSD 10.3-PRERELEASE OpenVPN.

Dans openvpn.conf:

dev tun server 192.168.22.0 255.255.255.0 

Lorsque OpenVPN est démarré, l'interface tun0 présente la configuration suivante:

 munchkin# ifconfig tun0 tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet6 fe80::222:15ff:fe4b:7e10%tun0 prefixlen 64 scopeid 0x1c inet 192.168.22.1 --> 192.168.22.2 netmask 0xffffffff nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> Opened by PID 2746 

Dans ospfd.conf:

 router ospf ... network 192.168.11.0/24 area 0.0.0.0 network 192.168.22.0/24 area 0.0.0.1 area 0.0.0.1 range 192.168.22.1/32 substitute 192.168.22.0/24 

OSPF publie alors 192.168.22.0/24 au lieu de 192.168.22.1/32

NB Ceci ne fonctionne que sur une limite de zone.