Vpn + apache = apache invisible depuis l'exterieur

Support Debian
#1

Salut à tous

Dabord je precise que je connais tout juste le necessaire dans le reseau et linux pour pouvoir
entretenir un petit serveur web et travailler, alors merci d’avance pour votre patience.
J’ai lu pas mal de sujets qui parlent +ou- du meme probleme mais impossible de trouver une solution soit parceque je ne comprends rien, au alors c’est pas tout a fait le meme cas etc…

j’ai donc apache2 avec mes petites pages qui fonctionnent bien en local et en externe.
J’ai en paralelle pris un nom de domaine ovh…
Mon travail m’impose aujourd’hui de passer par un VPN (client openvpn) qui fonctionne bien aussi
et l’admin du serveur VPN m’a assuré qu’il ne bloque rien.
Or lorsque celui ci est connecte je n’arrive plus à acceder à mes pages depuis l’exterieur (testé avec ip ou domaine)
tjrs vpn connecté, j’ai teste aussi avec un autre pc en local avec mon ip 192.168 ca marche, et avec mon domaine aussi

Je mets en dessous differentes infos, si quelqu’un aurait au moins une piste car la je desespere…

version linux debian squeeze : 2.6.32-5-amd64

apache2.conf : par defaut avec tout les includes qui vont bien

le fichier /etc/apache2/sites-enabled/000-default

<VirtualHost *:80>
ServerAdmin webmaster@localhost
ServerName www.mondomaine.fr
DocumentRoot /var/www

Options FollowSymLinks
AllowOverride None

<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

mon hosts :127.0.0.1
127.0.0.1 Lan localhost.localdomain localhost

ifconfig :
eth0 Link encap:Ethernet HWaddr 50:46:5d:50:5b:95
inet adr:192.168.0.10 Bcast:192.168.0.255 Masque:255.255.255.0
adr inet6: fe80::5246:5dff:fe50:5b95/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:29895 errors:0 dropped:0 overruns:0 frame:0
TX packets:27188 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:4316201 (4.3 MiB) TX bytes:26623921 (25.9 MiB)
Interruption:28 Adresse de base:0x8000

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:14046 errors:0 dropped:0 overruns:0 frame:0
TX packets:14046 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:4409740 (4.2 MiB) TX bytes:4409740 (4.2 MiB)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet adr:xxx.xxx.xxx.xxx P-t-P:xxx.xxx.xxx.xxx Masque:255.255.0.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:426 errors:0 dropped:0 overruns:0 frame:0
TX packets:272 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:100
RX bytes:4332860 (4.3 MiB) TX bytes:1566609 (1.4 MiB)

#2

Je penche pour un problème de routage. Si tu as redéfini le VPN comme route par défaut, alors les paquets de réponse du serveur web sortent par le VPN au lieu de sortir directement par le réseau local puis la connexion internet. A vérifier avec route -n ou ip route lorsque le VPN est actif.
Dans ce cas, toutes les communications avec internet passent par le VPN pour ressortir de l’autre côté. Par contre les communications avec le réseau local ne sont pas affectées parce que la route correspondante est prioritaire sur la route par défaut.
Deux possibilités s’offrent alors à toi :

  • Si tu n’as pas réellement besoin que la route par défaut soit redéfinie lorsque le VPN est actif, alors il suffit de configurer le VPN pour ne pas la modifier, et au besoin d’ajouter des routes vers les plages d’adresse qui se trouvent de l’autre côté du VPN. Exemple :
  • Si tu as besoin que la route par défaut soit redéfinie lorsque le VPN est actif, alors il faut mettre en place du routage avancé pour que les réponses aux paquets reçus hors VPN ne partent pas dans le VPN. La façon la plus simple est de se baser sur l’adresse source des paquets sortants. Cela ne fonctionne pas toujours pour le protocole UDP, mais pas de problème en TCP donc en HTTP.

ip rule add from 192.168.0.10 table 100 ip route add 192.168.0.0/24 dev eth0 table 100 ip route add default via 192.168.0.x table 100
où 192.168.0.10 est l’adresse de ta machine et 192.168.0.x celle de la passerelle (routeur, box).

#3

Merci de prendre le temps et effectivement, d’apres ce que je comprends tout semble passer par le tunnel…

Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
212.x.x.x 192.168.0.126 255.255.255.255 UGH 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
225.x.x.x 0.0.0.0 255.255.0.0 U 0 0 0 tun0
0.0.0.0 212.x.x.x 0.0.0.0 UG 0 0 0 tun0

excuse moi de te repondre en neuneu mais globalement mon besoin est d’avoir le vpn connecté quasi en permanence pour me connecter sur une interface web qui necessite la cnx vpn et que mes pages soit accessible par n’importe qui.

Malheureusement je ne comprends pas les incidences que tes conseils peuvent avoir sur ma connexion

ce que je comprend pour la solution 1 c’est que seules les ip de la plage d’ip distantes definie, communiqueront dans le tunnel avec mon pc

et pour la solution 2… l’exemple que tu donne me fait dire que tout le traffic passe en dehors du tunnel.
je ne vois pas comment ces regles peuvent distinguer une communication susceptible de passer par le vpn d’une autre qui passerait en dehors.

tu me donnes deja une bonne base de part, merci à toi

#4

Effectivement la table de routage montre que le VPN a réécrit la route par défaut pour qu’elle passe par son interface tun0.

Si l’adresse de l’interface web à laquelle tu dois accéder via le VPN est dans la plage 225.x.0.0/255.255.0.0 (ou écrit au format CIDR 225.x.0.0/16, soit l’intervalle 225.x.0.0-225.x.255.255), alors la route par défaut n’a pas besoin d’être réécrite, il faut désactiver cette option dans la configuration du VPN. Quel type de VPN est-ce ?

Si l’adresse n’est pas dans la plage, ce qui me surprendrait étant donné son étendue, alors tu peux quand même l’ajouter avec une route comme dans mon exemple.

[quote=“yourible”]et pour la solution 2… l’exemple que tu donne me fait dire que tout le traffic passe en dehors du tunnel.
je ne vois pas comment ces regles peuvent distinguer une communication susceptible de passer par le vpn d’une autre qui passerait en dehors.[/quote]
Non, pas tout le trafic.
La première commande (ip rule) crée une règle pour appliquer une table de routage spéciale (n° 100, choisi arbitrairement entre 1 et 252) aux paquets émis avec l’adresse source 192.168.0.10. Les paquets qui n’ont pas encore d’adresse source définie ou les paquets qui on déjà l’adresse source de tun0 restent routés avec la table de routage principale (numéro 254), celle qui est affichée par la commande route, dont la route par défaut passe par l’interface tun0 du VPN.

#5

le VPN? une connexion openvpn configuree sous gnome avec l’interface qui va bien, une ip de connexion et des identifiants :wink: paramatres ipv4 en auto, aucunes routes… idem pour eth0 (en dhcp avec un bail permanent…pas de route)
et pour le reste tout est par defaut pas de parametres supplementaires…

ta solution 2 me parait correspondre à mes besoins…
je vais deja me pencher la dessus me documenter ce soir et experimenter.

par contre je suppose qu’il y a une commande ip rule del …quelque chose ou ip route del…quelquechose
pour supprimer ces regles ? ou peut etre je peux les definir directement dans l’applet de configuration ?

j’ai vite fait jeté un oeil sur la man page mais si tu pouvais juste me donner la commande inverse
ce me fera une bonne base de depart pour experimenter et m’eviter de tout mettre en l’air faut que
je sois operationnel pour le boulot demain matin :wink:

#6

Dans les paramètres du VPN OpenVPN, onglet “Paramètres IPv4”, bouton “Routes…” il y a une option “Utiliser cette connexion uniquement pour les ressource de son réseau”. Si tu l’actives, le VPN ne servira pas de route par défaut. C’est dans cette même fenêtre que tu peux ajouter une route vers l’adresse de l’interface web à atteindre par le VPN si besoin.

  1. Coche cette option, relance le VPN et vérifie si l’interface web sur laquelle tu dois travailler reste accessible. Si oui, alors c’est tout ce que tu as à faire et ton serveur web devrait être redevenu accessible.

  2. Sinon, ajoute une route pour l’adresse de cette interface web dans la fenêtre “Routes” du VPN et relance-le.

Oui, il suffit de remplacer “add” par “del” mais il n’est pas nécessaire de les supprimer, elles ne gênent en rien.

Je ne sais pas, je ne connais pas assez network-manager.

#7

c’est partit :slightly_smiling:
Merci pour tes bons conseils, je fais un suivi si ca peut interresser quelqu’un

#8

Avant de te dire un gd merci je voulais savoir si y a moyen de mettre ces regles en static car au reboot je suis obligé de retaper les commandes pour que ca fonctionne. ou si je dois faire un script…
Sinon cas ca fonctionne à merveille !!! :041

ip rule add from 192.168.0.10 table 100
ip route add 192.168.0.0/24 dev eth0 table 100
ip route add default via 192.168.0.x table 100

#9

en fait le routage ne fonctionne plus des lors que eth0 est deconnecte, par contre les cnx/decnx du vpn ne pose pas de pb

#10

Le routage avancé avec ip rule/route, ça reste de l’artillerie lourde et pas pratique. Tu n’as pas essayé l’autre méthode que je suggérais, modifier les paramètres de la connexion VPN ? C’est quand même plus simple.

Comme toutes les commandes de base du réseau (ifconfig, route, ip…), l’effet de ces commandes est volatil car elles agissent directement sur le noyau sans écrire dans un fichier persistant. J’aurais su te dire comment les exécuter automatiquement si eth0 était gérée par ifupdown via le fichier /etc/network/interfaces (avec un script exécuté par une option post-up), mais comme je l’ai déjà dit je connais très mal network-manager.

Qu’entends-tu exactement par “eth0 est déconnectée” ?
En tout cas, quand une interface est désactivée, toutes les routes associées sont supprimées. Les deux routes créées dans la table 100, liées à eth0, sont donc supprimées si eth0 est désactivée. Et comme je l’ai dit l’effet de ces commandes est volatil, ça ne revient pas tout seul.

J’ai conscience que les solutions que je propose sont souvent partielles car leur mise en oeuvre complète (persistance, automatisation…) dépend des particularités du système sur lequel elles doivent être intégrées. Mais bon, il faut bien laisser un peu de travail aux bénéficiaires…

#11

je vais me pencher sur les autres methodes… malgré que j’ai vulu essayer de mettre l’ip de l’interface directement dans le ntwork-manager mais en vain j’ai l’impression que ca na pas d’effet.
De plus l’interface demande une passerelle et un métrique ?!?

Hier soir je suis resté sur ce qui marche et j’ai tenté de bricoler un bash qui se lance au demarrage (et oui la nuit à ete longue…), qui teste si eth0 est deconnecte auquel cas il execute les ip rule/route.
ca fonctionne pas encore, les commandes ip rule/route necessitent les droits admin apparement :
RTNETLINK answers: Operation not permitted
je vais essayer de trouver le moyen d’executer le bash au demarrage de la machine et de mettre ces commandes dans une boucle infinie qui teste en continue la connexion

je cherchais une piste de recherche tu as plus que repondu a mes attentes. Un grand merci donc !
je continue à creuser…

j’etais il y a encore 1 mois sous windows, je me rends compte qu’avec Linux il y à
toujours une solution !

#12

Apparemment, pour faire exécuter un script par network manager, il faut le placer dans le répertoire /etc/NetworkManager/dispatcher.d/ et il doit avoir la forme suivante :

[code]#!/bin/bash

INTERFACE=$1
STATUS=$2

if [ “$INTERFACE” == “eth0” ]
then
case “$STATUS” in
up)
# inserer les commandes ip route add et ip rule add ici
;;
down)
# inserer les commandes ip route del et ip rule del ici
;;
pre-up)
;;
post-down)
;;
*)
;;
esac
fi[/code]
Il doit bien sûr avoir les droits exécutable (chmod +x).
Sans garantie, pas testé.

#13

n’ayant pas les competences pour faire mieux j’ai bricolé un bash en parcourant un peu
google… le script permet de redefinir les regles automatiquement à la reconnexion du vpn
pour cela jutilise le retour en boucle de “nmcli con status” en comptant la longueur de varp
ensuite comme la commande IP necessitant les droits admin, j’ai mis cette ligne dans le fichier etc/sudoers : monlogin ALL = NOPASSWD: /bin/ip
qui me donne acces à la commande ip sans mot de passe
puis j’ai ulisé dans gnome le gestionnaire d’applications au demarrage pour lancer le script
au debut de chaque session.

ca va en faire rire certains mais c’est le resultat d’une bonne journee de recherches
je sais… c’est surement pas la meilleure methode, mais ca marche a tout les coups :wink:

au passage : p**** c’est vrai que linux c’est pas mal qd même… je decouvre…

#!/bin/bash

while :
do
	varp=$(nmcli con status)
        #si le vpn est actif
	if [ ${#varp} -eq 305 ]; then

	sudo ip rule add from 192.168.0.10 table 100
	sudo ip route add 192.168.0.0/24 dev eth0 table 100
	sudo ip route add default via 192.168.0.126 table 100

	else

	sudo ip rule del from 192.168.0.10 table 100
	sudo ip route del 192.168.0.0/24 dev eth0 table 100
	sudo ip route del default via 192.168.0.126 table 100

sleep 10
#14

Ça ne me paraît quand même pas très optimal, comme méthode. Si je comprends bien, tant que le VPN est actif, toutes les 10 secondes ton script va créer une nouvelle règle (ip rule) qui va s’empiler au-dessus de celles déjà existantes. Contrairement aux routes cette règle n’est pas supprimée si eth0 tombe, il suffit donc de la créer une fois pour toutes au démarrage de la machine.