Installer un client vpn pptp + deluge

Support Debian
#1

Bonjour à tous,

J’ai installé une raspbian jessie sur lequel tourne un demon Deluge et son interface web. l’installation est faite avec un utilisateur dédié afin de mettre en place un filtrage/routage dans iptables
Un tunnel vpn pptp est également en place.

Le tout tourne lorsque je lance un script maison en root à la main.
Mais quand j’essaie d’automatiser rien ne fonctionne… d’où ce post…

Je pense que mon erreur doit être plus grosse que moi mais je ne la vois pas !

Pour faire simple, je vais procéder par étape. Pis comme cela ça pourra aider d’autres personnes qui souhaitent mettre en place la même chose.

Donc phase 1 : le tunnel VPN
Je me suis inscris chez un fournisseur pour le VPN (je ne sais pas si je peux donner son nom donc je m’abstiens…)
J’ai installé et paramétré un client pptp via ces 2 lignes de commande :

sudo apt-get install -y pptp-linux
sudo pptpsetup --create <###NOM_DU_TUNNEL###> --server <##URL_DU_SERVEUR###> --username <##VOTRE_LOGIN###> --password <##VOTRE_MOT_DE_PASSE###> --encrypt --start

A la mimine, on peut ouvrir le tunnel via

sudo pon <###NOM_DU_TUNNEL###>

Et le fermer via

sudo poff <###NOM_DU_TUNNEL###>

1er problème : Si je souhaite mettre en place le tunnel au boot via le script ci-dessous dans /etc/network/interfaces, ben ca marche pô !

auto vpn
iface vpn inet ppp
provider <###NOM_DU_TUNNEL###>

Quand je fais un ifconfig -s, je n’ai pas de trace du tunnel.

Quelqu’un aurait une idée ?
merci

#2

Est-ce que

monte le VPN ?

Si oui, le réseau normal est-il opérationnel au démarrage avant que le VPN soit monté ?
Comment le réseau normal est-il configuré ?

#3

Salut
Je te remercie pour ta contribution.
La commande

monte bien le vpn…

Pour le réseau normal, rien de spécial. Je me connecte en wifi. Tout est laissé par défaut depuis l’installation de l’OS sauf le fichier /etc/wpa_supplicant/wpa_supplicant.conf où j’y ai mis les infos de connection à mon wifi (SSID/MDP)

l’IP local est definie par le serveur dhcp de mon routeur.

Ah au fait, j’ai fait un test simple:
si je mets un script à l’arrache via init.d du genre :

sleep 10
pon <### MON_VPN###>
sleep 30

là ça fonctionne…
J’pige plus rien…

#4

D’accord, mais qu’est-ce qui active et configure le wifi ? ifupdown (basé sur /etc/network/interfaces), NetworkManager, systemd, autre ?

#5

Pas NetworkManager car pas installé.
Comme ça et par habitude,j’aurais dit interfaces mais comme c’est une jessie, il estprobable que cela soit systemd.

Du coup, j’ai fait un systemd-analyze blame et j’ai ça :

          5.811s nmbd.service
          5.416s samba-ad-dc.service
          2.461s systemd-fsck-root.service
===>      2.176s networking.service
          2.033s smbd.service
          1.692s systemd-logind.service
          1.400s alsa-restore.service
===>      1.388s pppd-dns.service
===>      1.378s dhcpcd.service
          1.363s triggerhappy.service
          1.362s dphys-swapfile.service
          1.321s bluetooth.service
          1.221s raspi-config.service
          1.199s avahi-daemon.service
          1.115s keyboard-setup.service
           720ms rc-local.service
           503ms systemd-modules-load.service
           476ms fake-hwclock.service
           466ms kbd.service
           465ms console-setup.service
           438ms systemd-tmpfiles-setup.service
           419ms rsyslog.service
           66ms hdparm.service
      ...etc...

Comment peut-on savoir l’ordre de lancement des services ?

#6

Il suffit de regarder dans le fichier pour le savoir.

#7

Le voici :

# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

iface eth0 inet manual

allow-hotplug wlan0
iface wlan0 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

allow-hotplug wlan1
iface wlan1 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

auto vpn
iface vpn inet ppp
provider freedomip

Hormis les 3 dernières lignes, je n’ai rien ajouté

#8

Pourquoi deux interfaces wlan0 et wlan1 avec le même fichier de configuration WPA ?

En tout cas le wifi semble configuré dans ce fichier mais comme wlan0/wlan1 est activée avec “allow-hotplug” donc de façon asynchrone, il se peut qu’elle ne soit pas encore opérationnelle quand le VPN est lancé.

Ce n’est pas très propre, mais tu peux essayer d’introduire un délai avant l’activation du VPN avec une option du genre :

#9

Oui c’est en effet étrange. Je pensais que c’était le fait d’avoir changé le dongle wifi de port USB… mais je ne crois pas.
J’ai viré les lignes en rapport avec le wlan1 et depuis plus de réseau même en reopiant les lignes d’origine !

Bon le plus simple : repartir de zéro
Je vais en profiter pour récupérer une raspibian jessie lite afin de ne pas avoir tous les softs qui ne servent à rien sur un serveur.
Je remettrai en place le tunnel vpn comme dans mon 1er post puis testerai le tunnel au boot sans puis avec la commande que tu m’as passé. Je te tiens au jus. Merci en touts cas !

#10

Avant de supprimer quoi que ce soit il aurait fallu vérifier quel est le nom de l’interface wifi avec [mono]ifconfig -a[/mono] ou [mono]ip link[/mono] ou [mono]iwconfig[/mono].

#11

Oui effectivement… j’ai fait ca tard le soir et les yeux collés :blush:

Là la carte SD possède une fresh install. Reste plus qu’à la glisser dans la raspberry…

#12

Ré-installation faite !
Donc j’ai une Raspbian jessie lite connecté au réseau via eth0 (pour le moment faisons simple…)

J’ai réinstallé le tunnel pptp.
J’ai édité le fichier interfaces. Il y a toujours cette histoire de wlan0/wlan1.
Soit c’est comme cela par défaut soit c’est à cause des dongles wifi et bluetooth. Bref ça marche…

J’ai ajouté à ce fichier :

auto vpn
iface vpn inet ppp
provider freedomip

puis reboot

là j’ai fait un ifconfig -s : pas de trace de ppp0 :smiling_imp:

Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0       1500 0       327      0     14 0           178      0      0      0 BMRU
lo        65536 0       136      0      0 0           136      0      0      0 LRU
wlan0      1500 0         0      0      0 0             0      0      0      0 BMU

bon…je fais un “sudo ifup vpn” et là :

ifup: interface vpn already configured

un “ping -I ppp0 8.8.8.8” ne fonctionne pas dans ce cas :119

Je tente un dernier “sudo pon freedomip” : rien
Bon bah, un petit “ifconfig -s” alors ?

Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0       1500 0      2085      0    134 0           794      0      0      0 BMRU
lo        65536 0       200      0      0 0           200      0      0      0 LRU
ppp0       1496 0         8      0      0 0             5      0      0      0 MOPRU
wlan0      1500 0         0      0      0 0             0      0      0      0 BMU

et un “ping -I ppp0 8.8.8.8” fonctionne :013
===> Bon bah je vais me coucher et pleurer !

Note : ta commande ne fonctionne pas.

#13

[quote=“pixeldesbois”]bon…je fais un “sudo ifup vpn” et là :

Normal, ifupdown a démarré l’interface et l’a marquée comme telle. Mais ça ne signifie pas qu’elle est opérationnelle : ifupdown se limite à lancer la connexion PPP en invoquant [mono]pon[/mono] ou directement [mono]pppd[/mono] mais ne surveille pas son état réel.

L’absence de message de retour ne signifie pas qu’il ne s’est rien passé. [mono]pon[/mono] se limite à invoquer [mono]pppd[/mono] qui tourne en tâche de fond. Vérifie les interfaces avec [mono]ip addr[/mono].

Quelle commande ? Peux-tu republier le contenu actuel du fichier interfaces ?

La ligne au début du fichier indique qu’il est écrit pour fonctionner avec [mono]dhcpcd[/mono] (client DHCP mais pas seulement), que je ne connais pas du tout. Cela pourrait expliquer la méthode “manual” pour toutes les interfaces.
Y a-t-il des fichiers dans les répertoires /etc/network/if-*.d ?

#14

Bonsoir,

Je te remercie pour tes explications.

Par curiosité et comme ça ne prend qu’une dizaine de minutes, j’ai refait l’installation. Cette fois-ci, au préalable, je n’ai laissé que la connexion filaire et retiré tous les dongles.

Résultat :
Le fichier interfaces possède quand même les lignes

allow-hotplug wlan0
iface wlan0 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

allow-hotplug wlan1
iface wlan1 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Toujours pas de vpn au reboot…

Je parlais de ligne que tu m’as proposé d’ajouter dans le fichier interfaces :

pre-up sleep 10

Voici le fichier interfaces :

# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

iface eth0 inet manual

allow-hotplug wlan0
iface wlan0 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

allow-hotplug wlan1
iface wlan1 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

auto freedomip
iface freedomip inet ppp
provider freedomip

oui il y en a :

pi@zelda:~ $ sudo ls /etc/network/if-up.d/
000resolvconf  avahi-daemon  mountnfs  openssh-server  upstart	wpasupplicant
pi@zelda:~ $ sudo ls /etc/network/if-pre-up.d/
wireless-tools	wpasupplicant
pi@zelda:~ $ sudo ls /etc/network/if-post-down.d/
avahi-daemon  wireless-tools  wpasupplicant
pi@zelda:~ $ sudo ls /etc/network/if-down.d/
resolvconf  upstart  wpasupplicant

Peut-être faire un essai avec une adresse ip statique ?

#15

Tu l’avais bien mise juste après la ligne “provider” ?
Il faut peut-être augmenter le délai.

#16

J’ai doublé le délai mais rien y fait…

J’ai regardé le fichier /var/log/messages :

Feb 16 22:30:28 zelda rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="427" x-info="http://www.rsyslog.com"] ex$
Feb 16 22:30:52 zelda rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="430" x-info="http://www.rsyslog.com"] st$
Feb 16 22:30:52 zelda kernel: [    0.000000] Booting Linux on physical CPU 0xf00
Feb 16 22:30:52 zelda kernel: [    0.000000] Initializing cgroup subsys cpuset
Feb 16 22:30:52 zelda kernel: [    0.000000] Initializing cgroup subsys cpu
Feb 16 22:30:52 zelda kernel: [    0.000000] Initializing cgroup subsys cpuacct
Feb 16 22:30:52 zelda kernel: [    0.000000] Linux version 4.1.17-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.8.3 20140303 (prere$
Feb 16 22:30:52 zelda kernel: [    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
Feb 16 22:30:52 zelda kernel: [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Feb 16 22:30:52 zelda kernel: [    0.000000] Machine model: Raspberry Pi 2 Model B Rev 1.1
Feb 16 22:30:52 zelda kernel: [    0.000000] cma: Reserved 8 MiB at 0x3a400000
Feb 16 22:30:52 zelda kernel: [    0.000000] Memory policy: Data cache writealloc
Feb 16 22:30:52 zelda pppd[314]: pppd 2.4.6 started by root, uid 0
Feb 16 22:30:52 zelda pppd[314]: Using interface ppp0
Feb 16 22:30:52 zelda pppd[314]: Connect: ppp0 <--> /dev/pts/0
Feb 16 22:30:52 zelda pppd[314]: Modem hangup
Feb 16 22:30:52 zelda pppd[314]: Connection terminated.
Feb 16 22:30:52 zelda pppd[314]: Exit.

....

Feb 16 22:30:52 zelda kernel: [    5.937892] bcm2835-rng 3f104000.rng: hwrng registered
Feb 16 22:30:52 zelda kernel: [    5.938731] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
Feb 16 22:30:52 zelda kernel: [    6.318663] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
Feb 16 22:30:52 zelda kernel: [   27.050237] PPP generic driver version 2.4.2
Feb 16 22:30:52 zelda kernel: [   27.137870] random: nonblocking pool is initialized
Feb 16 22:30:52 zelda kernel: [   27.737235] cfg80211: Calling CRDA to update world regulatory domain
Feb 16 22:30:52 zelda kernel: [   27.840631] Adding 102396k swap on /var/swap.  Priority:-1 extents:7 across:307200k SSFS
Feb 16 22:30:52 zelda kernel: [   27.948778] cfg80211: World regulatory domain updated:
Feb 16 22:30:52 zelda kernel: [   27.948814] cfg80211:  DFS Master region: unset
Feb 16 22:30:52 zelda kernel: [   27.948828] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), ($
Feb 16 22:30:52 zelda kernel: [   27.948846] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
Feb 16 22:30:52 zelda kernel: [   27.948861] cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
Feb 16 22:30:52 zelda kernel: [   27.948876] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
Feb 16 22:30:52 zelda kernel: [   27.948895] cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000$
Feb 16 22:30:52 zelda kernel: [   27.948913] cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000$
Feb 16 22:30:52 zelda kernel: [   27.948929] cfg80211:   (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
Feb 16 22:30:52 zelda kernel: [   27.948945] cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
Feb 16 22:30:52 zelda kernel: [   27.948961] cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
Feb 16 22:30:53 zelda kernel: [   28.448952] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Feb 16 22:30:53 zelda kernel: [   28.449977] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Feb 16 22:30:54 zelda kernel: [   29.963940] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Feb 16 22:30:54 zelda kernel: [   29.964777] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xDDE1

Si j’ai bien compris, il semblerait que l’interface ppp0 tente une connexion bien avant l’interface network.

Comme si tout se lançait dans le désordre.

#17

oh pinaise ! méthode bourrin :
il suffit d’ajouter dans le fichier de config de la connexion VPN (/etc/ppp/peer/<###Nom du fichier###>

persist
maxfail 0

Cela force la reconnexion indéfinimment.
Dans le /var/log/message , on voit que plusieurs tentatives au démarrage jusqu’à la fin de la séquence de boot où il finit par passer.

Suite au prochaine épisode !

#18

Si le VPN doit être permanent, c’est une bonne solution.