Je vois le problème, mais ça ne change pas grand chose au chmilblick. Tes paquets ne partent probablement pas vers le VPN.
Ce qu'il faut, c'est que tes paquets partent vers le VPN quand tu cherche à joindre un réseau donné. Donc il te faut une règle NETMAP en PREROUTING sur la passerelle locale qui va réécrire sur un réseau (choisi pour être unique), tu met une route vers ce réseau qui transite par le VPN, et une règle PREROUTING sur la passerelle VPN distante, pour réécrire les adresses arbitraires en adresses locale (par rapport au réseau distant, je sais pas si je me fais bien comprendre...). Bien évidemment, ça ne t'exonère pas des règles de SNAT en POSTROUTING pour gérer le problème de la route retour.
Autre solution, le PBR, Policy Based Routing. Tu gères sur la passerelle locale plusieurs tables de routage (une par réseau distant), et tu utilise des règles iproute (ip rule add ...) pour envoyer les paquets dans les bonnes règles. Le problème étant que si les adresses source sont identiques pour accéder à plusieurs réseaux distants, ça va être coton pour faire des règles iproute qui conviennent...
L'avantage dans ce cas là c'est que tu n'as pas de double NAT (chose que certains protocoles risquent de ne pas apprécier).
Enfin, comme cela a été suggéré, tu peux utiliser un client openvpn sur chaque poste client, pour obtenir les adresses et routes nécessaires pour chaque réseau. Tu ne sera connecté qu'à un réseau à la fois mais ça résoud le problème. Dans la mesure ou les adresses à joindre sont des ip "internes", tu n'échapperas jamais vraiment au conflit autrement, il y aura toujours un cas pour t'embêter. Si il ne s'agit pas de connexions persistante, c'est probablement la meilleure solution, même si elle t'oblige à maintenir plusieurs configurations openvpn, à gérer les certificats et leur révocation, etc.
[^] # Re: Règle PREROUTING avec filtre sur l'interface d'entrée
Posté par nodens . En réponse au message iptables et réseaux non routables. Évalué à 1.
Ce qu'il faut, c'est que tes paquets partent vers le VPN quand tu cherche à joindre un réseau donné. Donc il te faut une règle NETMAP en PREROUTING sur la passerelle locale qui va réécrire sur un réseau (choisi pour être unique), tu met une route vers ce réseau qui transite par le VPN, et une règle PREROUTING sur la passerelle VPN distante, pour réécrire les adresses arbitraires en adresses locale (par rapport au réseau distant, je sais pas si je me fais bien comprendre...). Bien évidemment, ça ne t'exonère pas des règles de SNAT en POSTROUTING pour gérer le problème de la route retour.
Autre solution, le PBR, Policy Based Routing. Tu gères sur la passerelle locale plusieurs tables de routage (une par réseau distant), et tu utilise des règles iproute (ip rule add ...) pour envoyer les paquets dans les bonnes règles. Le problème étant que si les adresses source sont identiques pour accéder à plusieurs réseaux distants, ça va être coton pour faire des règles iproute qui conviennent...
L'avantage dans ce cas là c'est que tu n'as pas de double NAT (chose que certains protocoles risquent de ne pas apprécier).
Enfin, comme cela a été suggéré, tu peux utiliser un client openvpn sur chaque poste client, pour obtenir les adresses et routes nécessaires pour chaque réseau. Tu ne sera connecté qu'à un réseau à la fois mais ça résoud le problème. Dans la mesure ou les adresses à joindre sont des ip "internes", tu n'échapperas jamais vraiment au conflit autrement, il y aura toujours un cas pour t'embêter. Si il ne s'agit pas de connexions persistante, c'est probablement la meilleure solution, même si elle t'oblige à maintenir plusieurs configurations openvpn, à gérer les certificats et leur révocation, etc.