Distribution EOLE

Bonjour,

Nous avons passé un département complet en de AMON 2.5.2 en 2.7.1 et nous avons le soucis suivant :

Nous déclarons un tunnel qui est un classe C, qui est en réalité présent en plusieurs morceaux coté EPLE.
Il s'avère qu'en 2.7.1, les règles de passthrough ne sont pas appliquées pour ces différents "morceaux", car il n'y a pas correspondance entre le réseau du VPN et les réseaux locaux.

La fonctionnalité a été récrite ici : https://dev-eole.ac-dijon.fr/projects/eole-vpn/repository/revisions/9b3b7f35bcc9b9df0645283a0477f912043da93b/diff

Tout me semble ok de ce que j'ai compris du script, la ou il faudrait ajouter du test c'est sur le bloc ligne 320 et après, car en l'état, il est recherché un match réseau complet. Il n'y a pas de test pour voir si le subnet est un sous ensemble d'un réseau monté coté VPN.

Exemple :

Je monte en VPN :

amon-CD41-maquette-sphynx-adriatic-DSI_1-pedago1D-adriatic{49}:   10.141.41.0/24 === 172.16.0.0/13

Mon AMON a les subnets suivants :

 IP('10.141.41.200/29'), int eth0
 IP('10.41.41.0/24'), adm
 IP('172.23.52.0/22'), ped
 IP('10.141.41.0/25'), vlan5
 IP('10.141.41.128/27'), vlan35
 IP('172.23.55.128/27'), vlan21
 IP('192.168.227.0/25'), vlan wifi
 IP('192.168.228.0/22'), vlan wifi
 IP('192.168.227.128/25'), vlan wifi
 IP('192.168.226.0/25'), vlan wifi
 IP('192.168.226.128/25'), vlan wifi
 IP('10.141.41.224/28'),  vlan4
 IP('10.141.41.160/28'), int dmz pub
 IP('192.168.207.66'), vpn
 IP('192.168.203.0/24')] vpn

La conf des tunnels tel que le test la fonction "generate_passthrough" dans active_rvp est :

{IP('172.23.52.0/22'): [IP('192.168.207.128/25'), IP('172.16.0.0/13')]
 IP('10.141.41.0/24'): [IP('192.168.207.128/25'), IP('172.16.0.0/13')], 
 IP('10.41.41.0/24'): [IP('192.168.207.128/25'), IP('172.24.0.0/13'), IP('10.0.0.0/8'), IP('161.48.0.0/19'), IP('172.16.0.0/13')]

Du coup sur le bloc ligne 320, '10.141.41.0/24' ne matchera jamais. Hors j'ai besoin de regles de passthrough pour que par exemple, la "DMZ pub" soit joignable depuis la "peda" en 172.23.52.0/22.

Dans ce cas précis, sans ip xfrm policy, on rentre dans le tunnel

 10.141.41.0/24 === 172.16.0.0/13

Une des autres solutions est de déclarer chaque subnet dans la conf ipsec, mais c'est bien plus lourd, et la version 2.5.2 fonctionnait en l'état, ce qui est bien pratique.

En attendant, on passe des ip xfrm policy en script, mais ce n'est pas beau... ;-)

Nicolas