Je souhaiterais garder wicd sur ma debian, mais pouvoir utiliser un vpn en PPTP (je suis sous XFCE donc j’aimerais éviter network-manager)…
J’ai vu que Wicd ne supportait pas le vpn.
Bref, pourrais-je créer un script qui, une fois wicd lancé, me connecterait au VPN?
Ou existerait-il un client VPN avec un gui?
Pour le script, auriez vous un exemple?
Merci.
Avec wicd tu peux définir des scripts à exécuter lors de la connexion à certains réseau (dans la liste des réseaux dispos, tu cliques sur “propriétés” puis sur “script”)
Merci Benji.
Une idée de la facon de configurer le vpn en script? (fichiers de conf., commande d’execution etc).
Ben ça dépend de quel vpn tu utilises ^^ Par exemple pour lancer mon vpn je fais juste openvpn /etc/openvpn/client.conf
Suivant le logiciel de vpn que t’utilises la conf varie fortement…
Un VPN PPTP n’est jamais qu’une connexion PPP, pas besoin de script. On crée un fichier d’options pour pppd /etc/ppp/peers/, on la démarre avec pon et on l’arrête avec poff . Il faut avoir les droits root ou faire partie du groupe dip.
Exemple de fichier d’options pour pppd :
user "lelogin"
password "lemotdepasse"
# c'est la qu'on indique l'adresse ou le nom d'hote du serveur PPTP
pty "/usr/sbin/pptp 10.0.0.138 --nolaunchpppd"
debug
noproxyarp
local
nocrtscts
hide-password
noauth
# decommenter si on veut que la connexion soit rétablie automatiquement après coupure
#persist
# negociation IPV6CP/IPv6 si dispo sur le serveur
ipv6 ,
# pas de negociation IPXCP/IPX
noipx
# l'adresse IP est fournie par le serveur
noipdefault
# decommenter pour installer une route par defaut via le VPN
# attention si le serveur n'est pas sur le reseau local !
#defaultroute
#replacedefaultroute
# decommenter pour utiliser les adresses de DNS fournies par le serveur
#usepeerdnsMerci beaucoup,
Pascal, en suivant tes recommandations, j’obtiens:
root@debian/etc/ppp/peers# tail -f /var/log/messages
Aug 19 19:37:34 horgh pppd[3717]: Connection terminated.
Aug 19 19:37:34 horgh pppd[3717]: Using interface ppp0
Aug 19 19:37:34 horgh pppd[3717]: Connect: ppp0 <–> /dev/pts/2
Aug 19 19:37:34 horgh pppd[3717]: Modem hangup
Aug 19 19:37:34 horgh pppd[3717]: Connection terminated.
Aug 19 19:37:34 horgh pppd[3717]: Using interface ppp0
Aug 19 19:37:34 horgh pppd[3717]: Connect: ppp0 <–> /dev/pts/2
Aug 19 19:37:34 horgh pppd[3717]: Modem hangup
Aug 19 19:37:34 horgh pppd[3717]: Connection terminated.
Aug 19 19:37:34 horgh pppd[3717]: Exit.
Une idée?
Juste pour être sûr, le paquetage pptp-linux est bien installé ?
Oups, je l’avais désinstallé lors d’une précédente manip.
Une fois installé, j’obtiens:
Aug 19 20:21:38 horgh pppd[6168]: Modem hangup
Aug 19 20:21:38 horgh pppd[6168]: Connection terminated.
Aug 19 20:21:38 horgh pppd[6168]: Using interface ppp0
Aug 19 20:21:38 horgh pppd[6168]: Connect: ppp0 <–> /dev/pts/2
Aug 19 20:21:40 horgh pppd[6168]: CHAP authentication succeeded
Aug 19 20:21:40 horgh pppd[6168]: LCP terminated by peer (MPPE required but peer negotiation failed)
Aug 19 20:21:40 horgh pppd[6168]: Modem hangup
Aug 19 20:21:40 horgh pppd[6168]: Connection terminated.
je soupconne que mon encryption n’est pas activée.
A y’est, ca fonctionne, il manquait l’encryption. Merci bcp.
J’ai bien acquis une IP publique au travers du VPN, comme le montrent les logs, par contre un check de mon IP sur les sites internet me montre toujours l’IP de mon FAI.
Etrange, je pense qu’il faut que je route mes flux vers PPP0.
Comment pourrais-je réaliser ce routage?
[quote=“isterios”]A y’est, ca fonctionne, il manquait l’encryption.
J’ai bien acquis une IP publique au travers du VPN, comme le montrent les logs, par contre un check de mon IP sur les sites internet me montre toujours l’IP de mon FAI.
Etrange[/quote]
Verifie tes routes (routes -n)
P’tet qu’il faut que tu changes la route par défaut pour que les paquets empruntent le VPN, au lieu de la passerelle habituelle de ton reseau local.
Normal si la route par défaut n’est pas modifiée.
Pour que les communications vers l’extérieur passent dans le VPN, il faut que la route par défaut pointe sur l’interface PPP. C’est le but de l’option defaultroute qui est commentée dans mon exemple. Le flag replacedefaultroute, également commenté, est nécessaire en plus s’il y a déjà une route par défaut, sinon pppd ne la remplace pas. (A noter que ce flag est spécifique à un patch appliqué par certaines distributions comme Debian, il n’est pas supporté par la version upstream de pppd.)
Mais, me direz-vous, survient un problème si la route par défaut doit être remplacée et si la route par défaut initiale est nécessaire pour atteindre le serveur VPN. Vous voyez l’idée : pour envoyer un paquet dans le VPN il faut l’encapsuler et l’envoyer au serveur VPN, mais si pour atteindre le serveur VPN il faut prendre la route par défaut et que celle-ci passe par le VPN… oups ! Heureusement pour nous, pptp nous sort de ce mauvais pas en créant une route vers l’adresse du serveur VPN indépendante de la route par défaut.
[quote=“PascalHambourg”]Normal si la route par défaut n’est pas modifiée.
Pour que les communications vers l’extérieur passent dans le VPN, il faut que la route par défaut pointe sur l’interface PPP. C’est le but de l’option defaultroute qui est commentée dans mon exemple. Le flag replacedefaultroute, également commenté, est nécessaire en plus s’il y a déjà une route par défaut, sinon pppd ne la remplace pas. (A noter que ce flag est spécifique à un patch appliqué par certaines distributions comme Debian, il n’est pas supporté par la version upstream de pppd.)
Mais, me direz-vous, survient un problème si la route par défaut doit être remplacée et si la route par défaut initiale est nécessaire pour atteindre le serveur VPN. Vous voyez l’idée : pour envoyer un paquet dans le VPN il faut l’encapsuler et l’envoyer au serveur VPN, mais si pour atteindre le serveur VPN il faut prendre la route par défaut et que celle-ci passe par le VPN… oups ! Heureusement pour nous, pptp nous sort de ce mauvais pas en créant une route vers l’adresse du serveur VPN indépendante de la route par défaut.[/quote]
Merci bcp.
Je dois donc ajouter la syntaxe suivante?:
#defaultroute
replacedefaultroute ppp
Car en faisant ceci, j’obtiens:
/usr/sbin/pppd: pty option precludes specifying device name
Il faut aussi décommenter defaultroute, dont la ligne suivante ne fait que modifier le comportement.
Voici mes routes:
93.x.x.x = IP de mon VPN
192.x.x.x = routeur
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
93.182.133.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.164.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.190.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.186.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.153.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.180.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.149.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.151.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.147.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.130.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.189.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.187.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.152.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.185.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.181.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.148.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.150.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.146.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.146.2 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
93.182.179.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
192.168.123.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 192.168.123.1 0.0.0.0 UG 0 0 0 wlan0
0.0.0.0 0.0.0.0 0.0.0.0 U 1002 0 0 eth0
Un check de mon IP publique internet donne mon FAI: 88.x.x.x
defaultroute ppp
replacedefaultroute
ok, j’obtiens toujours:
/usr/sbin/pppd: pty option precludes specifying device name
Ho le bazar dans la table de routage ! On dirait que pptp oublie de supprimer la route vers le serveur quand il s’arrête. A moins qu’il ne s’arrête pas ? Que dit ps aux | grep “pp[tp]” ?
Par contre la route “93.182.146.2 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0” n’est pas normale, c’est toi qui l’as ajoutée ?
Pourquoi avoir ajouté “ppp” derrière “defaultroute” ? Il ne me semble pas avoir écrit de le faire.
[quote=“PascalHambourg”]Ho le bazar dans la table de routage ! On dirait que pptp oublie de supprimer la route vers le serveur quand il s’arrête. A moins qu’il ne s’arrête pas ? Que dit ps aux | grep “pp[tp]” ?
Par contre la route “93.182.146.2 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0” n’est pas normale, c’est toi qui l’as ajoutée ?
Pourquoi avoir ajouté “ppp” derrière “defaultroute” ? Il ne me semble pas avoir écrit de le faire.[/quote]
Bingo.
Merci Pascal, je pensais qu’il fallait indiquer le périphérique pour la route par défaut.
Maintenant, c’est bon.
Voici mes routes (non je n’ai rien modifié personnellement):
Destination Gateway Genmask Flags Metric Ref Use Iface
93.182.133.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.133.2 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
93.182.164.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.190.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.186.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.153.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.180.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.149.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.151.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.147.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.130.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.189.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.187.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.152.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.185.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.181.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.148.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.150.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.146.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
93.182.179.2 192.168.123.1 255.255.255.255 UGH 0 0 0 wlan0
192.168.123.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
0.0.0.0 0.0.0.0 0.0.0.0 U 1002 0 0 eth0
Ca te semble toujours anormal? (eth0 n’est pas utilisé).
root@debian:/usr/bin# ps aux | grep "pp[tp]"
root 1991 0.0 0.0 10184 668 ? Ss 19:17 0:00 /usr/sbin/pptpd
root 10633 0.0 0.0 21564 1152 ? Ss 21:26 0:00 /usr/sbin/pppd call ipredator
root 10635 0.0 0.0 3948 572 ? S 21:26 0:00 sh -c /usr/sbin/pptp vpn.ipredator.se --nolaunchpppd
root 10638 0.0 0.0 14328 940 ? S 21:26 0:00 /usr/sbin/pptp vpn.ipredator.se --nolaunchpppd
root 10646 0.0 0.0 14328 556 ? S 21:26 0:00 /usr/sbin/pptp vpn.ipredator.se --nolaunchpppd
Je crois que je comprends.
Le nom de domaine du serveur VPN, vpn.ipredator.se, se résoud en une ribambelle d’adresses IP (qui se ressemblent à un chiffre près, et je n’avais pas vu qu’elles étaient différentes), et apparemment pptp crée des routes pour toutes ces adresses plutôt que seulement pour celle à laquelle il va effectivement se connecter. Admettons.
Je soupçonne que l’adresse de pair PPP négociée par le serveur est identique à son adresse pour la connexion PPTP ; en d’autre termes, son adresse à l’extérieur du tunnel et son adresse dans le tunnel sont identiques (vérifier avec ifconfig l’adresse P-t-P de l’interface ppp, ou dans le log de pppd à la ligne “remote IP address”). C’est AMA très risqué, car cela crée sur le client deux routes contradictoires qui sont ici de même priorité/métrique, avec gros risque de confusion. Si jamais la “bonne” route venait à expirer dans le cache de routage (si le VPN dure longtemps), lors de son rafraîchissement il y aurait un risque qu’elle soit remplacée par la “mauvaise” route et le VPN ne fonctionnerait plus. J’ai moi-même un serveur PPTP, et je me suis bien gardé de faire ça.
Edit: si cela se révèle être effectivement un problème j’ai une solution en réserve, mais il faut mettre les mains dans le cambouis de pppd alors inutile de s’embêter par avance dans le cas contraire.
Un grand merci Pascal pour ton aide, je vais surveiller ça de près.
Et merci bcp pour toutes tes explications.