Salutations,
J'utilise vpnc
pour un client VPN. Je fais aussi des choses délicates avec route
pour m'assurer que je peux toujours accéder à mon réseau local, etc. etc. (les détails ici ne sont pas très importants).
Parfois, je reçois la table de routage, donc je suis surélevé, je reçois ping: sendto: Network is unreachable
pour les URL qui devraient autrement être résolues.
Actuellement, si je redémarre Mac OS X, tout redevient normal. Ce que je voudrais faire, c'est réinitialiser les tables de routage à la "valeur par défaut" (par exemple, ce qu'il est défini au démarrage) sans un redémarrage complet du système .
Je pense que l'étape 1 est route flush
(pour supprimer toutes les routes). Et l'étape 2 doit recharger toutes les routes par défaut.
Des idées sur la façon de faire cela? (par exemple, qu'est-ce que l'étape 2?)
MODIFIER De plus, je remarque qu'un autre symptôme est que traceroute
échoue également sur l'adresse en question. Par exemple:
traceroute the.good.dns.name
traceroute: bind: Can't assign requested address
Vous devez vider les routes. Utilisez route -n flush plusieurs fois. Ajoutez ensuite vos itinéraires avec route add.
Je rencontrais ce problème lors de l'utilisation d'un serveur OpenVPN domestique et de la connexion à celui-ci à l'aide de l'application Tunnelblick sur Mac.
Ce qui se passait de mon côté, c'est qu'un itinéraire avec mon adresse IP domestique comme destination et une passerelle incorrecte restait après la déconnexion du VPN. La suppression de cet itinéraire a résolu le problème, simplement
$ Sudo route -n delete the.good.dns.name
Exemple: je suis à l'école et après un nouveau démarrage de l'ordinateur, je me connecte à un réseau sans fil. Je me connecte à mon serveur OpenVPN domestique avec Tunnelblick.
$ netstat -nr
Destination Gateway
....
[home-ip]/32 [school-default-gateway-1] ....
....
Je me déconnecte du serveur VPN. Je change de réseau sans fil. Cela change ma passerelle par défaut.
$ netstat -nr
Destination Gateway
...
[home-ip]/32 [school-default-gateway-1] ...
...
$ ping [home-ip]
PING [home-ip]: 56 data bytes
ping: sendto: Network is unreachable
ping: sendto: Network is unreachable
Request timeout for icmp_seq 0
...
Je ne peux en aucun cas me connecter à mon réseau domestique (VPN, ping, quoi que ce soit) après cela. Si je supprime ensuite l'itinéraire:
$ Sudo route -n delete [home-ip]
delete net [home-ip]
$ ping [home-ip]
PING [home-ip]: 56 data bytes
64 bytes from [home-ip]: icmp_seq=1 ttl=56 time=13.111 ms
Ça fonctionne bien.
Il peut y avoir un problème avec la configuration du serveur/client OpenVPN qui laisse cela (et je serais intéressé de savoir ce que c'est), mais j'ai installé un script de déconnexion Tunnelblick qui automatise cette suppression de route.
Vous avez d'abord besoin d'un itinéraire pour votre interface réseau. Si le VPN est déconnecté, il vous suffit de retirer votre interface réseau et de la réactiver avec ifconfig. Utilisez ensuite la commande route pour créer votre gw par défaut. Donc quelque chose comme:
ifconfig en0 down
ifconfig en0 up
route add <ip address> default
Je rencontrais le même problème que @Sean (j'utilise également OS X), en ce sens que lorsque je basculais entre les réseaux domestique et professionnel, l'itinéraire par défaut n'était pas supprimé.
Pour être complet, lorsque je me connecte à mon VPN à la maison et que j'exécute la commande suivante, cela affichera la passerelle par défaut comme ci-dessous
$ netstat -nr
Destination Gateway
...
[home-ip]/32 [work-default-gateway-1]
Et quand je me suis déconnecté, la passerelle [home-ip] serait toujours là. Lorsque je me connectais à mon réseau de travail, je ne pouvais pas du tout me connecter à Internet et je rencontrais le même problème que OP
$ traceroute the.good.dns.name
$ traceroute: bind: Can't assign requested address
Je devrais ensuite supprimer manuellement l'itinéraire avec
$ Sudo route -n delete [home-ip]
Au départ, je mets la "route -n supprimer" dans un post-disconnect.sh
script, mais c'était un peu compliqué donc j'ai trouvé ce lien
https://code.google.com/p/tunnelblick/issues/detail?id=177
Apparemment, la raison est due à la configuration de ce qui suit dans mon .ovpn
fichier
user nobody
group nogroup
Ce qui signifie que l'itinéraire est configuré en tant que root, mais lorsque la connexion est interrompue, l'utilisateur n'est plus root, donc l'itinéraire ne peut pas être supprimé.
Commentant ces 2 lignes dans mon .ovpn
fichier a résolu le problème, sans avoir à utiliser un post-disconnect.sh
.