SMPFR

salut

Je rencontre depuis peu un probleme avec openvpn sur une configuration que j'essaye de mettre en place.
pour faire simple, j'ai 2 machines sous debian, avec un lan derrière chacune.
- la debian1 a 3 interfaces: eth0 pour le lan, eth1 pour le net (route par défaut) et eth2 pour une 2e connexion internet. c'est sur cette machine qu'openvpn tourne en serveur
- la debian2 a 2 interfaces, eth0 pour le lan et eth1 pour acceder au net. son openvpn agit en tant que client pour aller se connecter sur la debian1.


Le souci est que si on ne force pas openvpn a écouter sur une ip/interface en particulier, il sort par la route par défaut, quelque soit les reglages qu'on ait fait, notemment avec ip route 2

Si depuis la debian2, j'essaye de contacter la debian1 sur sa 1è interface, pas de soucis.
Si depuis la debian2, j'essaye de contacter la debian1 sur sa 2e interface, elle me repond par la 1e interface... donc forcément ca marche pas

Mon but serait de pouvoir utiliser les 2 connexions de maniere a ce que si la première tombe, le client puisse se connecter sur la 2è.
(sur le client, on peut définir plusieurs remote ou se connecter, docn pas de soucis de ce coté, testé et approuvé)

Après mult recherches sur le net, il apparait que c'est un bug connu de openvpn... qui malgré tous les reglages qu'on ait pu faire, repondra par la route par défaut.
Sur la debian1, j'ai des regles faites avec iproute2, et des applis qui ecoutent sur les 2 interfaces (nginx, bind) et pas de souci, elles répondent bien sur l'interface d'ou vient la requete. seul openvpn est concerné par ce souci)

quelqu'un a deja eu ce souci et trouvé une solution ?

merci d'avance

Salut

tu peux pas aggréger eth1 et eth2 pour créer une interface réseau en failover ?

Je sais pas si c'est possible sous linux, sous bsd je m'en sers tout le temps.

Enfin d'après la doc

--local host
Local host name or IP address for bind. If specified, OpenVPN will bind to this address only. If unspecified, OpenVPN will bind to all interfaces.

Le bug n'est toujours pas corrigé ? :/

ouais voila, suis obligé d'utiliser "local a.b.c.d" si je ne le met pas sur l'ip par défaut.
en fait c'est pas l'interface qu'il aime pas mais juste l'ip.
meme avec une seule interface vers le net, et 2 ip dessus, une en eth1 et l'autre en eth1:0 par exemple, le probleme est le meme.
(j'ai testé sur ma dedibox qui est dans ce cas la une ip + 1 en alias, et c'est pareil)
donc l'aggregation, bien que possible sous debian, ne résoudrait pas le problème je pense.

edit: ma dedibox etant en ubuntu server 10.04, la version d'openvpn est plus recente que sur ma debian. meme en activant l'option --multihome, le comportement ne change pas

et si tu fais un push route vers les clients ?

yop
oui j'ai deja des push route pour que le client puisse atteindre le lan derriere mon serveur.
mais pas sur de voir comment ça pourrait aider openvpn a repondre sur la bonne ip

ah le problème c'est que sur eth1 et eth2 t'as directement l'ip publique et qu'elle est dynamique ? Du coup en cas de déco tu dois ressaisir l'adresse ?


Et quand je parlais d'aggrégation, je parle pas d'alias de plusieurs adresses sur une même carte réseau, mais de créer une interface virtuelle qui permet de faire du failover ou round-robin avec plusieurs interfaces réseaux

non non, l'ip est fixe (quand meme, une ip dynamique sur une connexion pro ça la fout mal )
@zplay, vi j'avais bien compris mais peu importe que soit soit plusieurs ip en alias sur une meme interface, ou plusieurs interfaces
le probleme est juste que openvpn repond sur l'ip par défaut, quelle que soit l'ip par laquelle se connecte le client

ta debian2 a aussi une IP publique fixe ?

Si oui, solution moche mais qui marche, tu ajoutes une route statique sur debian1 pour forcer les paquets à destination de debian à passer par la bonne interface

fightinh_falcon> deja tenté
ça ne marche pas car openvpn force sa réponse sur l'ip par défaut, et se fiche des reglages et routes que tu as pu faire auparavant :/

bon sinon... roulement de tambours... j'ai trouvé ZE solution, propre et fonctionnelle
- aller choper la derniere version d'openvpn (2.1.3, telechargeable ici)
- on chope aussi la derniere version de la librairie LZO pour la compression

on installe lzo puis on compile openvpn on ne fait surtout pas un "make install", y'a une feinte
on arrete le service openvpn, et on remplace juste le binaire (on sauvegarde l'ancien par précaution) pis on active l'option mulithome dans /etc/defaults/openvpn et on relance le bouzin.
je viens de tester sur ma dedibox qui a plusieurs IP. auparavant ca ne marchait pas. avec cette version c'est good
reste plus qu'à tester sur ma debian de prod

ps: j'ai testé les version par défaut sur debian lenny, ubuntu 10.04 et elles ne sont pas assez récentes pour ne plus avoir ce bug. seule la version de squeeze fonctionne.
sinon faut aller chercher la bonne version comme indiqué plus haut

bon, openvpn mis à jour sur mon serveur et ça roule
ça tombe bien car peu apres, ma 1e connexion est tombée pendant 2/3 minutes...
20 secondes après la coupure, mon autre debian s'est reconnectée toute seule comme une grande via la 2è connexion
c'est beau la redondance automatique

allez on continue dans le theme de la redondance, en ajoutant une cerise sur le gateau: OSPF
la j'ai plusieurs machines virtuelles pour simuler mes routeurs, avec la meme conf que les physiques, histoire de faire une maquette.
j'ai installé ospf et l'ai testé dans tous les sens, ça marche plutot bien et c'est vraiment pas mal du tout que de choisir la route la plus courte ainsi qu'un autre route si un routeur ou une liaison tombe

je tente maintenant de mixer openvpn et ospf.... et la ça coince :/
des que je pose un openvpn entre 2 machines, elles se voient normalement, pingent, etc... mais ospf m'arrive pas à les detecter....
un "show ip ospf neighbor" ne me renvoie rien
le reseau openvpn a la config standard en 10.8.0.0/4, déclaré comme area0, ou backbone, dans ospf
mes 2 routeur ont le lan sur eth0 et internet sur eth1

dans mon ospfd.conf j'ai et sur le router de l'autre coté du tunnel
pour l'instant je fais simple en n'ayant que 2 routeurs, après j'en rajouterai pour tout tester de manière progressive

y'a t il une ame charitable dans l'assistance qui aurait une idée ?

bon, je continue à debugger mon bazar

fw1 est le serveur openvpn et a une ip en 10.8.0.1
fw2 est le client openvpn et a une ip en 10.8.0.6

dans zebra.conf, j'ai mis un "ip route network/24 10.8.0.x" pour que chacun puisse atteindre le lan de l'autre, ça c'est bon

par contre, quand sur l'un ou l'autre, je lance un tcpdump -i tun0 pour voir les hello en ospf, je les vois bien passer :
mais pourtant ospf ne le reconnait pas, et aucune liaison de voisinage ne s'établit

dans la conf openvpn, remplacer "dev tun" par "dev tap"
ça marche vaaaaachement mieux

edit: en mode "tun", l'interface est montée en point-à-point avec un masque à 255.255.255.255.
donc pas de broadcast, donc pas d'ospf

Respect pour le taf.

marci ms'ieur mais c'pas fini !

maintenant que ospf roule entre les 2 debian par openvpn, j'en pose un 3è à coté du 2è, relié également au 1er par openvpn, et au 2è par ethernet
(le 2è et 3è sont sur le meme site, contrairement au 1er, d'ou la redondance obligatoire)

voila en gros mon chti réseau ( oui c'est bien paint, qui ose dire le contraire )


FW1 a 1 connection au lan + 2 connections internet
FW2 et FW3 ont chacun une connection au lan + 1 connection internet + 1 connection openvpn à FW1
ces 2 derniers publient leur route par défaut via ospf (ajouter la ligne default-information originate dans ospfd.conf)

j'ai également ajouté un heartbeat entre FW2 et FW3

au final :
- si la 1e connexion internet de FW1 tombe, FW2 et FW3 se reconnectent automatiquement en openvpn sur la 2e connexion de FW1
- si FW2 tombe, FW3 prend son ip et tout passe par lui, et vice versa
- si seule la connection internet de FW2, alors il reroute tout par FW3, grâce aux routes publiées par OSPF. et vice versa

maintenant, j'arrive à faire marcher tout ça dans mes machines virtuelles (3 pour chaque firewall, +1 pour simuler la connection internet, + encore 2 pour simuler une machine dans LAN1 et LAN2. soit 6 machines virtuelles en meme temps, c'est rigolo )

Bref, merci l'open source, Debian, openvpn et heartbeat. sans vous le monde serait nul

Bref, merci l'open source, Debian, openvpn et heartbeat. sans vous le monde serait nul

+ Gogolplex

Et oui, magnifique taf truc de ouf