Projet

Général

Profil

Evolution #4803

leftsourceip en 2.3

Ajouté par Guillaume PITARD il y a environ 11 ans. Mis à jour il y a environ 11 ans.

Statut:
Fermé
Priorité:
Haut
Catégorie:
-
Début:
Echéance:
12/04/2013
% réalisé:

100%

Temps estimé:
0.25 h
Temps passé:
Distribution:
EOLE 2.3

Description

Bonjour,

J'ai découvert un bug problématique en 2.3 lorsqu'on gère les tunnels agriates.

On ne peut pas imposer dans la conf vpn avec quelle adresse IP l'amon va rentrer dans les tunnels.
Ainsi si un proxy parent existe et nécessite le passage par les tunnels, ou lors des requêtes DNS à destination des serveurs en in.ac- quelque-chose, on ne maîtrise l'adresse IP source.
Cela peut-être une ip 10.dep (admin) ou une en 10.1dep (peda), dans mon cas j'ai également des IP en 172 pour des réseaux péda. Du coup, s'il existe des règles de filtrage pour que des stations pédagogiques n'aillent pas sur nos réseaux centraux, cela va provoquer des dysfonctionnements.

Pouvez-vous faire en sorte que lorsque les paquets sont émis par l'amon, il le soit avec l'IP admin de l'amon.

Cordialement,


Demandes liées

Lié à arv - Evolution #4036: adresse source aléatoire Fermé 11/09/2012

Révisions associées

Révision a79eb240 (diff)
Ajouté par Fabrice Barconnière il y a environ 11 ans

rvp/tmpl/ipsec_updown : routes gérées ici -> ip eth1 src par defaut
rvp/tmpl/strongswan.conf : désactiver gestion routes par Strongswan
fixes #4803 @1h

Historique

#1 Mis à jour par Guillaume PITARD il y a environ 11 ans

Bonjour,

C'est même pire que ce que je pensais, l'ip source de l'amon change en fonction du réseau de la destination.
Voici un exemple obtenu pour 4 réseaux différents, les ping son lancé du même amon.

:~# ping 10.10.10.10
...
:~# ping 172.30.30.30
...
:~# ping 192.168.1.1
...
:~# ping 161.48.0.1

résultats sur le sphynx:
root@xxxxxxxxx:~# tcpdump -ni eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
08:18:19.973259 IP 10.72.254.4 > 10.10.10.10: ICMP echo request, id 11376, seq 1, length 64
...
08:18:33.789489 IP 10.172.254.126 > 172.30.30.30: ICMP echo request, id 12144, seq 1, length 64
...
08:18:48.376163 IP 10.172.254.126 > 192.168.1.1: ICMP echo request, id 15216, seq 1, length 64
...
08:19:07.353470 IP 10.72.254.4 > 161.48.0.1: ICMP echo request, id 16496, seq 1, length 64

On vois l'amon utiliser des IP différentes en fonction des réseau de destination.

Ce qui est cohérent avec l'ordre dans lequel les tunnels ce sont montés.

amon crid72-sphynx RECTORAT ACADEMIE DE NANTES1: ESTABLISHED 8 minutes ago, 10.172.253.254[C=fr, O=gouv, OU=education, OU=ac-nantes, CN=0721572T-02]...195.83.xx.xx[C=fr, O=gouv, OU=education, OU=ac-nantes, CN=AGRIATES-NANTES-02]
APA_admin_10{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: c6e9ba90_i cc3fd008_o
APA_admin_10{1}: 10.72.254.0/24 === 10.0.0.0/8
APA_peda_192{2}: INSTALLED, TUNNEL, ESP in UDP SPIs: c71d98bb_i cd6288eb_o
APA_peda_192{2}: 10.172.254.0/24 === 192.168.0.0/16
APA_peda_172{3}: INSTALLED, TUNNEL, ESP in UDP SPIs: c07de140_i c9f786da_o
APA_peda_172{3}: 10.172.254.0/24 === 172.16.0.0/12
APA_peda_10{4}: INSTALLED, TUNNEL, ESP in UDP SPIs: c621c035_i ce367b71_o
APA_peda_10{4}: 10.172.254.0/24 === 10.0.0.0/8
APA_admin_ader{5}: INSTALLED, TUNNEL, ESP in UDP SPIs: c3c82818_i c8ab342f_o
APA_admin_ader{5}: 10.72.254.0/24 === 161.48.0.0/19
APA_admin_172{6}: INSTALLED, TUNNEL, ESP in UDP SPIs: cb09a80d_i cca36fe6_o
APA_admin_172{6}: 10.72.254.0/24 === 172.16.0.0/12
APA_admin_192{7}: INSTALLED, TUNNEL, ESP in UDP SPIs: c899ba54_i c0447f63_o
APA_admin_192{7}: 10.72.254.0/24 === 192.168.0.0/16

Le problème est que ce n'est pas satisfaisant du point de vue de la sécurité.
Le comportement n'est pas prédictive.

Cordialement,

#2 Mis à jour par Guillaume PITARD il y a environ 11 ans

Re-bonjour,

Je pense avoir trouver la solution pour fixer l'IP source des trames émises par l'amon, mais je ne sais pas comment intégrer ça.
ip route add 10.0.0.0/8 via 'IP de ETH0' dev eth0 proto static src 'IP de ETH1'
ip route add 172.16.0.0/12 via 'IP de ETH0' dev eth0 proto static src 'IP de ETH1'
ip route add 192.168.0.0/16 via 'IP de ETH0' dev eth0 proto static src 'IP de ETH1'
ip route add 161.48.0.0/19 via 'IP de ETH0' dev eth0 proto static src 'IP de ETH1'

Cordialement,

#3 Mis à jour par Guillaume PITARD il y a environ 11 ans

En creusant un peu je pense vous avoir trouver une piste.

1) modif de /etc/strongswan.conf dans le paragraphe charon
Remplacer install_routes = yes
par install_route = no

2) modifier le script /etc/init.d/rvp
Ajouter dans le paragraphe start:
if [ $RETVAL -eq 0 ]; then
ip route add 10.0.0.0/8 via 10.172.253.253 dev eth0 proto static src 10.72.254.4
ip route add 172.16.0.0/12 via 10.172.253.253 dev eth0 proto static src 10.72.254.4
ip route add 192.168.0.0/16 via 10.172.253.253 dev eth0 proto static src 10.72.254.4
ip route add 161.48.0.0/19 via 10.172.253.253 dev eth0 proto static src 10.72.254.4
fi

Ajouter dans le paragraphe stop:
ip route del 10.0.0.0/8
ip route del 172.16.0.0/12
ip route del 192.168.0.0/16
ip route del 161.48.0.0/19

C'est un peu brute de fonderie, il faudrait que ce soit en cohérence avec ARV.

Bon courage.

#4 Mis à jour par Guillaume PITARD il y a environ 11 ans

La modif peut encore être plus light.
C'est même tellement light qu'on pourrait appeler ça du zéro.

Modifier uniquement le script /etc/init.d/rvp
en ajoutant simplement dans le paragraphe start:
if [ $RETVAL -eq 0 ]; then
ip route replace 10.0.0.0/8 via 'IP de ETH0' dev eth0 proto static src 'IP de ETH1'
ip route replace 172.16.0.0/12 via 'IP de ETH0' dev eth0 proto static src 'IP de ETH1'
ip route replace 192.168.0.0/16 via 'IP de ETH0' dev eth0 proto static src 'IP de ETH1'
ip route replace 161.48.0.0/19 via 'IP de ETH0' dev eth0 proto static src 'IP de ETH1'
fi

Bon maintenant, il faut arriver mettre ça en cohérence avec les modèles de liens sécurisés dans ARV, mais là je ne sais pas faire, à vous de jouer...

Cordialement,

#5 Mis à jour par Joël Cuissinat il y a environ 11 ans

  • Version cible changé de Mises à jour 2.3.8 à Mises à jour 2.3.9

#6 Mis à jour par Guillaume PITARD il y a environ 11 ans

Bonjour,

Fabrice m'a proposé par mail une solution qui me semble fonctionnelle, et qui me convient. Je la mets dans ce fil, ça permettra peut-être de l'avoir à la prochaine mise à jour Amon.

Cordialement.

MAIL de FABRICE :

Salut Guillaume,

Peux-tu me dire si ceci te convient :
À faire sur Amon uniquement.
Dans /etc/ipsec.d/ipsec_updown :
ligne 349 : décommenter #uproute
ligne 369 : décommenter #downroute
Dans /etc/strongswan.conf :
Remplacer la ligne 19 par : install_routes = no

Relancer rvp.

Le script ipsec_updown est lancé à chaque montée/descente de tunnel et installera/supprimera les routes forcée par IP eth1.
Les routes ne sont plus gérées par Strongswan (install_routes = no)

Attention, un reconfigure annulera les modifs. Si ça te convient, on pourra intégrer ceci.

--
Cordialement,
Fabrice Barconnière
Equipe EOLE

#7 Mis à jour par Fabrice Barconnière il y a environ 11 ans

  • Statut changé de Nouveau à En attente d'informations
  • Temps estimé mis à 0.25 h

Attente d'infos pour savoir si Guillaume est satisfait de cette solution et si il n'y a pas d'effets indésirables.

#8 Mis à jour par Fabrice Barconnière il y a environ 11 ans

  • Tracker changé de Anomalie à Evolution

#9 Mis à jour par Fabrice Barconnière il y a environ 11 ans

  • Projet changé de arv à conf-amon

#10 Mis à jour par Fabrice Barconnière il y a environ 11 ans

  • Echéance mis à 29/03/2013

#11 Mis à jour par Redmine Admin il y a environ 11 ans

  • Echéance changé de 29/03/2013 à 05/04/2013

#12 Mis à jour par Luc Bourdot il y a environ 11 ans

  • Echéance changé de 05/04/2013 à 04/04/2014

#13 Mis à jour par Guillaume PITARD il y a environ 11 ans

Salut Luc,

2014 c'est une erreur de frappe, rassures moi !!!

Cordialement,

#14 Mis à jour par Guillaume PITARD il y a environ 11 ans

Salut,

Après tests et re-test, je peux dire que la modification proposer par Fabrice est satisfaisante.

Désolé pour le retard, je pensais avoir déjà répondu.

Cordialement.

#15 Mis à jour par Gérald Schwartzmann il y a environ 11 ans

  • Statut changé de En attente d'informations à Accepté

#16 Mis à jour par Fabrice Barconnière il y a environ 11 ans

  • Statut changé de Accepté à Résolu
  • % réalisé changé de 0 à 100

#17 Mis à jour par Fabrice Barconnière il y a environ 11 ans

  • Echéance changé de 04/04/2014 à 12/04/2013

#18 Mis à jour par Fabrice Barconnière il y a environ 11 ans

  • Statut changé de Résolu à Fermé

Formats disponibles : Atom PDF