Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 08-04-2017 20:10:58

Hassassin
Membre
Distrib. : Serveur : Debian 9 / Perso : MATE Ubuntu 16.10
Noyau : Serveur : 4.9.0-1-amd64 / Perso : 4.8.0-41-generic
(G)UI : Serveur : null / Perso : Compiz
Inscription : 21-06-2011

[Résolu] Requête externe impossible si connecté en VPN

Bonjour,

Il m'est impossible de me connecter depuis l’extérieur à mon serveur perso (debian 9) lorsque celui-ci est connecté à un serveur VPN. Quand je stop openVPN tout rentre dans l'ordre et je peux de nouveau accéder à ma machine http://ma-machine.
Je compare les règles de routage de ma machine quand le VPN est activé et quand il est désactivé mais sans trop comprendre les résultats retournés par la commande "ip route show".
Vous l'aurez probablement compris, je cherche à me connecter à ma machine même quand ce dernier est connecté au VPN.

L'ip local de ma machine est 192.168.0.150 et ma passerelle 192.168.0.254.

Connexion VPN arrêtée


ip route show
 


default via 192.168.0.254 dev eth0
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.150
 


Connexion VPN établie


ip route show
 


0.0.0.0/1 via 10.181.71.5 dev tun0
default via 192.168.0.254 dev eth0
10.181.71.1 via 10.181.71.5 dev tun0
10.181.71.5 dev tun0 proto kernel scope link src 10.181.71.6
128.0.0.0/1 via 10.181.71.5 dev tun0
185.84.181.99 via 192.168.0.254 dev eth0
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.150


Mon iptables temporaire (vierge pour ne pas accumuler les problèmes)

iptables -L



Chain INPUT (policy ACCEPT)
target     prot opt source               destination        
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
 


Merci d'avance pour l'aide que vous pourriez m'apporter.

Dernière modification par Hassassin (17-01-2018 14:54:07)

Hors ligne

#2 09-04-2017 00:45:02

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Requête externe impossible si connecté en VPN

Le programme qui monte le VPN crée entre autres les deux routes suivantes :

0.0.0.0/1 via 10.181.71.5 dev tun0
128.0.0.0/1 via 10.181.71.5 dev tun0


Elles ont pour effet de détourner la route par défaut pour la faire passer par le VPN au lieu du routeur du LAN.
Quand la machine reçoit un paquet de l'extérieur sur son interface ethernet eth0 via le routeur, elle y répond en envoyant un paquet par l'interface VPN tun0, via le routeur qui est à l'autre bout, sur le serveur VPN. Comme ces deux interfaces ont des adresses IP privées, chacun de ces deux routeurs fait forcément du NAT avec une adresse IP publique différente. La machine extérieure a envoyé un paquet à destination d'une adresse IP publique du routeur du LAN, et reçoit un paquet dont la source est une adresse IP publique du serveur VPN. Ça ne peut pas marcher, car la plupart des protocoles tablent sur le fait que la source de la réponse est identique à la destination de la requête.

Pour l'éviter, il va falloir faire du routage avancé. Ici un simple routage basé sur la source sera suffisant pour envoyer par l'interface eth0 les paquets sortants dont l'adresse source est celle d'eth0.

ip rule add from 192.168.0.150 table 99
ip route add 192.168.0.0/24 dev eth0 table 99
ip route add default via 192.168.0.254 dev eth0 table 99

Dernière modification par raleur (09-04-2017 00:45:16)

En ligne

#3 11-04-2017 09:17:10

Hassassin
Membre
Distrib. : Serveur : Debian 9 / Perso : MATE Ubuntu 16.10
Noyau : Serveur : 4.9.0-1-amd64 / Perso : 4.8.0-41-generic
(G)UI : Serveur : null / Perso : Compiz
Inscription : 21-06-2011

Re : [Résolu] Requête externe impossible si connecté en VPN

Merci pour la réponse. En recopiant bêtement les commandes, ça marche parfaitement.
Maintenant il ne me reste plus qu'à me documenter pour bien comprendre l'usage d'ip rule et route.

Hors ligne

#4 11-04-2017 10:35:11

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Requête externe impossible si connecté en VPN

La documentation sur le routage avancé est le "LARTC howto" (Linux Advanced Routing and Traffic Control).

La commande "ip rule" créer une règle de routage (à ne pas confondre avec une route) qui fait router les paquets dont l'adresse source est 192.168.0.150 par les routes de la table de routage 99 (numéro de table libre choisi arbitrairement).
Les commandes "ip route" créent deux routes dans cette table. Ce sont juste des copies de la route de sous-réseau ethernet et de la route par défaut via le routeur de ce sous-réseau qui existent dans la table de routage principale "main".

Effet : lorsque la machine envoie un paquet avec son adresse source 192.168.0.150, elle le route avec la table 99.
Les paquets de réponse aux paquets reçus via le routeur du LAN ont cette adresse source. Cela évite de les renvoyer par le VPN.

La route de sous-réseau peut être nécessaire pour que la machine continue à pouvoir communiquer directement avec les autres machines du sous-réseau. Sinon tout le trafic destiné à ces machines serait envoyé au routeur, qui devrait ensuite le renvoyer vers la machine destinataire.

En ligne

#5 15-01-2018 20:22:37

Hassassin
Membre
Distrib. : Serveur : Debian 9 / Perso : MATE Ubuntu 16.10
Noyau : Serveur : 4.9.0-1-amd64 / Perso : 4.8.0-41-generic
(G)UI : Serveur : null / Perso : Compiz
Inscription : 21-06-2011

Re : [Résolu] Requête externe impossible si connecté en VPN

Mmm je viens de remarquer que depuis l'installation de docker, une interface docker0 vient me mettre la pagaille.
Une application web tourne sous docker et fonctionne correctement sauf lorsque j'active le VPN.

0.0.0.0/1 via 10.181.71.49 dev tun0
default via 192.168.0.254 dev eth0
10.181.71.1 via 10.181.71.49 dev tun0
10.181.71.49 dev tun0 proto kernel scope link src 10.181.71.50
128.0.0.0/1 via 10.181.71.49 dev tun0
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
185.84.181.71 via 192.168.0.254 dev eth0
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.150


J'ai essayé de corrigé le problème avec les infos données dans le post précédent mais je n'ai toujours pas bien compris le fonctionnement d'ip route/rule.

Ma tentative ratée :

ip rule add from 172.17.0.1 table 98
ip route add default via 192.168.0.254 dev eth0 table 98

Hors ligne

#6 15-01-2018 21:44:33

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Requête externe impossible si connecté en VPN

1) Pas besoin d'utiliser une autre table, la 99 ira très bien.
2) 172.17.0.1 n'est pas l'adresse de l'application docker mais l'adresse de l'interface de la machine hôte utilisée pour communiquer avec l'application docker. L'adresse de l'application docker est dans le bloc 172.17.0.0/16.
3) Il faut dupliquer dans la table 99 toutes les routes présentes dans la table principale lorsque le VPN n'est pas monté.

Essaie ceci en remplacement de mes commandes précédentes :

ip rule add from 192.168.0.150 table 99
ip rule add from 172.17.0.0/16 table 99
ip route add 192.168.0.0/24 dev eth0 table 99
ip route add 172.17.0.0/16 dev docker0 table 99
ip route add default via 192.168.0.254 dev eth0 table 99



PS : vire le RESOLU du titre si ce n'est plus résolu, je ne me souvenais pas de cette discussion et j'ai failli ne pas l'ouvrir en pensant que c'était déjà résolu.

Dernière modification par raleur (15-01-2018 21:49:58)

En ligne

#7 16-01-2018 10:20:09

Hassassin
Membre
Distrib. : Serveur : Debian 9 / Perso : MATE Ubuntu 16.10
Noyau : Serveur : 4.9.0-1-amd64 / Perso : 4.8.0-41-generic
(G)UI : Serveur : null / Perso : Compiz
Inscription : 21-06-2011

Re : [Résolu] Requête externe impossible si connecté en VPN

Merci bien.
Je teste ça dans la journée et repasserai dans le coin.

C'était en résolu car à l'époque Docker n'était pas installé. wink

Hors ligne

#8 16-01-2018 10:35:27

Hassassin
Membre
Distrib. : Serveur : Debian 9 / Perso : MATE Ubuntu 16.10
Noyau : Serveur : 4.9.0-1-amd64 / Perso : 4.8.0-41-generic
(G)UI : Serveur : null / Perso : Compiz
Inscription : 21-06-2011

Re : [Résolu] Requête externe impossible si connecté en VPN

Je viens de tester, ça ne résout pas mon problème.
Mais peut-être qu'il y a besoin de donner un peu plus d'informations.

Docker est utilisé pour faire tourner l'application Collabora/Code pour Nextcloud. L'application est servi par apache via Proxy.
La méthode suivi (et donc le fichier de config pour collabora/code) est celle-ci : https://debian-facile.org/doc:reseau:ne … ora-online.

Depuis l'extérieur j'accède bien à tous mes vhost. Nextcloud fonctionne. En revanche si dans Nextcloud je souhaite éditer un fichier via collabora/code, j'ai un message d'erreur (en local comme à distance) quand ce dernier est appelé.

Et tout fonctionne correctement dès lors que je coupe la connexion VPN.

Dernière modification par Hassassin (16-01-2018 10:36:41)

Hors ligne

#9 16-01-2018 12:56:45

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Requête externe impossible si connecté en VPN

Quel message d'erreur ?

Peux-tu decrier les flux réseau mis en jeu lors de cette opération ?

Si j'ai bien compris, la connexion arrive sur apache qui renvoie vers 127.0.0.1:9980 et docker redirige vers le conteneur qui fait tourner l'application.
Je ne vois même pas où l'interface docker0 est impliquée.

En ligne

#10 16-01-2018 13:10:53

Hassassin
Membre
Distrib. : Serveur : Debian 9 / Perso : MATE Ubuntu 16.10
Noyau : Serveur : 4.9.0-1-amd64 / Perso : 4.8.0-41-generic
(G)UI : Serveur : null / Perso : Compiz
Inscription : 21-06-2011

Re : [Résolu] Requête externe impossible si connecté en VPN

Je ne vois pas non plus... sad

Le message d'erreur n'est pas parlant :

Erreur interne du serveur
Le serveur a rencontré une erreur interne et est incapable d'exécuter votre requête.
Veuillez contacter l'administrateur du serveur si cette erreur apparaît plusieurs fois. Veuillez joindre les détails techniques à votre rapport.
Le fichier journal du serveur peut fournir plus de renseignements.

Renseignements techniques
Adresse distante : 192.168.0.254


Et dans le log de Nextcloud se sont des messages d'erreurs : code du fichier X.js ou X.php à la ligne X a merdé.

Apache me donne comme message d'erreur :

 [access_compat:error] [pid 792] [client mon-ip_vpn:39008] AH01797: client denied by server configuration: proxy:https://127.0.0.1:9980/hosting/discovery


Comment puis-je analyser le flux ?

Dernière modification par Hassassin (16-01-2018 13:13:39)

Hors ligne

#11 16-01-2018 15:51:30

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Requête externe impossible si connecté en VPN

Hassassin a écrit :

Le message d'erreur n'est pas parlant


C'est un message d'erreur du navigateur, du proxy ou du serveur ?
L'adresse IP mentionnée est bien celle du routeur (passerelle) ? Si oui, que vient-elle faire là ?

Hassassin a écrit :

Et dans le log de Nextcloud se sont des messages d'erreurs : code du fichier X.js ou X.php à la ligne X a merdé.


Sur quel genre d'instruction ?

Hassassin a écrit :

Apache me donne comme message d'erreur


Où est le navigateur et quel est le nom de domaine et l'adresse IP de l'URL qui provoque l'erreur ?

En ligne

#12 16-01-2018 18:38:18

Hassassin
Membre
Distrib. : Serveur : Debian 9 / Perso : MATE Ubuntu 16.10
Noyau : Serveur : 4.9.0-1-amd64 / Perso : 4.8.0-41-generic
(G)UI : Serveur : null / Perso : Compiz
Inscription : 21-06-2011

Re : [Résolu] Requête externe impossible si connecté en VPN

C'est un message dans la page web. (message d'erreur de Nextcloud)
L'adresse IP est bien celle de la passerelle quand je tente depuis le réseau local autrement c'est l'adresse IP public du poste distant (extérieur au réseau local) qui apparaît.

Le log dans nextcloud :

GuzzleHttp\Exception\ClientException: Client error response [url] https://bureau.mondomaine.fr/hosting/discovery [status code] 403 [reason phrase] Forbidden

    /var/www/classeur/3rdparty/guzzlehttp/guzzle/src/Subscriber/HttpError.php - line 32: GuzzleHttp\Exception\RequestException create(Object(GuzzleHttp\Message\Request), Object(GuzzleHttp\Message\Response))
    /var/www/classeur/3rdparty/guzzlehttp/guzzle/src/Event/Emitter.php - line 108: GuzzleHttp\Subscriber\HttpError->onComplete(Object(GuzzleHttp\Event\CompleteEvent), 'complete')
    /var/www/classeur/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php - line 91: GuzzleHttp\Event\Emitter->emit('complete', Object(GuzzleHttp\Event\CompleteEvent))
    /var/www/classeur/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php - line 132: GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))
    /var/www/classeur/3rdparty/react/promise/src/FulfilledPromise.php - line 25: GuzzleHttp\RequestFsm->GuzzleHttp\{closure}(Array)
    /var/www/classeur/3rdparty/guzzlehttp/ringphp/src/Future/CompletedFutureValue.php - line 55: React\Promise\FulfilledPromise->then(Object(Closure), NULL, NULL)
    /var/www/classeur/3rdparty/guzzlehttp/guzzle/src/Message/FutureResponse.php - line 43: GuzzleHttp\Ring\Future\CompletedFutureValue->then(Object(Closure), NULL, NULL)
    /var/www/classeur/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php - line 134: GuzzleHttp\Message\FutureResponse proxy(Object(GuzzleHttp\Ring\Future\CompletedFutureArray), Object(Closure))
    /var/www/classeur/3rdparty/guzzlehttp/guzzle/src/Client.php - line 165: GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))
    /var/www/classeur/3rdparty/guzzlehttp/guzzle/src/Client.php - line 125: GuzzleHttp\Client->send(Object(GuzzleHttp\Message\Request))
    /var/www/classeur/lib/private/Http/Client/Client.php - line 138: GuzzleHttp\Client->get('https //bureau....', Array)
    /var/www/classeur/apps/richdocuments/lib/WOPI/DiscoveryManager.php - line 84: OC\Http\Client\Client->get('https //bureau....')
    /var/www/classeur/apps/richdocuments/lib/WOPI/Parser.php - line 41: OCA\Richdocuments\WOPI\DiscoveryManager->get()
    /var/www/classeur/apps/richdocuments/lib/TokenManager.php - line 122: OCA\Richdocuments\WOPI\Parser->getUrlSrc('application/vnd...')
    /var/www/classeur/apps/richdocuments/lib/Controller/DocumentController.php - line 168: OCA\Richdocuments\TokenManager->getToken(*** sensitive parameters replaced ***)
    [internal function] OCA\Richdocuments\Controller\DocumentController->index('258105')
    /var/www/classeur/lib/private/AppFramework/Http/Dispatcher.php - line 160: call_user_func_array(Array, Array)
    /var/www/classeur/lib/private/AppFramework/Http/Dispatcher.php - line 90: OC\AppFramework\Http\Dispatcher->executeController(Object(OCA\Richdocuments\Controller\DocumentController), 'index')
    /var/www/classeur/lib/private/AppFramework/App.php - line 114: OC\AppFramework\Http\Dispatcher->dispatch(Object(OCA\Richdocuments\Controller\DocumentController), 'index')
    /var/www/classeur/lib/private/AppFramework/Routing/RouteActionHandler.php - line 47: OC\AppFramework\App main('OCA\\Richdocumen...', 'index', Object(OC\AppFramework\DependencyInjection\DIContainer), Array)
    [internal function] OC\AppFramework\Routing\RouteActionHandler->__invoke(Array)
    /var/www/classeur/lib/private/Route/Router.php - line 299: call_user_func(Object(OC\AppFramework\Routing\RouteActionHandler), Array)
    /var/www/classeur/lib/base.php - line 1004: OC\Route\Router->match('/apps/richdocum...')
    /var/www/classeur/index.php - line 48: OC handleRequest()
    {main}


bureau.mondomaine.fr = Collabora/code
classeur.mondomaine.fr = Nextcloud

Où est le navigateur et quel est le nom de domaine et l'adresse IP de l'URL qui provoque l'erreur ?


Euh... Apache ne me donne pas ces précisions dans error.log

Hors ligne

#13 17-01-2018 14:53:35

Hassassin
Membre
Distrib. : Serveur : Debian 9 / Perso : MATE Ubuntu 16.10
Noyau : Serveur : 4.9.0-1-amd64 / Perso : 4.8.0-41-generic
(G)UI : Serveur : null / Perso : Compiz
Inscription : 21-06-2011

Re : [Résolu] Requête externe impossible si connecté en VPN

Problème réglé on dirait après avoir totalement désactivé ipv6 : (dans /etc/sysctl.conf)

# Ajout des lignes
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.default.autoconf = 0
 

Hors ligne

#14 18-11-2018 15:17:59

zaoui
Membre
Inscription : 18-11-2018

Re : [Résolu] Requête externe impossible si connecté en VPN

raleur a écrit :

Le programme qui monte le VPN crée entre autres les deux routes suivantes :

0.0.0.0/1 via 10.181.71.5 dev tun0
128.0.0.0/1 via 10.181.71.5 dev tun0


Elles ont pour effet de détourner la route par défaut pour la faire passer par le VPN au lieu du routeur du LAN.
Quand la machine reçoit un paquet de l'extérieur sur son interface ethernet eth0 via le routeur, elle y répond en envoyant un paquet par l'interface VPN tun0, via le routeur qui est à l'autre bout, sur le serveur VPN. Comme ces deux interfaces ont des adresses IP privées, chacun de ces deux routeurs fait forcément du NAT avec une adresse IP publique différente. La machine extérieure a envoyé un paquet à destination d'une adresse IP publique du routeur du LAN, et reçoit un paquet dont la source est une adresse IP publique du serveur VPN. Ça ne peut pas marcher, car la plupart des protocoles tablent sur le fait que la source de la réponse est identique à la destination de la requête.

Pour l'éviter, il va falloir faire du routage avancé. Ici un simple routage basé sur la source sera suffisant pour envoyer par l'interface eth0 les paquets sortants dont l'adresse source est celle d'eth0.

ip rule add from 192.168.0.150 table 99
ip route add 192.168.0.0/24 dev eth0 table 99
ip route add default via 192.168.0.254 dev eth0 table 99



bonjour a tous
merci pour cette solution qui fonctionne sur mon serveur. mais comment automatiser au démarrage ? je ne trouve pas ...
merci d avance

Hors ligne

Pied de page des forums