PPTP + ownCloud

martinhou · Février 21, 2016, 7:46pm

Bonjour à tous,

J’ai un petit soucis de configuration avec mon serveur Debian 7 :

Je loue un petit serveur Kimsufi (OVH) sur lequel j’ai installé une Debian 7, un VPN de type PPTP et ownCloud 6 (à partir du repository d’openSUSE). Le nom de mon serveur est de type “nsXXXXXX.ip-XX-XXX-XXX.eu”. Comme il s’agit d’un serveur à usage strictement personnel, je n’ai pas besoin de nom de domaine.

Le VPN fonctionne bien.
Apache fonctionne bien (il affiche “It works!” lors de la connexion à la racine du serveur HTTP). Il affiche ce message que je me connecte en direct ou via mon VPN.
ownCloud ne fonctionne QUE lorsque je ne suis pas connecté au VPN. Dès que je me connecte au VPN et que j’essaye d’y accéder, il ne répond pas (que ce soit via un navigateur ou via leur client).

J’ai probablement oublié de configurer quelque chose, mais je ne sais pas quoi.

J’ai utilisé ce tutoriel pour configurer mon VPN : macsim.info/2013/11/18/tuto- … -et-ks-4g/

Merci pour votre aide,

Martin

martinhou · Février 21, 2016, 7:46pm

J’ai trouvé d’où vient le problème mais je ne sais pas comment le résoudre :

J’utilise OS X (Mavericks) et ce dernier n’utilise pas la connexion VPN pour se connecter à un site dont l’IP est identique à celle du VPN. Il utilise alors la connexion (Wi-Fi) de base. Malheureusement, cette connexion de base est très limitée. Du coup, le chargement de ownCloud échoue.

Connaissez-vous un moyen de forcer l’utiliser de la connexion VPN pour aller sur un site dont l’adresse IP est la même que celle utilisée par le VPN lui-même ?

J’ai déjà esssayé un “route -net change 192.168.0.0/24 -interface ppp0” mais ça ne donne rien. J’ai même essayé “route change default -interface ppp0”. Rien à faire, je passe toujours en dehors du VPN…

Mais ça dépasse probablement le cadre de ce forum, donc excusez-moi si ça devient hors-sujet.

Bien à vous,

Martin

PascalHambourg · Février 21, 2016, 7:46pm

C’est normal, et ce n’est pas spécifique à MacOS X. Ce serait la même chose avec Linux ou Windows. L’adresse IP du serveur VPN sert à transporter “l’extérieur” du VPN, on ne peut s’en servir “à l’intérieur” du VPN. L’affichage de la table de routage avec la commande [mono]route[/mono] devrait contenir une route spécifique pour cette adresse, afin de préserver son routage même lorsque le VPN est défini comme route par défaut. Si tu changes le routage de cette adresse, tu perds la connectivité avec le serveur VPN et donc le VPN lui-même.

Avec Linux on peut néanmoins utiliser du routage avancé pour que certaines communications vers l’adresse IP du serveur passent dans le VPN. Mais avec MacOS X je sais pas.

Un contournement simple serait de communiquer avec le serveur par son adresse privée dans le VPN au lieu de son adresse publique, visible avec [mono]ifconfig ppp0[/mono] en tant que [mono]pointopoint[/mono], à condition que owncloud écoute sur toutes les adresses locales et pas seulement l’adresse publique.

Limitée en quoi ? Si le VPN passe par cette connexion, ne va-t-il pas souffrir de la même limitation ?

martinhou · Février 21, 2016, 7:46pm

La connexion de base est très limitée à cause d’un firewall assez agressif. J’ai pu obtenir un laisser-passer pour ma connexion VPN, mais c’est tout.

Je ne dispose que d’un seul serveur et une seule IP, je ne peux donc pas dissocier le VPN de ownCloud.

Dans ma configuration PPTP, j’ai spécifié que la localeip est l’adresse IP publique du serveur. A-t-il une IP interne aussi (en se basant sur la configuration VPN que j’ai liée dans le premier message) ?

Mais le problème est que je dois accéder à ownCloud indifféremment avec ou sans connexion VPN. Ça me semble assez compliqué à faire avec un seul serveur, je me trompe ?

Merci encore pour votre aide !

PascalHambourg · Février 21, 2016, 7:46pm

A mon avis ce n’est pas une bonne idée car cela pourrait entraîner une confusion du routage dans et hors du VPN. Il vaudrait mieux définir [mono]localip[/mono] avec une autre adresse que l’adresse IP publique utilisée pour se connecteur au VPN, donc une adresse privée comme celles définies pour [mono]remoteip[/mono] si le serveur n’a qu’une adresse publique.

A moins de pouvoir faire du routage avancé (pour router certains ports de l’adresse publique vers l’adresse privée) ou du NAT destination (pour rediriger certains ports de l’adresse publique vers l’adresse privée) sur le poste MacOS X lorsque le VPN est lancé, cela va compliquer l’accès à owncloud puisqu’il faudra utiliser l’adresse privée avec le VPN et l’adresse publique sans le VPN.

Une possibilité pour accéder à owncloud indifféremment serait d’utiliser le nom d’hôte et non l’adresse IP, et de faire en sorte que sur le poste client le nom du serveur pointe vers l’adresse privée ou l’adresse publique selon le cas. Deux approches possibles :

modifier le fichier /etc/hosts sur le client pour ajouter/supprimer l’association entre l’adresse privée et le nom du serveur lors de l’établissement/arrêt du VPN ;
installer un serveur DNS sur le serveur qui renvoie l’adresse privée pour le nom du serveur (et la réponse normale pour toute autre requête), et définir l’adresse privée comme DNS dans pptpd afin que le poste client utilise ce serveur DNS lorsqu’il est connecté au VPN.

martinhou · Février 21, 2016, 7:46pm

Merci pour ces précisions !

Je pense plutôt me diriger vers la solution du serveur DNS sur le serveur car je préfère ne pas changer les fichiers hosts des clients.

Mon serveur n’a qu’une seule interface réseau (eth0). Est-ce que je peux mettre dans localip une autre valeur que l’IP publique ?
Est-ce que ceci fonctionnerait :

localip 192.168.0.1 remoteip 192.168.0.100-105
sachant que mon IP publique est totalement différente ? Comment va-t-il router le traffic entre 192.168.0.1 et l’adresse IP publique du serveur ? C’est automatique ?

Je devrais mettre :

à la place des DNS de Google dans mon pptpd-options alors ?

Auriez-vous un bon tutorial pour l’installation d’un serveur DNS sur Debian 7 (le plus simple possible, c’est ma première fois) qui corresponde plus ou moins à mon besoin ?

Merci beaucoup !

PascalHambourg · Février 21, 2016, 7:46pm

Oui, la route nécessaire est automatiquement créée sur le client à la connexion.

Pour le serveur DNS, ne te fais pas d’illusion, ça ne va pas être simple surtout pour une configuration de ce type.

martinhou · Février 21, 2016, 7:46pm

C’est déjà un peu plus clair.

Je vais donc devoir me pencher sur ce serveur DNS. Toute aide/information/site sont les bienvenus.

Merci encore pour votre aide !

martinhou · Février 21, 2016, 7:46pm

Suite aux messages de PascalHambourg, j’ai changé le localip en 192.168.0.1. Le serveur PPTP fonctionne correctement et ça m’a permis d’accéder à ownCloud via 192.168.0.1 lorsque je suis connecté sur le VPN. Ce n’est pas très pratique mais ça a l’avantage de fonctionner.

J’ai quand même un doute concernant l’usage de mon propre serveur DNS :

Lorsque je renseigne un mauvais serveur DNS dans la configuration PPTP (comme 192.168.0.1 qui n’est donc pas - encore - un serveur DNS), il ne m’est plus possible de surfer sur mes clients (normal). Par contre, si j’indique l’IP publique de mon serveur dans un navigateur, les clients arrivent quand même à se connecter en passant par les DNS de la connexion Wi-Fi.

Ce qui m’amène à penser que même avec un serveur DNS, Mac OS X s’obstinera à vouloir utiliser les DNS de la connexion Wi-Fi pour atteindre mon serveur…

PascalHambourg · Février 21, 2016, 7:46pm

Normal.

Heu, non. Quand on se connecte directement avec l’adresse IP d’un serveur, il n’y a pas de résolution DNS. La résolution DNS sert (entre autres) à résoudre un nom de domaine en adresse IP à laquelle on peut se connecter.

martinhou · Février 21, 2016, 7:46pm

Oui, je me suis mal exprimé : Dès que OS X voit que j’essaye d’accéder à la même adresse IP que celle du serveur VPN, il utilise la connexion Wi-Fi, peu importe les DNS précisés par le serveur PPTP. C’est pour ça que je me dis qu’installer un serveur DNS n’aidera pas.

Il faudrait que j’arrive à indiquer à OS X qu’il doit essayer 192.168.0.1 (IP privée) avant d’essayer nsXXXXXX.ip-XX-XXX-XXX.eu (nom ou IP public).

Ou alors d’avoir un petit script Bash qui redirige temporairement nsXXXXXX.ip-XX-XXX-XXX.eu vers 192.168.0.1 (avec la commande route peut-être) ?

PascalHambourg · Février 21, 2016, 7:46pm

Si : le but du serveur DNS, c’est de pouvoir utiliser le nom du serveur pour accéder à owncloud, pas son adresse privée ni publique. Quand on n’est pas connecté au VPN on utilise n’importe quel serveur DNS qui renvoie l’adresse publique. Quand on est connecté au VPN on utilise le serveur DNS du dédié qui renvoie l’adresse privée.

Tu peux essayer d’ajouter ceci dans /etc/hosts sur le poste client (où x.x.x.x est l’adresse publique) :

192.168.0.1 nsXXXXXX.ip-XX-XXX-XXX.eu x.x.x.x nsXXXXXX.ip-XX-XXX-XXX.eu
Mais ce n’est pas très propre, et je ne garantis pas que ça marche à tous les coups.

Le routage n’est pas concerné par les noms de domaine, il ne s’occupe que d’adresses IP. On en revient à ce que j’évoquais dans ma première réponse : ajouter la ligne [mono]192.168.0.1 nsXXXXXX.ip-XX-XXX-XXX.eu[/mono] dans /etc/hosts lorsque le VPN monte, et la supprimer lorsque le VPN tombe. Il faut les droits root pour modifier ce fichier. Sous Linux la partie PPP de connexion PPTP est gérée par pppd qui permet d’exécuter des scripts lorsque la session monte ou tombe, je ne sais pas ce qu’il en est sous MacOS X.

Pour préciser la configuration du serveur DNS.
Il devra assurer deux fonctions.

Résolution récursive. Tu peux définir des “redirecteurs” (forwarders) utilisant les DNS caches récursifs mis à disposition par l’hébergeur (OVH), les DNS ouverts de Google ou autres (ceux d’OpenDNS mentent et logguent, tous les autres loggent probablement).
Autorité pour le nom de domaine du serveur que tu utilises pour te connecter, retournant l’adresse privée de l’interface VPN.

Contrôle d’accès : accepter les requêtes proventant de la plage d’adresses privées du VPN seulement.

Implémentations possibles :

BIND (bind9). La résolution récursive sans redirecteur est activée par défaut ; ajouter une zone maître pour le nom du serveur contenant un enregistrement A avec l’adresse privée en plus des enregistrements NS et SOA obligatoires ; ajuster le contrôle d’accès. Pour les détails je peux aider.
Autre serveur DNS polyvalent (maradns, pdns, djbdns…). Je ne peux pas aider sauf pour le contenu de la zone, ne les connaissant pas.
dnsmasq. Ce n’est pas un véritable serveur DNS mais il peut suffire. Pour la résolution récursive, il passe par les DNS définis dans /etc/resolv.conf sur le serveur ; pour l’autorité, il utilise le contenu du fichier /etc/hosts sur le serveur ; ajuster le contrôle d’accès ; désactiver la fonction DHCP. Pour les détails je ne peux pas trop aider, ne l’utilisant pas.

martinhou · Février 21, 2016, 7:46pm

Merci pour ces réponses rapides !

Je pense installer bind9 alors. Il me semble assez “facile” à mettre en oeuvre.
Dans un premier temps, je pensais essayer ce tutoriel :

mindref.blogspot.be/2010/12/debi … erver.html

Si j’ai bien compris, ce tutoriel montre comment installer un serveur DNS bind9 dans sa configuration de base. Je suppose qu’il ne faudra plus qu’ajouter quelque part la résolution de nsXXXXXX.ip-XX-XXX-XXX.eu en 192.168.0.1.

J’espère être sur la bonne voie. J’essayerai ça ce soir.

Bien à vous,

Martin

martinhou · Février 21, 2016, 7:46pm

bind9 était déjà installé sur le serveur (ça tombe bien).

Voici ce que j’ai changé :

named.conf.options : listen-on { 127.0.0.1; }; en listen-on { any; };.

pptpd-options : ms-dns 8.8.8.8 en ms-dns 192.168.0.1

Malheureusement, ça ne fonctionne pas. Plus aucune URL ne fonctionnent.
Comment configurer correctement bind9 pour que ça fonctionne sachant que je ne souhaite pas prendre de nom de domaine ?

Merci !

PascalHambourg · Février 21, 2016, 7:46pm

J’aurais plutôt mis [mono]listen-on { localhost; 192.168.0.0/24; };[/mono] pour restreindre les requêtes au serveur et aux clients du VPN.
Que contient le reste de named.conf.options ?
BIND est bien démarré (processus [mono]named[/mono] présent) ?
Tu l’as redémarré ou reconfiguré avec [mono]rndc reconfig[/mono] après avoir modifié la configuration ?
Il répond aux requêtes depuis le serveur ?

Il y a des règles iptables sur le serveur (affichées par iptables-save)?

martinhou · Février 21, 2016, 7:46pm

J’ai changé en listen-on { 127.0.0.1; 192.168.0.0/24; };

J’ai redémarré bind9 avec la commande : service bind9 reload

Voici le résultat du dig :

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.debian-fr.org @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62644
;; 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.	38400	IN	A	91.121.50.62

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

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

;; Query time: 212 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jan 17 20:30:45 2014
;; MSG SIZE  rcvd: 185

Voici le résultat d’un nslookup :

Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
Name:	debian-fr.org
Address: 91.121.50.62

En ce qui concerne les règles iptables :

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -o eth0 -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 800:1536 -j TCPMSS --clamp-mss-to-pmtu

Ça me semble bon vu du serveur et pourtant ça ne fonctionne pas sur les clients…

martinhou · Février 21, 2016, 7:46pm

root@nsXXXXXX:~# service bind9 status
[ ok ] bind9 is running.

Il n’y a pas de service named.

Voici le contenu du fichier 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; };
};

PascalHambourg · Février 21, 2016, 7:46pm

J’ai confondu, pour restreindre les adresses de clients il faut utiliser l’option allow-query. listen-on sert à spécifier sur quelles adresses locales BIND écoute. Mais dans ton cas par effet de bord cela devrait aussi fonctionner.
Sur le serveur, que donne

Si cela fonctionne, que donne la même commande sur un poste avec le VPN connecté ?

martinhou · Février 21, 2016, 7:46pm

root@nsXXXXXX:~# dig www.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
;; connection timed out; no servers could be reached

Hum…

PascalHambourg · Février 21, 2016, 7:46pm

Je n’ai pas parlé d’un service mais d’un processus.
Vu le fichier : il faut ajouter 192.168.0.0/24 dans l’option allow-recursion.
J’ajouterais aussi une option allow-query avec le même contenu, car ce serveur n’a pas vocation à répondre à tout le monde, même pour les requêtes non récursives.

Mais un refus ne devrait pas provoquer un time-out, seulement une réponse REFUSED.
Ah, j’y pense, il faut que l’adresse 192.168.0.1 existe sur le serveur, donc qu’un client soit connecté au VPN…