Je n’ai pas répondu à ta 2ème question :
Ben oui je voudrais que mon site soit accessible par son adresse publique normale lorsqu’il est client VPN.
Mais actuellement ça ne marche pas, car avec mon ordi portable 3G j’essaie d’y accéder de l’extérieur et en fait j’ouvre la page d’accueil de freedom-ip
Visiblement le nom de domaine de ton site pointe vers l’adresse IP du serveur VPN. On a déjà vu que ça ne peut pas marcher, le serveur VPN ne faisant pas la redirection. Le nom de domaine de ton site doit pointer en permanence vers l’adresse IP publique de la connexion internet “normale”. Si l’adresse IP est mise à jour automatiquement avec un client de DNS dynamique depuis ton serveur, alors il faudra faire en sorte qu’il annonce l’adresse IP publique de la connexion internet normale et non celle du VPN.
Bonjour,
YYYYYYYYYYEEEEEEEEEEEEEEEEAAAAAAAAAAAAAAAHHHHHHHHHHHHH !!!
ça marche >> lorsque le vpn était désactivé j’ai stoppé mon ddclient pour conserver mon IP de FAI >>>> puis réactivation du VPN et là … Miracle ou plutôt non, je doit reconnaitre avoir eu l’aide d’une vraie compétence.
Un grand merci à PascalHambourg
Je dois maintenant automatiser et pérenniser les [ip route] et [ip rule] pour qu’à chaque [reboot] mon vpn s’active.
Merci encore
Il faut donc empêcher ddclient de faire la mise à jour de l’adresse via le VPN, ou le forcer à passer par la connexion internet normale. Je ne connais pas bien le fonctionnement de ddclient et compagnie, ayant la chance (si on peut dire, mais en fait c’est un choix) de bénéficier d’adresses IP publiques fixes depuis que j’ai l’ADSL. J’imagine qu’il communique en HTTP(S) avec un serveur distant de DynDNS. Méthodes envisageables, faisabilité à étudier :
- forcer ddclient à utiliser l’adresse d’eth1 comme source de la connexion au serveur de mise à jour (mais pas comme adresse IP à associer au nom de domaine évidemment) ;
- forcer ddclient à utiliser un port source défini, qu’il serait possible de marquer avec iptables pour le router avec la table 99 ;
- si ddclient s’exécute sous un utilisateur spécifique, marquer les paquets émis par cet utilisateur avec iptables pour les router avec la table 99 ;
- si l’adresse IP du serveur DynDNS ne change pas, créer une route spécifique pour elle ; c’est probablement la méthode la plus simple. Si le nom de domaine du serveur résoud en plusieurs adresses IP, créer une route pour chaque adresse.
Les ip route/rule et le VPN sont deux choses indépendantes. Pour exécuter les premières au démarrage, le meilleur endroit est dans le fichier /etc/network/interfaces si c’est lui qui configure eth1 (je suppose en statique) :
iface eth1 inet static
address 192.168.0.x
...
up ip route add default via 192.168.0.254 dev eth1 table 99
up ip route add 192.168.0.0/24 dev eth1 table 99
up ip rule add from 192.168.0.0/24 lookup 99
down ip rule del from 192.168.0.0/24 lookup 99
Inutile d’ajouter des commandes pour supprimer les routes, elles le sont automatiquement lorsque l’interface est arrêtée.
Pour démarrer automatiquement openvpn au démarrage, je suppose qu’il faut regarder du côté de /etc/default/openvpn.
Bonjour,
Tous mes voeux pour cette nouvelle année.
Pour moi le problème est résolu, j’ai moi aussi une IP fixe donnée par mon FAI, mais je dois garder mon compte dyndns pour conserver mon nom de domaine.
ddclient est facilement paramétrable dans ddclient.conf pour attribuer en continu à mon domaine, l’IP du FAI >> 1ère solution que tu m’as proposée :
[quote=“PascalHambourg”]
- forcer ddclient à utiliser l’adresse d’eth1 comme source de la connexion au serveur de mise à jour (mais pas comme adresse IP à associer au nom de domaine évidemment)[/quote][/quote]
La question que je me pose encore est : comment savoir si le trafic de mon serveur apache passe réellement par le vpn ou pas ?
Il me semblait pourtant que la discussion avait été claire sur ce point : le trafic de ton serveur web ne passe pas par le VPN, il ne le peut pas. Ainsi tout le bazar que je t’ai fait mettre en place a pour but de faire en sorte que ce trafic passe par la connexion normale et non par le VPN (puisque ça ne peut pas marcher).
Plus d’explications.
Pour être accessible publiquement depuis internet, un serveur doit avoir une adresse IP publique. Ce n’est pas le cas de ta machine qui a deux adresses IP privées (192.168.x.x sur le réseau local et 10.x.x.x sur le VPN). Dans ce cas un autre possibilité consiste à rediriger les connexions entrantes reçues par une autre machine (routeur ou reverse proxy) qui a une adresse IP publique et capable de communiquer avec le serveur. Dans ton cas, deux machines peuvent éventuellement jouer ce rôle : la “box” (ou le routeur) de ta connexion internet, et le point de sortie du VPN. Or d’après tes dires, il n’est pas possible de rediriger des connexions depuis le point de sortie du VPN. La seule solution restante est donc une redirection sur la box. Donc le trafic entrant à destination du serveur ne peut passer que par la connexion internet et la box.
Concernant le trafic sortant, en théorie rien n’interdit qu’il sorte par une autre voie, comme le VPN. Mais d’une part les mécanismes de redirection (redirection de port NPAT ou reverse proxy) imposent que le trafic sortant repasse par le même chemin afin de pouvoir appliquer la transformation inverse ; et en général les FAI (au sens large, incluant le fournisseur du VPN) n’autorisent le trafic sortant qu’avec l’adresse IP source attribuée au “client”, ce filtrage fait partie des bonnes pratiques recommandées pour éviter l’usurpation d’adresse IP. Donc en pratique le trafic sortant doit repartir par le même chemin, ici la box. Ce n’est pas ce que fait Linux par défaut : il route les paquets sortants selon sa table de routage, sans se soucier de l’interface d’entrée des paquets auxquels il répond. D’où la nécessité du routage avancé pour modifier ce comportement par défaut.
Je suis sûr maintenant que l’accès entrant de mon site ne passe pas par le vpn, par contre il semblerait que le flux sortant y passe bien.
OK je te remercie beaucoup pour toutes ces explications qui m’ont permises de mieux comprendre ces cheminements réseaux.