Client vpn pptp + deluge daemon : à l'aide !

Sxilderik · Février 21, 2016, 4:11am

Bonjour

J’ai une deluged qui tourne sur ma Debian Squeeze, j’ai un compte pptp chez un fournisseur de VPN, configuré aussi sur ma Squeeze (mais inactif), et j’aimerais faire tourner les deux de la manière suivante :

État actuel :

mon serveur Debian est headless, sans clavier ni écran, ni interface graphique.
il est situé, comme les autres PC de mon réseau, derrière mon routeur. Il ne sert pas de passerelle internet. Par contre, il héberge un serveur Web accessible de l’extérieur : le routeur redirige tout le port 80 vers ce serveur, une ligne iptable NAT transforme ce 80 venant de l’extérieur en 8080 interne (c’est d’ailleurs le seule paramétrage iptable utilisé)
le démon deluged communique actuellement par le réseau standard (eth0)

Souhait :

Tout le trafic réseau du démon deluge doit passer par le VPN, et seulement ce trafic-là.

Les docs qui parlent de tout ça ne sont pas très claires, ou ne correspondent pas à ma configuration, et je manque de compétences pour les adapter.

Pouvez-vous me faire avancer sur ce sujet svp ?

Merci beaucoup de votre aide.

PascalHambourg · Février 21, 2016, 4:11am

Il y a déjà eu des discussions sur ce sujet. Il faut mettre en place du routage avancé.

Le principe consiste à identifier les paquets émis devant être routés vers l’interface PPTP au lieu de la passerelle par défaut. Le critère peut être notamment :

l’adresse source (si on peut lier le processus émetteur à une adresse locale spécifique)
le protocole TCP, UDP, SCTP…
le port source et/ou destination
l’UID ou le GID effectif du processus émetteur

Le plus simple, c’est l’adresse source. Idéalement il faut configurer le processus émetteur pour utiliser l’adresse de l’interface PPTP (et donc le lancer après que le VPN soit établi), ainsi on peut faire le routage avancé directement sans devoir marquer les paquets avec iptables.

Sxilderik · Février 21, 2016, 4:11am

Merci.

C’est du p2p, à l’écoute sur un port donné, mais pouvant à priori émettre sur n’importe quel port.

Dans deluge, on peut préciser l’interface, par défaut, la zone est à vide. Si je comprends bien l’idée, il suffirait d’indiquer ici ppp0. Mais encore faut-il que le canal soit monté… comment le monter au démarrage ?

Plein de questions…

PascalHambourg · Février 21, 2016, 11:07am

Je suppose que tu as déjà créé un fichier de configuration pour le VPN dans /etc/ppp/peers/.
Pour lancer le VPN au démarrage du système, il faut définir la connexion avec auto dans le fichier /etc/network/interfaces :

auto vpn iface vpn inet ppp provider <le_nom_du_fichier>
A noter qu’il n’est pas garanti que l’interface s’appelle ppp0. pppd prend le premier nom disponible. Si par exemple on relance la connexion alors que la précédente utilisant ppp0 est bloquée ou pas complètement terminée, alors la nouvelle connexion aura pour interface ppp1.

Sxilderik · Février 21, 2016, 11:07am

Merci

La doc de deluge est assez sommaire, et ne semble pas mentionner l’utilisation de ce champ appelé Interface. J’avais supposé qu’il s’agissait d’un nom d’interface, au sens *nix, mais je lis dans les forums deluge qu’il faut inscrire ici une adresse IP, et que ça s’applique aux machines avec plusieurs IP (cartes physiques, adresses virtuelles, etc.)

Du coup, je ne suis pas beaucoup plus avancé…

PascalHambourg · Février 21, 2016, 11:07am

C’est logique, les applications “normales” utilisent des adresses IP, pas des interfaces. Même si l’option s’appelle parfois improprement “interface”.
Il y a plusieurs possibilités.

Lancer l’application une fois que la connexion VPN est établie (et l’arrêter lorsque la connexion est coupée). Cela peut se faire avec des scripts placés dans /etc/ppp/ip-up.d/ et /etc/ppp/ip-down.d/ qui sont exécutés lorsqu’une connexion PPP monte et tombe respectivement. pppd passe l’adresse de l’interface créée, donc si l’adresse est variable le script peut la mettre à jour dans la configuration de l’application. Le script devra aussi créer les règles de routage avancé avec l’adresse et l’interface du VPN.
Créer une interface factice (dummy), lui attribuer une adresse quelconque utilisée par l’application.
Le routage avancé prendra cette adresse en compte, mais il faudra ajouter des règles iptables de NAT source et destination pour remplacer l’adresse factice par l’adresse réelle et vice versa dans les paquets passant par le VPN.

Clochette · Février 21, 2016, 11:07am

Qu’entends tu pas interface factice ? un bridge par exemple ?

Sxilderik · Février 21, 2016, 11:07am

Merci

La solution n° 1 me plait mieux, dans le sens où je vois mieux ce qu’il faudrait faire (que pour la solution n° 2)

automatiser la connexion VPN comme indiqué plus haut
lancer deluged seulement dans le script de connexion, et l’arrêter dans le script de déconnexion
choper l’IP donnée par le VPN dans le script de connexion pour le mettre dans la config de deluged.

Par contre, je ne comprends pas pourquoi, une fois qu’on a dit à deluged d’utiliser cette IP, il faudrait ajouter des règles iptables. Comment marche torrent ? L’IP publique utilisée pour se connecter au réseau torrent est celle qui sera utilisée à son tour en entrée, sur un port donné, ou me trompe-je ? L’IP « normale » ne serait donc pas utilisée ni communiquée par deluged.

Quelle brique me manque ?

PascalHambourg · Février 21, 2016, 11:07am

Non : une interface dummy0, 1… (équivalent réseau de /dev/null).

La solution n° 1 n’a pas besoin d’iptables. Il faut juste créer une règle de routage (ip rule) et une route (ip route).

PascalHambourg · Février 21, 2016, 11:07am

Tu peux commencer par tester la solution de routage avancé manuellement avant d’automatiser avec des scripts.

[ul][li]Etablir le VPN[/li]
[li]Récupérer le nom $PPP_IFACE et l’adresse $PPP_LOCAL de l’interface PPP, par exemple avec ifconfig.[/li]
[li]Créer la route vers le VPN la règle de routage basée sur l’adresse source (avec la table de routage 99 par exemple) :

ip route add default dev $PPP_IFACE table 99 ip rule from $PPP_LOCAL lookup table 99[/li]
[li]Configurer et lancer l’application avec l’adresse $PPP_LOCAL.[/li]
[li]Tester.[/li][/ul]

Sxilderik · Février 21, 2016, 11:07am

Un truc comme ça

pon mon_vpn (?)

ensuite ifconfig me donne ppp0 et xxx.xxx.xxx.xxx

ip route add default dev ppp0 table mon_vpn
ip rule add from xxx.xxx.xxx.xxx lookup mon_vpn

deluged -i xxx.xxx.xxx.xxx

etc.

Il faut que j’adapte mon script /etc/init.d/deluge-daemon pour qu’il prenne le paramètre -i

Par contre, après le poff, je constate par ip rule et ip route que les règles et routes sont toujours là. Comment faire le ménage ?

Ensuite… comment vérifier qu’effectivement deluged ne cause au monde extérieur que par $PPP_IFACE ? Une option de netstat ?

En tous cas, merci, ça avance. Merci pour moi et pour les autres qui se poseront ce genre de question

PascalHambourg · Février 21, 2016, 11:07am

Oui, si les options de la connexion PPTP sont définies dans /etc/ppp/peers/mon_vpn. Ou bien avec ifup si la connexion a été définie dans /etc/network/interfaces, ce qui permet de la lancer au démarrage avec une option auto.

[quote=“Sxilderik”]ip route add default dev ppp0 table mon_vpn
ip rule add from xxx.xxx.xxx.xxx lookup mon_vpn[/quote]
Il faut avoir préalablement défini un numéro de table pour le nom “mon_vpn” dans /etc/iproute2/rt_tables, sinon on peut utiliser directement un numéro de table dans les commandes.

Il faut effectivement effacer la règle avec

automatisable avec un script dans /etc/ppp/ip-down.d/ qui arrêtera l’application. Par contre la route faisant référence à l’interface $PPP_IFACE, elle devrait normalement être automatiquement supprimée quand l’interface tombe. Tu es sûr que la route est bien présente et la connexion bien arrêtée (l’interface $PPP_IFACE n’existe plus) ?

netstat -4p (en root) devrait afficher $PPP_LOCAL comme adresse source des sockets ouvertes par l’application. Tu peux vérifier avec “ip route get from $PPP_LOCAL to <n’importe où>” que l’interface de sortie est bien $PPP_IFACE. Enfin tu peux faire une capture de paquets sur l’interface LAN puis sur $PPP_IFACE pour vérifier que le trafic de l’application passe exclusivement par $PPP_IFACE.

Sxilderik · Février 21, 2016, 11:07am

Ça avance bien, merci de ta patience et de la clarté de tes explications !

dans /etc/network/interfaces, j’ai ajouté comme tu l’as dit
auto vpn
iface vpn inet ppp
provider mon_vpn

Édition : reste du message effacé car incorrect et donc trompeur.

Sxilderik · Février 21, 2016, 11:07am

Autre question : j’ai ajouté persist dans /etc/network/interfaces à mon interface vpn

Cette option permet semble-t-il une auto reconnexion. Mais les scripts if-xxx.d sont-ils joués à la perte de connexion et reconnexion ?

PascalHambourg · Février 21, 2016, 11:07am

[quote=“Sxilderik”]le pon est fait par /etc/network/if-up.d/ethtool
et le poff par /etc/network/if-down.d/resolvconf[/quote]
Je ne sais pas comment tu arrives à ces conclusions mais tu fais fausse route.
Ifup exécute pon et /etc/network/if-up.d/ethtool (de même que tous les autres scripts dans /etc/network/if-pre-up.d/ et /etc/network/if-up.d/).
Ifdown exécute poff et /etc/network/if-down.d/resolvconf (de même que tous les autres scripts dans /etc/network/if-down.d/ et /etc/network/if-post-down.d/).
Il n’y a pas de lien entre pon et ethtool ni entre poff et resolvconf (en fait il y a un lien entre pon|poff et resolvconf mais c’est à travers des scripts de resolvconf présents dans /etc/ppp/ip-up.d/ et /etc/ppp/ip-down.d/.

L’utilisation de scripts d’ifupdown n’est pas adaptée aux interfaces PPP, pour plusieurs raisons. Une est qu’ils ne disposent pas des paramètres dynamiques $PPP_* de la connexion comme l’adresse et le nom réel de l’interface. Une autre est que leur exécution n’est pas synchrone avec l’exécution de pppd et donc de l’activation et la désactivation effectives de l’interface PPP. Les scripts dans /etc/ppp/ip-pre-up.d/ sont exécutés par ifup avant l’exécution de pon (qui démarre pppd en tâche de fond) et ceux dans /etc/ppp/ip-up.d/ après, mais pas forcément (et probablement pas) après que pppd ait fini de monter la connexion. De même, les scripts dans /etc/ppp/ip-down.d/ sont exécutés par ifdown avant l’exécution de poff (qui arrête pppd) et ceux dans /etc/ppp/ip-post-down.d/ après, mais pas forcément (et probablement pas) après que pppd ait terminé la déconnexion. Une dernière est que ces scripts ne sont pas exécutés lorsque la connexion tombe indépendamment d’ifdown ou est relancée automatiquement si l’option ‘persist’ est présente.

Pour toutes ces raisons, il vaut mieux utiliser des scripts dans /etc/ppp/ip-.d/ à la place de ceux dans /etc/network/if-.d/.

Sxilderik · Février 21, 2016, 11:07am

Voilà ce qui m’a fait supposer que ethtool et resolvconf lançaient les pon et poff :

[quote]> ifup -v vpn
Configuring interface vpn=vpn (inet)
run-parts --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/ethtool
pon mon_vpn
run-parts --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/000resolvconf
run-parts: executing /etc/network/if-up.d/avahi-daemon
run-parts: executing /etc/network/if-up.d/ethtool
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/samba
run-parts: executing /etc/network/if-up.d/zzz_mon_vpn
je suis dans zzz_mon_vpn
[/quote]

[quote]> ifdown -v vpn
Configuring interface vpn=vpn (inet)
run-parts --verbose /etc/network/if-down.d
run-parts: executing /etc/network/if-down.d/resolvconf
poff mon_vpn
run-parts --verbose /etc/network/if-post-down.d
run-parts: executing /etc/network/if-post-down.d/avahi-daemon
[/quote]

À chaque fois que j’ai lancé ifup ou ifdown, j’avais le même résultat… En lisant ton explication, je comprends qu’il s’agissait d’une simple coïncidence, répétée à chaque lancement !

En tous cas tu m’apprends l’existence de scripts mieux adaptés au ppp dans /etc/ppp/if-updown.d, c’est là que je vais jouer bien sûr ! Je vois déjà que c’est /etc/ppp/if-up qui fournit les $PPP_x et qui lance les scripts dans if-up.d. Ça tombe bien, j’aime bien comprendre ce que je fais !

… On est samedi, il est 22h, j’ai pas décollé de ça de tout l’après-midi

PascalHambourg · Février 21, 2016, 11:07am

Eh, je les avais déjà mentionnés dans mon troisième message de cette discussion…

Sxilderik · Février 21, 2016, 11:07am

Arf oui… désolé !

À force de chercher partout j’ai confondu network et ppp !

Mais au final… ça marche !

dans /etc/ppp/ip-up.d/mon_vpn j’ai mis

[quote]# Restriction sur le fournisseur
[ “$PPP_IPPARAM” = “mon_vpn” ] || exit 0

ip route add default dev $PPP_IFACE table 111
ip rule add from $PPP_LOCAL lookup 111

export USE_PPP_LOCAL="–interface=$PPP_LOCAL"
/etc/init.d/deluge-daemon start
[/quote]

j’ai modifié /etc/init.d/deluge-daemon pour simplement ajouter $USE_PPP_LOCAL dans les options de lancement

dans /etc/ppp/ip-down.d/mon_vpn

[quote]# Restriction sur le fournisseur
[ “$PPP_IPPARAM” = “mon_vpn” ] || exit 0

/etc/init.d/deluge-daemon stop

ip rule del from $PPP_LOCAL lookup 111
[/quote]

et ça marche !

Enfin, presque

Le VPN se déconnecte / reconnecte très souvent, je ne sais pas encore pourquoi. En tous cas à chaque fois deluge tombe et est relancé avec la bonne adresse
J’ai l’impression qu’il y a un bug dans deluged, qui fait que la spécification de l’interface est mal prise en compte…

Oui, le vpn se reconnecte toutes les trois minutes environ, ce qu’il ne faisait pas quand je m’en servais sous Windows… Il y a un os.

En tous cas, merci beaucoup pour ta patience, ta disponibilité et tes explications complètes - et bien rédigées !

PascalHambourg · Février 21, 2016, 11:07am

C’est-à-dire ?

Tu peux ajouter “debug” dans les options de la connexion et regarder dans /var/log/syslog pourquoi ça coupe.

Sxilderik · Février 21, 2016, 11:07am

J’avais lancé des traces en debug hier soir, voilà un peu ce que ça donnait. Le problème principal venait de No response to 4 echo-requests, sans que je sache la cause de ça.
Mais ce matin, mon routeur était planté, j’ai tout relancé, routeur et serveur, et, comme on dit, c’est tombé en marche !
La connexion VPN est stable.

[size=60][code]
Feb 19 02:49:56 gaia pppd[13292]: pppd options in effect:
Feb 19 02:49:56 gaia pppd[13292]: debug#011#011# (from command line)
Feb 19 02:49:56 gaia pppd[13292]: nodetach#011#011# (from command line)
Feb 19 02:49:56 gaia pppd[13292]: persist#011#011# (from /etc/ppp/peers/mon_vpn)
Feb 19 02:49:56 gaia pppd[13292]: logfd 2#011#011# (from command line)
Feb 19 02:49:56 gaia pppd[13292]: dump#011#011# (from command line)
Feb 19 02:49:56 gaia pppd[13292]: noauth#011#011# (from /etc/ppp/peers/mon_vpn)
Feb 19 02:49:56 gaia pppd[13292]: name username#011#011# (from /etc/ppp/peers/mon_vpn)
Feb 19 02:49:56 gaia pppd[13292]: remotename mon_vpn#011#011# (from /etc/ppp/peers/mon_vpn)
Feb 19 02:49:56 gaia pppd[13292]: #011#011# (from /etc/ppp/peers/mon_vpn)
Feb 19 02:49:56 gaia pppd[13292]: pty pptp vpn.mon_vpn.net --nolaunchpppd#011#011# (from /etc/ppp/peers/mon_vpn)
Feb 19 02:49:56 gaia pppd[13292]: crtscts#011#011# (from /etc/ppp/options)
Feb 19 02:49:56 gaia pppd[13292]: #011#011# (from /etc/ppp/options)
Feb 19 02:49:56 gaia pppd[13292]: asyncmap 0#011#011# (from /etc/ppp/options)
Feb 19 02:49:56 gaia pppd[13292]: lcp-echo-failure 4#011#011# (from /etc/ppp/options)
Feb 19 02:49:56 gaia pppd[13292]: lcp-echo-interval 30#011#011# (from /etc/ppp/options)
Feb 19 02:49:56 gaia pppd[13292]: hide-password#011#011# (from /etc/ppp/options)
Feb 19 02:49:56 gaia pppd[13292]: ipparam mon_vpn#011#011# (from /etc/ppp/peers/mon_vpn)
Feb 19 02:49:56 gaia pppd[13292]: usepeerdns#011#011# (from /etc/ppp/peers/mon_vpn)
Feb 19 02:49:56 gaia pppd[13292]: nobsdcomp#011#011# (from /etc/ppp/peers/mon_vpn)
Feb 19 02:49:56 gaia pppd[13292]: nodeflate#011#011# (from /etc/ppp/peers/mon_vpn)
Feb 19 02:49:56 gaia pppd[13292]: require-mppe-128#011#011# (from /etc/ppp/peers/mon_vpn)
Feb 19 02:49:56 gaia pppd[13292]: noipx#011#011# (from /etc/ppp/options)
Feb 19 02:49:56 gaia pppd[13292]: pppd 2.4.5 started by luc, uid 0

Feb 19 02:49:56 gaia pppd[13292]: using channel 33
Feb 19 02:49:56 gaia pppd[13292]: Using interface ppp0
Feb 19 02:49:56 gaia pppd[13292]: Connect: ppp0 <–> /dev/pts/1
Feb 19 02:49:56 gaia pptp[13296]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Feb 19 02:49:56 gaia pptp[13305]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request’
Feb 19 02:49:56 gaia pptp[13305]: anon log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
Feb 19 02:49:56 gaia pptp[13305]: anon log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
Feb 19 02:49:57 gaia pppd[13292]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3589d883> ]
Feb 19 02:49:57 gaia pptp[13305]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request’
Feb 19 02:49:57 gaia pptp[13305]: anon log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
Feb 19 02:49:57 gaia pptp[13305]: anon log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer’s call ID 22446).
Feb 19 02:49:57 gaia pppd[13292]: rcvd [LCP ConfReq id=0x1 <mru 1500> <magic 0xbe4f09b6> ]
Feb 19 02:49:57 gaia pppd[13292]: sent [LCP ConfAck id=0x1 <mru 1500> <magic 0xbe4f09b6> ]
Feb 19 02:49:57 gaia pppd[13292]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x3589d883> ]
Feb 19 02:49:57 gaia pppd[13292]: sent [LCP EchoReq id=0x0 magic=0x3589d883]
Feb 19 02:49:57 gaia pppd[13292]: rcvd [CHAP Challenge id=0x1 , name = “”]
Feb 19 02:49:57 gaia pppd[13292]: sent [CHAP Response id=0x1 <1e0253eafeef03b73ee1c083849c2e9100000000000000009d8b5418a36947f8e66e9a88748c7a0f7d86960eafee305800>, name = “username”]
Feb 19 02:49:57 gaia pppd[13292]: rcvd [LCP EchoRep id=0x0 magic=0xbe4f09b6]
Feb 19 02:49:57 gaia pppd[13292]: rcvd [CHAP Success id=0x1 “S=FF87DAB24274B74BDBFCB695AE41B00181586392”]
Feb 19 02:49:57 gaia pppd[13292]: CHAP authentication succeeded
Feb 19 02:49:57 gaia pppd[13292]: sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
Feb 19 02:49:57 gaia pppd[13292]: rcvd [IPCP ConfReq id=0x1 <addr (ppp_remote_ip)> <compress VJ 0f 00>]
Feb 19 02:49:57 gaia pppd[13292]: sent [IPCP TermAck id=0x1]
Feb 19 02:49:57 gaia pppd[13292]: rcvd [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
Feb 19 02:49:57 gaia pppd[13292]: sent [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
Feb 19 02:49:59 gaia pppd[13292]: rcvd [IPCP ConfReq id=0x2 <addr (ppp_remote_ip)> <compress VJ 0f 00>]
Feb 19 02:49:59 gaia pppd[13292]: sent [IPCP TermAck id=0x2]
Feb 19 02:49:59 gaia pppd[13292]: rcvd [CCP ConfReq id=0x2 <mppe +H -M +S -L -D -C>]
Feb 19 02:49:59 gaia pppd[13292]: sent [CCP ConfAck id=0x2 <mppe +H -M +S -L -D -C>]
Feb 19 02:50:00 gaia pppd[13292]: sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
Feb 19 02:50:00 gaia pppd[13292]: rcvd [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
Feb 19 02:50:00 gaia pppd[13292]: MPPE 128-bit stateless compression enabled
Feb 19 02:50:00 gaia pppd[13292]: sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr (eth0_ip)> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Feb 19 02:50:00 gaia pppd[13292]: rcvd [IPCP ConfNak id=0x1 <addr (ppp_local_ip)> <ms-dns1 (dns1_ip)> <ms-dns2 (dns2_ip)>]
Feb 19 02:50:00 gaia pppd[13292]: sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr (ppp_local_ip)> <ms-dns1 (dns1_ip)> <ms-dns2 (dns2_ip)>]
Feb 19 02:50:00 gaia pppd[13292]: rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr (ppp_local_ip)> <ms-dns1 (dns1_ip)> <ms-dns2 (dns2_ip)>]
Feb 19 02:50:01 gaia pppd[13292]: rcvd [IPCP ConfReq id=0x3 <addr (ppp_remote_ip)> <compress VJ 0f 00>]
Feb 19 02:50:01 gaia pppd[13292]: sent [IPCP ConfAck id=0x3 <addr (ppp_remote_ip)> <compress VJ 0f 00>]
Feb 19 02:50:01 gaia pppd[13292]: local IP address (ppp_local_ip)
Feb 19 02:50:01 gaia pppd[13292]: remote IP address (ppp_remote_ip)
Feb 19 02:50:01 gaia pppd[13292]: primary DNS address (dns1_ip)
Feb 19 02:50:01 gaia pppd[13292]: secondary DNS address (dns2_ip)
Feb 19 02:50:01 gaia pppd[13292]: Script /etc/ppp/ip-up started (pid 13307)
Feb 19 02:50:02 gaia pppd[13292]: Script /etc/ppp/ip-up finished (pid 13307), status = 0x0
Feb 19 02:50:57 gaia pptp[13305]: anon log[logecho:pptp_ctrl.c:677]: Echo Request received.
Feb 19 02:50:57 gaia pptp[13305]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 6 'Echo-Reply’
Feb 19 02:50:57 gaia pptp[13305]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Feb 19 02:51:57 gaia pptp[13305]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Feb 19 02:52:57 gaia pptp[13305]: anon log[logecho:pptp_ctrl.c:677]: Echo Request received.
Feb 19 02:52:57 gaia pptp[13305]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 6 'Echo-Reply’
Feb 19 02:52:57 gaia pptp[13305]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Feb 19 02:53:27 gaia pppd[13292]: No response to 4 echo-requests
Feb 19 02:53:27 gaia pppd[13292]: Serial link appears to be disconnected.
Feb 19 02:53:27 gaia pppd[13292]: Connect time 3.5 minutes.
Feb 19 02:53:27 gaia pppd[13292]: Sent 1479 bytes, received 1279 bytes.
Feb 19 02:53:27 gaia pppd[13292]: Script /etc/ppp/ip-down started (pid 13566)
Feb 19 02:53:27 gaia pppd[13292]: MPPE disabled
Feb 19 02:53:27 gaia pppd[13292]: sent [LCP TermReq id=0x2 “MPPE disabled”]
Feb 19 02:53:27 gaia pppd[13292]: sent [LCP TermReq id=0x3 “MPPE disabled”]
Feb 19 02:53:28 gaia pppd[13292]: Script /etc/ppp/ip-down finished (pid 13566), status = 0x1
Feb 19 02:53:30 gaia pptp[13305]: anon log[ctrlp_disp:pptp_ctrl.c:929]: Call disconnect notification received (call id 22446)
Feb 19 02:53:30 gaia pppd[13292]: sent [LCP TermReq id=0x4 “MPPE disabled”]
Feb 19 02:53:30 gaia pppd[13292]: Connection terminated.
Feb 19 02:53:30 gaia pppd[13292]: Modem hangup
Feb 19 02:53:30 gaia pptp[13296]: anon warn[decaps_hdlc:pptp_gre.c:204]: short read (-1): Input/output error
Feb 19 02:53:30 gaia pptp[13296]: anon warn[decaps_hdlc:pptp_gre.c:216]: pppd may have shutdown, see pppd log
Feb 19 02:53:30 gaia pptp[13305]: anon log[callmgr_main:pptp_callmgr.c:234]: Closing connection (unhandled)
Feb 19 02:53:30 gaia pptp[13305]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request’
Feb 19 02:53:30 gaia pptp[13305]: anon log[call_callback:pptp_callmgr.c:79]: Closing connection (call state)

Feb 19 02:53:30 gaia pppd[13292]: using channel 34
Feb 19 02:53:30 gaia pppd[13292]: Using interface ppp0
Feb 19 02:53:30 gaia pppd[13292]: Connect: ppp0 <–> /dev/pts/2
Feb 19 02:53:30 gaia pppd[13292]: Script pptp vpn.mon_vpn.net --nolaunchpppd finished (pid 13294), status = 0x0
Feb 19 02:53:30 gaia pptp[13610]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Feb 19 02:53:31 gaia pppd[13292]: sent [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0x5fe1e1eb> ]
Feb 19 02:53:33 gaia pppd[13292]: sent [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0x5fe1e1eb> ]
Feb 19 02:53:34 gaia pppd[13292]: sent [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0x5fe1e1eb> ]
Feb 19 02:53:36 gaia pppd[13292]: sent [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0x5fe1e1eb> ]
Feb 19 02:53:37 gaia pppd[13292]: sent [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0x5fe1e1eb> ]
Feb 19 02:53:39 gaia pppd[13292]: sent [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0x5fe1e1eb> ]
Feb 19 02:53:40 gaia pppd[13292]: sent [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0x5fe1e1eb> ]
Feb 19 02:53:42 gaia pppd[13292]: sent [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0x5fe1e1eb> ]
Feb 19 02:53:43 gaia pppd[13292]: sent [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0x5fe1e1eb> ]
Feb 19 02:53:45 gaia pppd[13292]: sent [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0x5fe1e1eb> ]
Feb 19 02:53:46 gaia pppd[13292]: LCP: timeout sending Config-Requests
Feb 19 02:53:46 gaia pppd[13292]: Connection terminated.
Feb 19 02:53:46 gaia pppd[13292]: Modem hangup

Feb 19 02:53:46 gaia pppd[13292]: using channel 35
Feb 19 02:53:46 gaia pppd[13292]: Using interface ppp0
Feb 19 02:53:46 gaia pppd[13292]: Connect: ppp0 <–> /dev/pts/1
Feb 19 02:53:46 gaia pptp[13623]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Feb 19 02:53:47 gaia pppd[13292]: sent [LCP ConfReq id=0x6 <asyncmap 0x0> <magic 0x70623e7c> ]
Feb 19 02:53:48 gaia pppd[13292]: sent [LCP ConfReq id=0x6 <asyncmap 0x0> <magic 0x70623e7c> ]
Feb 19 02:53:49 gaia pptp[13633]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request’
Feb 19 02:53:50 gaia pptp[13633]: anon log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
Feb 19 02:53:50 gaia pptp[13633]: anon log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
Feb 19 02:53:50 gaia pppd[13292]: sent [LCP ConfReq id=0x6 <asyncmap 0x0> <magic 0x70623e7c> ]
Feb 19 02:53:50 gaia pptp[13633]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request’
Feb 19 02:53:51 gaia pptp[13633]: anon log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
Feb 19 02:53:51 gaia pptp[13633]: anon log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer’s call ID 55081).
Feb 19 02:53:51 gaia pppd[13292]: rcvd [LCP ConfReq id=0x1 <mru 1500> <magic 0x1a36b692> ]
Feb 19 02:53:51 gaia pppd[13292]: sent [LCP ConfAck id=0x1 <mru 1500> <magic 0x1a36b692> ]
Feb 19 02:53:51 gaia pppd[13292]: sent [LCP ConfReq id=0x6 <asyncmap 0x0> <magic 0x70623e7c> ]
Feb 19 02:53:51 gaia pptp[13614]: anon warn[open_inetsock:pptp_callmgr.c:329]: connect: Connection timed out
Feb 19 02:53:51 gaia pptp[13614]: anon fatal[callmgr_main:pptp_callmgr.c:127]: Could not open control connection to 46.246.117.148
Feb 19 02:53:51 gaia pptp[13610]: anon fatal[open_callmgr:pptp.c:487]: Call manager exited with error 256
Feb 19 02:53:51 gaia pppd[13292]: Script pptp vpn.mon_vpn.net --nolaunchpppd finished (pid 13608), status = 0x1
Feb 19 02:53:53 gaia pppd[13292]: sent [LCP ConfReq id=0x6 <asyncmap 0x0> <magic 0x70623e7c> ]
Feb 19 02:53:54 gaia pppd[13292]: sent [LCP ConfReq id=0x6 <asyncmap 0x0> <magic 0x70623e7c> ]
Feb 19 02:53:56 gaia pppd[13292]: sent [LCP ConfReq id=0x6 <asyncmap 0x0> <magic 0x70623e7c> ]
Feb 19 02:53:57 gaia pppd[13292]: sent [LCP ConfReq id=0x6 <asyncmap 0x0> <magic 0x70623e7c> ]
Feb 19 02:53:59 gaia pppd[13292]: sent [LCP ConfReq id=0x6 <asyncmap 0x0> <magic 0x70623e7c> ]
Feb 19 02:54:00 gaia pppd[13292]: sent [LCP ConfReq id=0x6 <asyncmap 0x0> <magic 0x70623e7c> ]
Feb 19 02:54:02 gaia pppd[13292]: LCP: timeout sending Config-Requests
Feb 19 02:54:02 gaia pppd[13292]: Connection terminated.
Feb 19 02:54:02 gaia pppd[13292]: Modem hangup
Feb 19 02:54:02 gaia pptp[13623]: anon warn[decaps_hdlc:pptp_gre.c:204]: short read (-1): Input/output error
Feb 19 02:54:02 gaia pptp[13623]: anon warn[decaps_hdlc:pptp_gre.c:216]: pppd may have shutdown, see pppd log
Feb 19 02:54:02 gaia pptp[13633]: anon log[callmgr_main:pptp_callmgr.c:234]: Closing connection (unhandled)
Feb 19 02:54:02 gaia pptp[13633]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request’
Feb 19 02:54:02 gaia pptp[13633]: anon log[call_callback:pptp_callmgr.c:79]: Closing connection (call state)

Feb 19 02:54:02 gaia pppd[13292]: using channel 36
Feb 19 02:54:02 gaia pppd[13292]: Using interface ppp0
Feb 19 02:54:02 gaia pppd[13292]: Connect: ppp0 <–> /dev/pts/2
Feb 19 02:54:02 gaia pppd[13292]: Script pptp vpn.mon_vpn.net --nolaunchpppd finished (pid 13622), status = 0x0
Feb 19 02:54:02 gaia pptp[13641]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Feb 19 02:54:03 gaia pppd[13292]: sent [LCP ConfReq id=0x7 <asyncmap 0x0> <magic 0x1bdcb58e> ]
Feb 19 02:54:06 gaia pptp[13649]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request’
Feb 19 02:54:06 gaia pptp[13649]: anon log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
Feb 19 02:54:06 gaia pptp[13649]: anon log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
Feb 19 02:54:06 gaia pppd[13292]: sent [LCP ConfReq id=0x7 <asyncmap 0x0> <magic 0x1bdcb58e> ]
Feb 19 02:54:07 gaia pptp[13649]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request’
Feb 19 02:54:07 gaia pptp[13649]: anon log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
Feb 19 02:54:07 gaia pptp[13649]: anon log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer’s call ID 40963).
Feb 19 02:54:07 gaia pppd[13292]: rcvd [LCP ConfReq id=0x1 <mru 1500> <magic 0xe9dee4a4> ]
Feb 19 02:54:07 gaia pppd[13292]: sent [LCP ConfAck id=0x1 <mru 1500> <magic 0xe9dee4a4> ]
Feb 19 02:54:07 gaia pppd[13292]: rcvd [LCP ConfAck id=0x7 <asyncmap 0x0> <magic 0x1bdcb58e> ]
Feb 19 02:54:07 gaia pppd[13292]: sent [LCP EchoReq id=0x0 magic=0x1bdcb58e]
Feb 19 02:54:07 gaia pppd[13292]: rcvd [LCP ConfAck id=0x7 <asyncmap 0x0> <magic 0x1bdcb58e> ]
Feb 19 02:54:07 gaia pppd[13292]: rcvd [CHAP Challenge id=0x1 , name = “”]
Feb 19 02:54:07 gaia pppd[13292]: sent [CHAP Response id=0x1 <5cb160d5964aee3779c195b81a1c86f90000000000000000bcd2c914a5126f03f18e832c739f851c222a9433f974ad4a00>, name = “username”]
Feb 19 02:54:07 gaia pppd[13292]: rcvd [LCP EchoRep id=0x0 magic=0xe9dee4a4]
Feb 19 02:54:07 gaia pppd[13292]: rcvd [CHAP Success id=0x1 “S=7EFC49532CD49A48D3818795686DB78E8E12AE9D”]
Feb 19 02:54:07 gaia pppd[13292]: CHAP authentication succeeded
Feb 19 02:54:07 gaia pppd[13292]: sent [CCP ConfReq id=0x2 <mppe +H -M +S -L -D -C>]
Feb 19 02:54:07 gaia pppd[13292]: rcvd [IPCP ConfReq id=0x1 <addr (autre_ppp_remote_ip)> <compress VJ 0f 00>]
Feb 19 02:54:07 gaia pppd[13292]: sent [IPCP TermAck id=0x1]
Feb 19 02:54:07 gaia pppd[13292]: rcvd [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
Feb 19 02:54:07 gaia pppd[13292]: sent [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
Feb 19 02:54:07 gaia pppd[13292]: rcvd [CCP ConfAck id=0x2 <mppe +H -M +S -L -D -C>]
Feb 19 02:54:07 gaia pppd[13292]: MPPE 128-bit stateless compression enabled
Feb 19 02:54:07 gaia pppd[13292]: sent [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr (ppp_local_ip)> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Feb 19 02:54:07 gaia pppd[13292]: rcvd [IPCP ConfNak id=0x3 <addr (autre_ppp_local_ip)> <ms-dns1 (dns1_ip)> <ms-dns2 (dns2_ip)>]
Feb 19 02:54:07 gaia pppd[13292]: sent [IPCP ConfReq id=0x4 <compress VJ 0f 01> <addr (autre_ppp_local_ip)> <ms-dns1 (dns1_ip)> <ms-dns2 (dns2_ip)>]
Feb 19 02:54:10 gaia pppd[13292]: sent [IPCP ConfReq id=0x4 <compress VJ 0f 01> <addr (autre_ppp_local_ip)> <ms-dns1 (dns1_ip)> <ms-dns2 (dns2_ip)>]
Feb 19 02:54:13 gaia pppd[13292]: sent [IPCP ConfReq id=0x4 <compress VJ 0f 01> <addr (autre_ppp_local_ip)> <ms-dns1 (dns1_ip)> <ms-dns2 (dns2_ip)>]
Feb 19 02:54:16 gaia pppd[13292]: sent [IPCP ConfReq id=0x4 <compress VJ 0f 01> <addr (autre_ppp_local_ip)> <ms-dns1 (dns1_ip)> <ms-dns2 (dns2_ip)>]
Feb 19 02:54:19 gaia pppd[13292]: sent [IPCP ConfReq id=0x4 <compress VJ 0f 01> <addr (autre_ppp_local_ip)> <ms-dns1 (dns1_ip)> <ms-dns2 (dns2_ip)>]
Feb 19 02:54:22 gaia pppd[13292]: sent [IPCP ConfReq id=0x4 <compress VJ 0f 01> <addr (autre_ppp_local_ip)> <ms-dns1 (dns1_ip)> <ms-dns2 (dns2_ip)>]
Feb 19 02:54:25 gaia pppd[13292]: sent [IPCP ConfReq id=0x4 <compress VJ 0f 01> <addr (autre_ppp_local_ip)> <ms-dns1 (dns1_ip)> <ms-dns2 (dns2_ip)>]
Feb 19 02:54:28 gaia pppd[13292]: sent [IPCP ConfReq id=0x4 <compress VJ 0f 01> <addr (autre_ppp_local_ip)> <ms-dns1 (dns1_ip)> <ms-dns2 (dns2_ip)>]
Feb 19 02:54:31 gaia pptp[13649]: anon log[ctrlp_disp:pptp_ctrl.c:929]: Call disconnect notification received (call id 40963)
Feb 19 02:54:31 gaia pppd[13292]: sent [IPCP ConfReq id=0x4 <compress VJ 0f 01> <addr (autre_ppp_local_ip)> <ms-dns1 (dns1_ip)> <ms-dns2 (dns2_ip)>]
Feb 19 02:54:34 gaia pppd[13292]: sent [IPCP ConfReq id=0x4 <compress VJ 0f 01> <addr (autre_ppp_local_ip)> <ms-dns1 (dns1_ip)> <ms-dns2 (dns2_ip)>]
Feb 19 02:54:37 gaia pppd[13292]: sent [LCP EchoReq id=0x1 magic=0x1bdcb58e]
Feb 19 02:54:37 gaia pppd[13292]: IPCP: timeout sending Config-Requests
Feb 19 02:54:37 gaia pppd[13292]: MPPE disabled
Feb 19 02:54:37 gaia pppd[13292]: sent [LCP TermReq id=0x8 “MPPE disabled”]
Feb 19 02:54:37 gaia pppd[13292]: sent [LCP TermReq id=0x9 “MPPE disabled”]
Feb 19 02:54:40 gaia pppd[13292]: sent [LCP TermReq id=0xa “MPPE disabled”]
Feb 19 02:54:40 gaia pppd[13292]: Connection terminated.
Feb 19 02:54:40 gaia pppd[13292]: Modem hangup
Feb 19 02:54:40 gaia pptp[13641]: anon warn[decaps_hdlc:pptp_gre.c:204]: short read (-1): Input/output error
Feb 19 02:54:40 gaia pptp[13641]: anon warn[decaps_hdlc:pptp_gre.c:216]: pppd may have shutdown, see pppd log
Feb 19 02:54:40 gaia pptp[13649]: anon log[callmgr_main:pptp_callmgr.c:234]: Closing connection (unhandled)
Feb 19 02:54:40 gaia pptp[13649]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request’
Feb 19 02:54:40 gaia pptp[13649]: anon log[call_callback:pptp_callmgr.c:79]: Closing connection (call state)
[/code][/size]

Concernant le problème de deluged et de son flag -i, les symptômes sont les suivants :
Quand on lance deluged -i (ip écoute), j’ai l’impression qu’il ignore ce paramètre si dans le fichier de config cette information est déjà présente, même avec une autre IP.
Donc, si dans .config/deluge/core.conf cette information est absente, la première utilisation de déluged -i IP la renseigne, mais les utilisations suivantes l’ignorent.
J’ai une deluge 1.2, version packagée par Squeeze. Je pourrais monter en 1.3.2 en prenant le package Wheezy, mais ce package demande également une mise à jour de libc6-dev, je me pencherai sur ce problème plus tard. Pour l’instant, ma piste est de modifier directement le fichier de config (au format JSON !) plutôt que de passer par -i.