Vous avez demandé: " Quelqu'un peut-il expliquer pourquoi ce problème se produit en premier lieu? "
Sur la base de ce qui est rapporté dans la FAQ officielle d'OpenVPN, je parie que cela est dû à un problème de routage dans le moteur OpenVPN.
Pour mieux clarifier le scénario, je me réfère au schéma suivant:
Içi vous pouvez voir:
- un "serveur" OpenVPN connecté au réseau interne HEADQUARTER (10.0.1.0/24)
- un "client" OpenVPN s'exécutant sur un site distant et connecté au réseau distant 192.168.1.0/24
Aussi
- nous supposons que le tunnel OpenVPN est établi et:
- Le "serveur" OpenVPN est accessible via sa propre interface tun , avec l'adresse 10.10.0.1. De plus, l'adresse P2P, utilisée par l'interface tun est 10.10.0.2 ( c'est important pour une discussion ultérieure, nous allons donc le souligner )
- OpenVPN "client" a une interface tun avec IP 10.10.0.2
Supposons maintenant que:
- le "Client" OpenVPN a redéfini sa passerelle par défaut, afin de rediriger dans le tunnel tout le trafic IP sortant;
- le "Client" OpenVPN a activé IP_FORWARDING et, en tant que tel, peut router les paquets provenant de son LAN interne (192.168.1.0/24) ( j'insiste sur ce point, car il est essentiel pour notre discussion ).
Avec un tel scénario en place, vérifions en détail ce qui se passe lorsque R_PC1 (192.168.1.2) envoie un paquet, comme une demande d'écho, à L_PC1 (10.0.1.2):
- après avoir quitté R_PC1 NIC, le paquet atteint le client OpenVPN;
- Client OpenVPN (qui est configuré pour agir comme un routeur commun), acheminez-le en fonction de sa table de routage. Comme sa passerelle par défaut est le tunnel, il envoie le paquet au tunnel;
- Le paquet atteint l'interface tun du serveur OpenVPN. OpenVPN le "verra" et, comme il (serveur OpenVPN) sait que 10.0.1.2 est une adresse appartenant à son sous-réseau LAN, il "transfère" le paquet, du TUN au LAN;
- Le paquet atteint L_PC1.
Alors tout va bien...
Voyons maintenant ce qui se passe avec l'écho-réponse que L_PC1 répond à R_PC1.
- echo-reply quitte la carte réseau L_PC1 et atteint l'interface LAN du serveur OpenVPN (10.0.1.1);
Maintenant, si nous voulons qu'OpenVPN Server puisse atteindre le site distant, nous devons définir le routage avec une "route statique". Quelque chose comme:
route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.0.2
Veuillez noter l'adresse P2P utilisée comme passerelle .
Ces routes statiques fonctionneront au niveau du système d'exploitation. En d'autres termes, il est nécessaire que le système d'exploitation achemine correctement le paquet. Cela signifie quelque chose comme: "S'il vous plaît, tout le trafic adressé au sous-réseau 192.168.1.0/24 doit être transmis au moteur OpenVPN, avec lequel le système d'exploitation est capable de parler via l'adresse P2P". Grâce à cette route statique, maintenant ...
- le paquet quitte le contexte de routage du système d'exploitation et atteint OpenVPN. L'instance OpenVPN s'exécutant sur le serveur OpenVPN. Donc, à ce stade, le système d'exploitation n'a plus rien à faire et tout le routage (au sein du VPN) est laissé au logiciel serveur OpenVPN.
Donc, maintenant, le problème est: comment, le logiciel serveur openvpn, pourra-t-il décider de l'itinéraire d'un paquet, avec SRC_IP 10.0.1.2 et DST_IP 192.168.1.2 ?
Veuillez noter que, basé sur la configuration du serveur OpenVPN, il ne sait rien du réseau 192.168.1.0/24, ni de l'hôte 192.168.1.2. Ce n'est pas un client connecté. Ce n'est pas un client local. Et donc? OpenVPN sait également que ce n'est pas le "OS-Router", donc il ne veut pas vraiment (et peut ....) renvoyer le paquet à la passerelle locale. Donc, la seule option, ici, est de déclencher une erreur. Exactement l'erreur que vous rencontrez
Pour le dire avec le langage de la FAQ: " ... il ne sait pas comment acheminer le paquet vers cette machine, donc il laisse tomber le paquet ... ".
Comment pouvons-nous résoudre le problème?
Comme vous pouvez le voir dans la documentation officielle , l'option iroute sert exactement à notre portée:
--iroute network [netmask]
Generate an internal route to a specific client. The netmask
parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server
to a particular client, regardless of where the client is
connecting from. Remember that you must also add the route to the
system routing table as well (such as by using the --route
directive). The reason why two routes are needed is that the
--route directive routes the packet from the kernel to OpenVPN.
Once in OpenVPN, the --iroute directive routes to the specific
client.
Vous avez donc besoin d'un:
--iroute 192.168.1.0 255.255.255.0
à appliquer (au serveur) lorsque votre client OpenVPN se connecte, par exemple via un fichier de configuration ad-hoc défini sur le serveur (client-config-dir, etc.).
Si vous vous demandez pourquoi ce problème ne se produit pas à l'étape 2) ci-dessus, je comprends qu'OpenVPN Client sait comment l'acheminer, car il sait que le tunnel VPN est une passerelle par défaut.
La même chose ne peut pas être faite sur OpenVPN Server, car là, la passerelle par défaut n'est généralement pas remplacée. En outre, considérez que vous pourriez avoir un seul serveur OpenVPN avec beaucoup de clients OpenVPN: chaque client sait comment atteindre le serveur mais ... comment le serveur peut-il décider quel client fait office de passerelle pour un sous-réseau inconnu?
Quant à votre première question ( les règles requises peuvent-elles être écrites de manière générique / ponctuelle? ), Je suis désolé mais je ne reçois pas votre problème. Pouvez-vous reformuler en fournissant plus de détails?