Bonjour
Je vais ré expliquer le problème.
Je voudrais que tout le trafic passe par le vpn (tun0)
Sauf les requêtes vers le serveur web et ftp qui sont respectivement le port 443 80 20590 14600:14650
En gros, je voudrais que si la requête les entre par ens18 (interface physique) sa ressorte par ens18
Car sinon bah la requête finie en timeout puisque ressort par la mauvaise interface sauf que je n’ai pas réussi, ça fait plusieurs jours que je recherche…
Il est beaucoup plus simple de faire sortir le trafic normalement sur l’interface ens et de mettre une route vers l’ip de ton serveur distant faisant passer le trafic au travers du vpn.
Dans la configuration de Openvpn, il y a moyen d’ajouter les routes adéquat.
Je suis pas sûr qu’il sera simple de gérer par type de trafic plutôt que par destination dans ton cas.
C’est ce qui me semblais j’ai même demander de l’aide à notre nouvelle amis chat gpt eu Même ce qui m’a sorti n’a rien donné de fonctionnel
Donc bon je pense que je vais voir pour faire passer tout le traffique en vpn et pour le serveur web je mettrai l’IP du vpn logiquement sa devrais être plus simples mais sa veux dire que je dois crée une règle qui rédige tout ce qui entre dans le serveur vpn dois aller vers l’interface du vpn maintenant donc la ces l’opération inverse
En gros pour schématisé
Requête externe entrente → serveur vpn → serveur web derrière vpn
Retour de la requête Serveur web → serveur vpn → renvoie la réponse à la requête externe
On n’a pas eu de réponses aux questions de @PascalHambourg
Je suis du même avis que lui poussé une route vers l’ip de ton serveur distant pour seulement le nécessaire est bien plus simple à mettre en place (si la sauvegarde cherche à atteindre une ip fixe, il suffit de pousser une route avec un métrique adéquat pour emprunter le VPN) le restant continuant à fonctionner comme d’habitude.
En gros tu veux remplacer une solution bancale par une « solution » encore plus bancale ?
En quoi la solution simple et efficace proposée par @Clochette et moi ne convient-elle pas ?
Hmmmm
Bha je pense ne pas avoir compris
Tout compris malheureusement
Pour résumer vous me conseiller au lieu de faire ce que je veux faire
Ces plutôt d’indiqué quel route dois prendre la route du vpn c’est ça
On essaie de proposer la meilleure solution qui convient au besoin. Mais c’est difficile d’évaluer ton besoin réel car tu changes d’idée et ne réponds pas aux questions.
Quand on configure un VPN, on définit les destinations qui sont joignables via ce VPN. Cela peut être une adresse unique (pour accéder à une machine distante), un préfixe (pour accéder à un réseau distant), toutes les adresses (pour accéder à internet via le VPN). Cela va créer la ou les routes correspondantes dans la table de routage lorsque le VPN sera monté.
Tu sembles avoir configuré le VPN pour le troisième cas, qui ajoute une route par défaut via le VPN pour toutes les destinations non locales. Initialement, tu as écrit que le serveur distant ne servait qu’à faire des sauvegardes. Il nous semblait donc plus logique de définir l’adresse de l’interface tun de ce serveur comme seule destination joignable via le VPN, d’autant plus si le serveur distant a moins de bande passante (si j’ai bien compris).
Mais tu as ensuite souhaité que tout le trafic sortant sauf les réponses aux connexions entrantes soit routé via le VPN (pourquoi ?) puis que tout le trafic sortant soit routé via le VPN et que les connexions entrantes soient reçues par le serveur distant et redirigées vers le serveur local (pourquoi ?).
Ce que je voudrais j’espère que sa aidera mieux
C’est quand on contacte 443 ou 80 sur ens18 (Interface physique que ça fonctionne
Je m’explique.
La actuellement le problème, c’est que dès que j’active le vpn et que j’essaye de contacter le serveur web sur le réseau local ça fonctionne, mais dès que c’est depuis l’extérieur ça ne.
Fonctionne pas donc j’ai l’impression que dès qu’une requête extérieure vient ca sort par tun0 alors que si je désactive le VPN j’arrive à ravoir le serveur web depuis l’extérieur
Comme si la requête passée par ens18
sauf que la réponse à la requête semble partir vers tun0 donc forcément ça ne fonctionne pas
Ce n’est pas comme SI, c’est le cas … tu as une route par défaut indiquant au trafic de passer au travers du VPN qui supplante la route par défaut utilisant ton interface ethernet.
Ce que l’on t’explique c’est qu’il faudrait sans doute mieux reconfigurer ton VPN pour n’être utiliser QUE pour accéder au ressources disponible au bout du tunnel 
En fait ça pourrait fonctionner, selon de ce qu’il y a à l’autre bout du tunnel. Le routage sur internet n’est pas forcément symétrique. Mais ce ne serait pas optimal.
Si tu ne sais pas comment configurer openvpn, tu peux commencer par poster les configurations d’openvpn et la sortie des commandes
ip addr
ip -4 route
ip -6 route
côté client et côté serveur lorsque le VPN est monté. (tu peux maquiller les adresses IP publiques mais que ça reste lisible)
Bon a ce que je comprends tu as dans l’idée de faire passer du trafic dans le vpn mais ce ne sera pas de la sauvegarde 
ok … soit, du coup le routage est plus complexe car tu va reçevoir des communications depuis le VPN (que tu ne gère pas) et tu souhaite que ce tyrafic reparte vers cette interface si j’ai bien compris (sans rentrer dans le détail ^^ ).
Pour commencer peux-tu à minima nous fournir les informations demandé par @PascalHambourg , sans ça on n’ira pas bien loin …
hello
Désolé, pour le temps de réponse, j’avais temporairement mis en pause tout ça, je commençais à saturer un peu.
Pour info, j’ai disable l’ipv6
Voici les informations demandées
pour info l’adresse ip local coté vpn est changeante et parfois j’ai tun0 ou tun1 qui apparais
retour de la commande : ip addr
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 86:7d:ba:3d:c2:0f brd ff:ff:ff:ff:ff:ff
altname enp0s18
inet 192.168.42.21/24 brd 192.168.42.255 scope global ens18
valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 10.8.3.12/24 scope global tun0
valid_lft forever preferred_lft forever
retour de la commande : ip -4 route
0.0.0.0/1 via 10.8.3.1 dev tun0
default via 192.168.42.1 dev ens18 onlink
10.8.3.0/24 dev tun0 proto kernel scope link src 10.8.3.12
128.0.0.0/1 via 10.8.3.1 dev tun0
192.168.42.0/24 dev ens18 proto kernel scope link src 192.168.42.21
213.232.87.63 via 192.168.42.1 dev ens18
la commande
ip -6 route ne remonte rien vue que j’ai disable ipv6
C’est la configuration classique d’openvpn lorsqu’il se positionne comme route par défaut. D’abord il crée une route spécifique pour l’adresse du serveur distant (213.232.87.63) calquée sur la route par défaut actuelle sinon les paquets transportant le VPN seraient routés dans le VPN. Ensuite, au lieu de remplacer la route par défaut existante, il crée deux nouvelles routes pour router une moitié de l’espace d’adressage total chacune (0.0.0.0/1 et 128.0.0.0/1) via le VPN. Ces destinations étant plus spécifiques que la route par défaut, elles sont systématiquement préférées et la route par défaut n’est plus utilisée tant que ces deux routes existent quelles que soient les éventuelles métriques (priorités) associées aux routes qui ne s’appliquent qu’en cas de conflit entre des routes couvrant la même taille de destination.
Pour ta problématique, il faut définir précisément quel trafic sortant doit être routé via le VPN ou via le routeur du LAN. Classiquement, il y a deux approches possibles :
Dans les deux cas il faut tout prendre en compte, y compris le trafic « utilitaire » comme DNS.
Le choix se fait généralement selon laquelle des deux catégories de trafic est la plus simple à caractériser.
Exemples de stratégies possibles :
Chacune de ces stratégies a des avantages et des inconvénients :
Si la stratégie choisie a besoin de règles iptables pour marquer les paquets, il faut faire attention à l’intégration avec ufw ou autre pare-feu.
A toi maintenant de définir les types de trafic.
Bonjour désolé pour le délai de réponse
Hmm la solution 3 semble la mieux
plus simple : on route via le routeur du LAN tous les paquets ayant l’adresse source de l’interface LAN (qui sont par défaut des paquets de réponses à une connexion entrante à destination de cette adresse) et le reste via le VPN ça me parais entre le plus simple.
Pour information le ftpes vsftpd a était paramétrer pour fonctionner de façon passiv (passiv port) actif avec la plage 12600-12650 en tcp
Globalement, le seul trafique qui dois passer sûr via le lan, ce sont les services web + FTP globalement, je pense que la solution 3 est la bonne
Après la solution 1 est aussi valable mais en sois le système fonctionne que sur du tcp donc la solution 3 et plus simple je pense
Solution 3 :
ip rule add to 192.168.42.0/24 priority 100 table main
ip rule add from 192.168.42.0/24 priority 200 table 200
ip route add default via 192.168.42.1 dev ens18 table 200
La troisième commande initialise une table de routage pour tout envoyer à la box.
La seconde commande crée une règle qui applique cette table de routage à tous les paquets émis avec une adresse source du LAN (au cas où l’adresse d’ens18 serait variable)
La première commande crée une règle prioritaire sur la précédente qui applique la table de routage normale (main) aux paquets émis avec une adresse de destination du LAN pour qu’ils ne soit pas envoyés à la box.
A tester manuellement puis à exécuter à chaque démarrage. Si l’interface ens18 est configurée dans /etc/network/interfaces, une méthode possible est d’utiliser l’option up.
Hello merci pour l’information sa fonctionne nickel
Donc dans le fichier /etc/network/interfaces j’ai add ses lignes la
a la suite pour ens18
up ip rule add to 192.168.42.0/24 priority 100 table main
up ip rule add from 192.168.42.0/24 priority 200 table 200
up ip route add default via 192.168.42.1 dev ens18 table 200
Pour info, l’interface est gravée en dur et en IP fixe donc ens18 ne devrais pas bouger la seule interface qui bouge parfois, c’est le vpn parfois, c’est tun0 et parfois, c’est tun1
Merci à vous pour l’aide en tout cas 
Petit avertissement : si l’interface ens18 est arrêtée et redémarrée avec ifdown+ifup ou le service networking, les commandes "ip rule sortiront en erreur car les règles existent déjà et les commandes suivantes ne seront pas exécutées. A contrario la route est supprimée automatiquement lorsque l’interface est désactivée, et ne sera pas recréée si la commande ip route n’est pas exécutée parce que les commandes précédentes sortent en erreur. Pour l’éviter, on peut soit
ip route en premier mais ça reste sale car les deux autres seront en erreur même si ça n’a pas d’impact || true » à la fin des deux commandes pour qu’elles sortent en succès, comme indiqué dans man interfacesdown pour supprimer les règles lors de l’arrêt de l’interface afin qu’elles puissent être recréées sans erreurhello donc si je comprend bien sa donnerais sa du coup ?
up ip rule add to 192.168.42.0/24 priority 100 table main || true
up ip rule add from 192.168.42.0/24 priority 200 table 200 || true
up ip route add default via 192.168.42.1 dev ens18 table 200 || true
actuellement mon fichier ressemble a cela
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug ens18
iface ens18 inet static
address 192.168.42.21/24
gateway 192.168.42.1
# static route
up ip rule add to 192.168.42.0/24 priority 100 table main
up ip rule add from 192.168.42.0/24 priority 200 table 200
up ip route add default via 192.168.42.1 dev ens18 table 200Oui, c’est ça.
OK modification effectué
merci pour votre aide
tout est fonctionnel
Je passe incident en résolue