Bonjour les moules,
Je m'arrache les cheveux depuis quleques mois sur ce sujet, qui de plus m'empêche de télétravailler sérieusement. En y répondant, vous me sauverez de la calvitie et m'économiserez des euros de gasoil. Euh, ferez un geste pour la planète. J'expose donc les symptômes:
Pour me connecter au vpn de ma société, j'utilise vpnc:
vpnc version 0.5.3
...
Supported DH-Groups: nopfs dh1 dh2 dh5
Supported Hash-Methods: md5 sha1
Supported Encryptions: null des 3des aes128 aes192 aes256
Supported Auth-Methods: psk psk+xauth hybrid(rsa)
ou le clickodrôme NetworkManager fourni avec ubuntu/gnome. (NetworkManager Applet 0.8).
La connection s'établit et tient 30 à 40 secondes, avant de se blo
Ça bloque également le trafic internet normal.
J'ai pas mal joué avec les différentes configs et je déserspérais de la situation, et puis j'ai essayé d'ailleurs que chez moi (un connection wifi sur un boitier ne passant pas par du xDSL). Et là, miracle, ça marche super.
Je me dis donc que cela doit venir de la freebox (testé derrière d'autres freebox avec le même résultat décevant, mais pas d'autres opérateurs/box). Je me suis assigné une IP fixe et forwardé le port TCP 1723. La box est en mode routeur, j'ai plusieurs machines derrière. J'ai fouillé le grand ternet mais je reste broucouille.
Une idée ? Une piste ? Une solution ? 100 balles ? Un mars ?
# pas compris
Posté par NeoX . Évalué à 3.
alors que c'est toi qui essaie de te connecter vers l'exterieur...
à tout hasard, tu n'aurais pas garder le wifi et le filaire actif en meme temps ?
du coup ton PC ne sait plus par quelle porte sortir pour aller quelque part ?
[^] # Re: pas compris
Posté par Obi MO (site web personnel) . Évalué à 2.
sudo ifconfig eth2 down, ça ne change rien. À tout hasard, voici le résultat d'un ifconfig:eth1 Link encap:Ethernet HWaddr 00:1f:3c:2c:7d:2c inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::21f:3cff:fe2c:7d2c/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:317806 errors:0 dropped:0 overruns:0 frame:0 TX packets:249718 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:358326990 (358.3 MB) TX bytes:37372648 (37.3 MB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:50822 errors:0 dropped:0 overruns:0 frame:0 TX packets:50822 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:6617608 (6.6 MB) TX bytes:6617608 (6.6 MB) virbr0 Link encap:Ethernet HWaddr c6:31:f8:29:dd:35 inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 inet6 addr: fe80::c431:f8ff:fe29:dd35/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:178 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:35789 (35.7 KB)L'interface filaire eth2 est bien désactivée puisqu'elle n'apparaît pas. D'un autre côté je ne vois pas pourquoi il n'y aurait conflit entre le filaire et le wifi que chez moi et pas chez mon collègue, sachant que c'est la même machine, les deux fois par wifi. Et surtout pourquoi ça marche pendant 30 secondes avant de tout bloquer. J'en suis venu à faire des scripts pour découper mes commandes svn par bouts de 35 secondes:#!/bin/bash sudo vpnc-disconnect while true do killall -9 svn svn cleanup find . -name log -exec rm '{}' \; sudo vpnc-connect XXX $* & sleep 35 sudo vpnc-disconnect doneCe qui est particulièrement sale et pas anodin pour svn, en témoigne le nettoyage systématique que je dois faire à chaque tour. Sans parler des services autres que svn dont j'ai besoin. Bref, je sèche.# Manque probablement des ports ...
Posté par DonKiShoot (site web personnel) . Évalué à 2.
[^] # Re: Manque probablement des ports ...
Posté par Obi MO (site web personnel) . Évalué à 1.
# DPD?
Posté par nek . Évalué à 3.
Le lien suivant pointe sur un problème ressemblant au tiens et propose une solution :
http://www.novell.com/communities/node/6352/fixing-vpnc-disc(...)
[^] # Re: DPD?
Posté par Obi MO (site web personnel) . Évalué à 1.
DPD idle timeout (our side) 0
# MTU
Posté par ruz revr . Évalué à 2.
Voilà juste une piste comme ça. J'ai déjà eu des bizarreries en utilisant OpenVPN au-dessus d'une connection FreeWifi avec un MTU de 1500 (par défaut). En mettant le mtu à 1460, c'est beaucoup mieux.
[^] # Re: MTU
Posté par Obi MO (site web personnel) . Évalué à 1.
Le MTU était déjà à 1460, je l'ai baissé à 1300, sans effet notable.
J'ai suivi la procédure suivante, on y voit 9 pings qui passent puis les suivants perdus :
$sudo vpnc-connect esterel
Connect Banner:
| Warning ! You are now connected to XXX Private Network.
|
VPNC started in background (pid: 21958)...
$ sudo ifconfig tun0 mtu 1300
$ ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.168.20.30 P-t-P:192.168.20.30 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1300 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:858 (858.0 B) TX bytes:542 (542.0 B)
$ ping fauve
PING fauve.XXXX (192.168.10.5) 56(84) bytes of data.
64 bytes from fauve.XXXX (192.168.10.5): icmp_seq=1 ttl=127 time=45.5 ms
[...]
64 bytes from fauve.XXXX (192.168.10.5): icmp_seq=9 ttl=127 time=45.6 ms
^C
--- fauve.XXXX ping statistics ---
15 packets transmitted, 9 received, 40% packet loss, time 14046ms
rtt min/avg/max/mdev = 45.172/45.779/47.007/0.578 ms
# une idée, peut-etre...
Posté par NeoX . Évalué à 3.
si le bail est tres court, il est renouvelé souvent
=> les routes et les DNS aussi
il ne faudrait pas la route "au travers du vpn" saute car la carte reseau reprend sa route par defaut en renouvellant son bail.
[^] # Re: une idée, peut-etre...
Posté par Obi MO (site web personnel) . Évalué à 2.
[^] # Re: une idée, peut-etre...
Posté par NeoX . Évalué à 3.
telle IP
tel masque
telle route
si c'est le DHCP qui fixe ton IP, oui, y a toujours un bail
car ta machine va continuer d'interroger le reseau pour verifier qu'elle ne doit pas rendre l'IP
[^] # Re: une idée, peut-etre...
Posté par Obi MO (site web personnel) . Évalué à 1.
[http://www.freenews.fr/local/cache-vignettes/L400xH613/4-ea3(...)] )
Et que dans les paramètres de ma machine, je dois virer DHCP pour le passer en mode manuel ?
Merci du conseil, j'essaye tout ça ce soir.
[^] # Re: une idée, peut-etre...
Posté par NeoX . Évalué à 2.
[^] # Re: une idée, peut-etre...
Posté par nono14 (site web personnel) . Évalué à 1.
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
# Route par défaut
Posté par Benoit . Évalué à 1.
J’ai déjà constaté que l’application d’une nouvelle route peut prendre un peu de temps sous Linux (normalement quelques secondes pas 30 ou 40) pour les connections déjà établies. Si la route statique vers la passerelle VPN n’est pas ajoutée, la connexion vers celle-ci passe par l’ancienne route par défaut, puis après un certain temps par la nouvelle ajoutée par NetworkManager (ce qui ne peut pas marcher car cela revient à faire passer les paquets à destination de la passerelle VPN par la connexion VPN).
C’est juste une idée comme ça.
[^] # Re: Route par défaut
Posté par Obi MO (site web personnel) . Évalué à 1.
[^] # route -n
Posté par nono14 (site web personnel) . Évalué à 1.
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: Route par défaut
Posté par Benoit . Évalué à 1.
Pour moi, le problème vient de la route suivante :
192.168.0.0 * 255.255.255.0 U 0 0 0 tun0car elle est prioritaire sur la route (métrique plus faible) :192.168.0.0 * 255.255.255.0 U 2 0 0 eth1Les paquets à destination de 192.168.0.0/255.255.255.0 passent prioritairement par tun0 (le VPN). Hors ta passerelle par défaut (192.168.0.254) (qui est également la passerelle vers la passerelle VPN (213.30.139.86 ou reverse.complet)) est joignable par cette route. Les paquets à destination de la passerelle VPN sont routés par le VPN (ce qui ne peut pas marcher).
Immédiatement après l’établissement de la connexion VPN, essaye un truc du genre :
route del -net 192.168.0.0 netmask 255.255.255.0 dev tun0Ne maîtrisant pas vraiment NetworkManager, je ne peux pas t’aider pour trouver une solution durable.[^] # Re: Route par défaut
Posté par Benoit . Évalué à 2.
Au niveau de la Freebox, essaye de changer ton adresse de réseau pour être 192.168.100.0/255.255.255.0. La Freebox devient alors 192.168.100.254 et ta machine 192.168.100.1.
Si après cette modification, tu as toujours ton problème de double route, essaye d’ajouter la commande :
route add -host 192.168.0.254 dev eth1ou (en fonction de l’adresse de la Freebox) :route add -host 192.168.100.254 dev eth1Tu ne verra plus ton réseau local, mais est-ce grave ?
[^] # Re: Route par défaut
Posté par Obi MO (site web personnel) . Évalué à 1.
Quelle quiche, j'avais pas remarqué les adresses réseau cibles et destinations étaient sur le même sous réseau. Mais les moules ont un oeil de lynx (étrange animal, non ?)
Merci à tous ceux qui se sont penchés sur le problème. À moi les joies du télétravail devant la cheminée tandis que le reste des Yvelines joue à Holliday On Ice sur les routes enneigées ! Si vous êtes dans la région, et que ça vous dit, ça vaut largement une paire de bières ...
[^] # Re: Route par défaut
Posté par Benoit . Évalué à 2.
C’est l’inverse, les adresses IP ne sont plus résolue (résolution inverse) en nom de domaine, car tu ne peux plus joindre le DNS de ton fournisseur d’accès. Ces tentatives de connexion infructueuses expliquent le temps pris pour afficher les routes.
[^] # Un grand classique
Posté par nono14 (site web personnel) . Évalué à 2.
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.