Client Openvpn et if-down.d

Support Debian
#1

Bonjour,

J’utilise openvpn (en ligne de commande) pour me connecter sur une machine distante. Tout fonctionne parfaitement bien, cependant, si la connexion se coupe (Soit parce que je fais la brute en enlevant le câble ethernet ou que ma box redémarre) lorsque que le réseau redémarre, mon tunnel est toujours là, complétement dans les choux. Je ne peux plus accéder à Internet (Mais il est toujours accessible en réseau local), j’en suis réduit à redémarrer.

Il me semble pourtant que script openvpn présent dans /etc/network/if-down.d/openvpn devrait automatiquement arrêter openvpn, non ? Ou alors j’ai mal compris ce que ce brave script fait.

Merci de vos éclaircissements.

#2

Salut,
Je crois ? que si openvpn est lancé en ligne de commande if-down ne fera rien.
Il faudrait qu’il soit démarré avec if-up pour que ça fonctionne.

#3

Salut Lol,

Ah ok. Je teste ce soir ta théorie. Merci du coup de main.

#4

Même pas. Les scripts dans /etc/network/if-down.d/ sont exécutés lors de l’arrêt “administratif” de la connexion, c’est-à-dire avec ifdown, pas lors d’une coupure sauvage.

#5

Et pour la coupure sauvage ? Une solution ?
Si je crée un script et que je mets un post-down mon-script dans /etc/network/interfaces j’ai bon ?

#6

Non, c’est pareil.

Mais il me semblait qu’openvpn était capable de se reconnecter automatiquement ?

#7

Bein écoute, d’après les tests que j’ai réalisé il n’en ai rien. Après mon fichier est peut-être mal fait, cependant mes recherches m’avaient conduit à l’argument “keepalive”. Je n’ai rien trouvé de plus.

C’est pas impossible aussi que j’ai mal configuré un truc.

#8

C’est ce qui se passe chez moi, ça retente jusqu’à ce que ça reconnecte.

#9

Lol, Tu as fait un truc en particulier pour que ça se reconnecte ? Ou juste l’argument keepalive dans ton fichier conf ?
Tu as testé avec une déco à la sauvage ?

Le plus bizarre moi, c’est que ça me fait complétement planter ma connexion à Internet. J’ai accès en local à ma machine, mais impossible de me connecter à Internet. Comme je disais, il faut que je redémarre pour que ça remarche. J’ai vérifié mon resolv.conf, il me semble pourtant correcte, et même en relançant mon ethernet “à la main” (ifup/ifdown) cela ne fonctionne pas. Hum… J’ai aucune idée, je vais continuer à creuse mais si vous avez des pistes, je suis preneur.

Merci.

#10

Bon du coup, j’ai fait différent test, mais toujours le même problème : Je démarre mon vpn, tout se passe bien, je débranche mon câble ethernet pour simuler une coupeur de courant (Qui a dit paranoïaque), je remets le câble…Et là, c’est la galère. La connexion sur le poste se fait difficilement et une fois établit, je n’ai plus d’accès à Internet. Je coupe le VPN et tue les process, rien n’y fait. Je obligé de redémarrer.

Une idée ?

PS : Faut-il que j’ouvre un nouveau sujets ?

Merci bien !!

#11

Salut,
Non rien de spécial.
Voici une conf que j’utilise:

client dev tun proto udp remote ip port resolv-retry infinite nobind persist-tun ca ca.crt cert serveur.crt key serveur.key comp-lzo verb 3 pull

#12

Merci Lol.
Bon après plusieurs tests, voilà mes conclusions : Si je coupe mon ethernet à la sauvage, mon VPN est dans les choux. Il n’arrive plus à résoudre d’adresse et donc il n’arrive plus à ce connecter.
J’ai pas trouvé de solution, faudrai que je fasse un script qui, à intervalle régulier, regarde si j’arrive à effectuer un ping de Google (Par exemple) et si c’est pas le cas, tue tous les process Openvpn.

#13

J’utilise régulièrement openvpn, je teste la connexion avec des ping et en cas de coupure, je redémarre juste le VPN via un «stop/start». Pas besoin de redémarrer les machines (heureusement en ce qui me concerne).

#14

Pour m’éviter de redémarrer, j’ai résolu le problème : je tue les processus openvpn.
Quand je stop openvpn parce que ce dernier s’est mis en carafe, il ne ferme pas tous ses processus. Une fois tout fermé, ma connexion revient.

Je pense que je vais faire comme toi, je ne vois que cette solution de toute façon.

#15

Note que si tu fais un vpn en udp, ça devrait supporter les coupures car il n’y a pas de connexion à proprement parler mais des écoutes.

#16

Si le client openvpn modifie la route par défaut pour qu’elle passe par le VPN, c’est peut-être cela qui cause le problème lors de la reconnexion.

#17

Il ne préserve pas sa «route»? Dans les scripts que j’ai fait, la route vers le serveur VPN était préservée, je pensais que c’était le cas pour une route par défaut mis par le VPN. Mais dans un tel cas, la connexion fevrait être immédiatement brisée dès la mise en place de la route non? Ou bien la modification ne concerne que les connexions à venir (comment ça se passe pour les réseaux en UDP dans ce cas?)

#18

Je fais confiance à openvpn pour préserver les routes liées à son interface tun. En revanche si l’interface ethernet est administrativement désactivée lorsque la liaison est coupée (cela dépend du gestionnaire de réseau) alors toutes les routes liées à cette interface sont supprimées. Or si openvpn modifie la route par défaut pour la faire passer par son interface tun, il est obligé de créer auparavant une route spécifique sur l’interface ethernet pour atteindre le serveur openvpn.

Je pensais donc à un scénario “catastrophe” du genre :

  • le gestionnaire de réseau détecte que la liaison ethernet est coupée et désactive administrativement l’interface ethernet, ce qui supprime la route vers le serveur openvpn mais laisse la route par défaut sur l’interface tun ;
  • la liaison remonte, le gestionnaire de réseau réactive l’interface ; deux choses peuvent faire que ça se passe mal :
  • il voit qu’il y a déjà une route par défaut (sur l’interface tun) et ne la modifie pas ;
  • comme la route vers le serveur openvpn n’est pas recréée, pas de communication possible sur le VPN.
#19

@Fran.b : D’après mon fichier de conf, je suis en udp.

@PascalHambourg : Ton scénario catastrophe peut-être une explication de ce qu’il se passe actuellement chez moi.
Je vais continuer de me pencher sur le sujet.

#20

La sortie de “ip route” ou “route -n” avant et après une coupure pourrait être instructive.

Autre source de problème possible, les DNS. Si openvpn importe ses propres DNS dans /etc/resolv.conf, ils peuvent être écrasés par le gestionnaire de réseau lors du rétablissement du lien.

Ce genre de situation où plusieurs programmes sont susceptibles de gérer les mêmes choses (interfaces, routes, DNS…) n’est pas simple.