PPTP + ownCloud

Support Debian
#21

dig debian-fr.org @192.168.0.1

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.debian-fr.org @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38484
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;www.debian-fr.org.		IN	A

;; ANSWER SECTION:
www.debian-fr.org.	38388	IN	A	91.121.50.62

;; AUTHORITY SECTION:
debian-fr.org.		86387	IN	NS	ns.kimsufi.com.
debian-fr.org.		86387	IN	NS	daboog.zehome.com.
debian-fr.org.		86387	IN	NS	chp.zehome.com.

;; ADDITIONAL SECTION:
ns.kimsufi.com.		172787	IN	A	213.186.33.199
ns.kimsufi.com.		172787	IN	AAAA	2001:41d0:3:1c7::1
daboog.zehome.com.	172787	IN	A	178.33.46.1

;; Query time: 1 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Jan 17 21:08:41 2014
;; MSG SIZE  rcvd: 185

Et sur le client :


; <<>> DiG 9.8.3-P1 <<>> debian-fr.org @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 61488
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;debian-fr.org.			IN	A

;; Query time: 32 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Jan 17 21:09:30 2014
;; MSG SIZE  rcvd: 31

Je pense qu’on touche au but !

Voici le contenu de /etc/bind/named.conf.options

options {
	directory "/var/cache/bind";

	// If there is a firewall between you and nameservers you want
	// to talk to, you may need to fix the firewall to allow multiple
	// ports to talk.  See http://www.kb.cert.org/vuls/id/800113

	// If your ISP provided one or more IP addresses for stable 
	// nameservers, you probably want to use them as forwarders.  
	// Uncomment the following block, and insert the addresses replacing 
	// the all-0's placeholder.

	// forwarders {
	// 	0.0.0.0;
	// };

	//========================================================================
	// If BIND logs error messages about the root key being expired,
	// you will need to update your keys.  See https://www.isc.org/bind-keys
	//========================================================================
	dnssec-validation auto;

	auth-nxdomain no;    # conform to RFC1035
	listen-on-v6 { ::1; };
	listen-on { 127.0.0.1; 192.168.0.0/24; };
	allow-recursion { 127.0.0.1; ::1; 192.168.0.0/24; };
	allow-query { 192.168.0.0/24; };
};
#22

REFUSED, ça vient de la configuration de BIND.
Mais les options semblent correctes (allow-query et allow-recursion pour 192.168.0.0/24).
Tu as relancé bind pour prendre en compte les modifications ?
L’adresse VPN du client est bien dans cette plage ?

CORRECTION
Note: mets les mêmes valeurs dans allow-query que dans allow-recursion.

#23

Ne faudrait-il pas mettre “recursion yes;” pour activer cette fonctionnalité ?

#24

Pas besoin, c’est la valeur par défaut. D’ailleur cela fonctionne depuis le serveur, donc si la requête d’un client est refusée le problème vient de l’adresse source qui n’est pas acceptée.

Je corrige une erreur dans ma recommandation précédente : mets les mêmes valeurs dans allow-query que dans allow-recursion.

#25 
	listen-on { 127.0.0.1; 192.168.0.0/24; };
	allow-recursion { 127.0.0.1; 192.168.0.0/24; };
	allow-query { 127.0.0.1; 192.168.0.0/24; };

service bind9 reload
et service bind9 restart

J’ai toujours le même problème sur le client malheureusement.

#26

Problème résolu !

Pour une raison absolument inconnue, OS X reçoit une IP de type 192.168.1.X (le premier client reçoit 192.68.1.1). Du coup, j’ai mis 192.168.1.0/24 dans allow-recursion et ça semble maintenant fonctionner.
Je ne peux malheureusement pas tester cette configuration sur le firewall ce week-end, mais j’ai hâte de voir ce que ça donne lundi.

Comme il ne s’agit pas d’un serveur de production, je n’ai pas besoin d’une énorme sécurité. Je suppose que la distribution Debian 7 installée sur les Kimsufi d’OVH cachent déjà bind9 correctement (il était déjà pré-installé) pour éviter l’exploitation des failles potentielles.

Je vais maintenant m’attaquer la sécurisation d’ownCloud qui tourne pour le moment en HTTP.

Si vous avez une idée pourquoi mon client reçoit une adresse IP tout à fait en dehors de la plage définie ? C’est quand même étrange…

Un tout grand merci pour votre aide !

#27

Il n’y a pas une autre option remoteip qui traîne dans /etc/pptpd.conf ?

#28

Pas que je sache…

#29

Lorsqu’un client est connecté au VPN, qu’affiche la commande suivante sur le serveur ?

Cela devrait afficher une ligne de cette forme :

où <remote_ip> est l’adresse que pptpd dit à pppd d’attribuer au client. Ainsi on verra si c’est pptpd qui n’attribue pas les bonnes adresses où si ça vient d’ailleurs (pppd sur le serveur, client MacOS X…).

Tu peux aussi regarder dans les messages de pppd et pptpd dans /var/log/syslog.
Quelle est l’adresse IP des postes clients sur le réseau local ?

#30

En attendant,tu peux t’occuper de la zone DNS qui va contenir le nom du serveur et retourner l’adresse privée.

Dans /etc/bind/named.conf.local, ajouter

zone "nsXXXXXX.ip-XX-XXX-XXX.eu" { type master; file "/etc/bind/db.nsXXXXXX.ip-XX-XXX-XXX.eu"; };
Créer le fichier de zone /etc/bind/db.nsXXXXXX.ip-XX-XXX-XXX.eu

$TTL 604800 @ IN SOA nsXXXXXX.ip-XX-XXX-XXX.eu. root.nsXXXXXX.ip-XX-XXX-XXX.eu. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS nsXXXXXX.ip-XX-XXX-XXX.eu. @ IN A 192.168.0.1
Relancer bind.
Tester depuis le serveur ou le client VPN

#31

Il n’y a pas de client sur le réseau local car le serveur est tout seul chez OVH.

dig nsXXXXXX.ip-XX-XXX-XXX.eu @192.168.0.1

[code]; <<>> DiG 9.8.3-P1 <<>> nsXXXXXX.ip-XX-XXX-XXX.eu @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 52819
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;nsXXXXXX.ip-XX-XXX-XXX.eu. IN A

;; Query time: 16 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Mon Jan 20 08:13:49 2014
;; MSG SIZE rcvd: 43
[/code]

Il doit y avoir un petit soucis dans la configuration de la zone je pense…

Edit :

named-checkzone nsXXXXXX.ip-XX-XXX-XXX.eu /etc/bind/db.nsXXXXXX.ip-XX-XXX-XXX.eu

zone nsXXXXXX.ip-XX-XXX-XXX.eu/IN: loaded serial 1 OK

#32

Le même dig répond normalement sur le serveur mais est refusé sur le client. Étrange…

#33

Ça fonctionne !

J’ai juste changé /etc/bind/named.conf.options :

listen-on { 127.0.0.1; 192.168.0.0/24; 192.168.1.0/24; }; allow-recursion { 127.0.0.1; 192.168.0.0/24; 192.168.1.0/24; }; allow-query { 127.0.0.1; 192.168.0.0/24; 192.168.1.0/24; };

Voilà une affaire rondement menée ! Merci beaucoup pour votre aide PascalHambourg. Je vous en suis très reconnaissant !

PS : Pour le remoteip un peu bizarre, j’ai lu sur le Net que d’autres personnes étaient dans le même cas. Certaines ont pu s’en sortir en redémarrant leur serveur. Malheureusement, je ne peux pas le redémarrer pour le moment. Je verrai bien ce que ça donne lors du prochain redémarrage.

#34

D’après les options de la ligne de commande de pppd, c’est bien le démon pptpd (serveur PPTP) qui attribue une adresse en 192.168.1.x, en contradiction avec l’option remoteip de pptpd.conf.
Tu as essayé de redémarrer pptpd avec [mono]invoke-rc.d pptpd restart[/mono] ?
Si ça ne change rien, je suggère de remplacer la plage remoteip dans pptpd.conf en 192.168.1.x pour la faire correspondre avec la réalité et avec les autorisation d’accès de bind.

Je parlais de l’adresse du poste client sur son propre réseau local. Je me disais que peut-être il avait déjà une adresse en 192.168.0.x donc refusait celle attribuée par le VPN, mais ça me semblait quand même tiré par les cheveux.

Acessoirement, j’aurais choisi une plage d’adresses pour le VPN un peu moins couramment utilisée que 192.168.0.x ou 192.168.1.x (plage par défaut de beaucoup de box et réseaux locaux) afin d’éviter d’éventuels conflits. Mais s’il n’y a que 192.168.1.x qui marche…

#35

J’ai déjà redémarré PPTPD plusieurs fois (pour les diverses modifications de configuration). Ça n’a rien changé.

Je verrai ce que ça donne au prochain démarrage du serveur et j’adapterai les fichiers en conséquence afin que ça reste cohérent. Mais c’est quand même un peu bizarre.

L’adresse locale du client est 10.X.X.X donc il n’y a pas de conflit de ce côté-là.

Merci encore pour votre aide et votre temps !

#36

Help ! J’ai un problème avec BIND :

Plusieurs fois par jours, il s’arrête de fonctionner et chaque requête DNS est refusée à partir d’un client jusqu’à ce que je redémarre la connexion VPN (qui ne s’était pas arrêtée).

Dans le syslog, je vois que

named: listening on IPv4 interface ppp0, 192.168.0.1#53 named: binding TCP socket: address in use

Ensuite, toutes les requêtes DNS sont refusées.

Je n’ai pas fait attention aux heures, sauf ce matin où ce problème s’est produit exactement 1 heure après le lancement de la connexion VPN, ce qui me fait penser que BIND recharge la liste des interfaces toutes les heures.
J’ai pensé désactiver le scan des interfaces, mais est-ce que BIND répondra aux requêtes des clients du VPN si ppp0 n’est pas présente lors du démarrage du service ?

Merci !

#37

ProblèmeS résoluS !

J’ai killall pppd, pptpd et named. J’ai ensuite redémarré les services.

Le serveur PPTP donne maintenant une bonne adresse IP à partir du range remoteip.
Le serveur BIND ne refuse plus les requêtes (en tout cas plus depuis son re-lancement).

:041