Comment activer l'accès LAN aux clients OpenVPN

0

J'ai un serveur avec 2 vrais NIC et 1 NIC virtuel (tun0) créé par OpenVPN.

eth0 is LAN - IP 192.168.2.1
eth1 is Internet - IP is public internet IP
tun0 is created by openvpn

Ce dont j'ai besoin, c'est que les clients qui se connectent au serveur VPN via eth1 auront également accès au réseau eth0, par exemple. sera en mesure de se connecter à 192.168.2.21

Cela fonctionnait auparavant jusqu'à ce que je redémarre le serveur et que les informations de routage soient réinitialisées: / J'ai configuré cela il y a quelques années et j'ai oublié comment je l'avais fait.

La table de routage ressemble maintenant à ceci:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         public gw       0.0.0.0         UG    0      0        0 eth1
public ip       *               255.255.255.0   U     0      0        0 eth1
192.168.2.0     *               255.255.255.0   U     0      0        0 eth0
192.168.8.0     192.168.8.2     255.255.255.0   UG    0      0        0 tun0
192.168.8.2     *               255.255.255.255 UH    0      0        0 tun0

Quand je lance OpenVPN, il essaie d’ajouter route

Tue Oct 11 19:29:58 2016 /sbin/ip route add 192.168.2.0/24 via 192.168.8.2
RTNETLINK answers: File exists
Tue Oct 11 19:29:58 2016 ERROR: Linux route add command failed: external program exited with error status: 2

Cela ne semble toutefois pas possible, car cela existe déjà. Lorsque je supprime cette route, openVPN réussit à l'ajouter, mais il n'est plus possible pour le serveur d'atteindre le réseau 192.168.2.0/24.

Comment puis-je le faire fonctionner?

EDIT: oui, le transfert IPv4 et IPv6 est activé

networking openvpn

— Petr
source

Votre question n’est pas tout à fait claire sur ce qui se passe où: serveur ou client VPN. Précisez s'il vous plaît. De plus, pour que cela fonctionne, toutes les machines du 192.168.2.0/24réseau doivent savoir que 192.168.8.0/24(le sous-réseau VPN, je suppose) est accessible via 192.168.2.1. Si ce 192.168.2.1n'est pas la passerelle par défaut, vous devez configurer une route sur la passerelle par défaut.

— Daniel B

@DanielB ce que je décris ici est un serveur, qui est aussi une passerelle elle-même, il s’agit de DNS, de DHCP et d’un routeur pour le réseau local. Tout cela fonctionnait jusqu'à ce que je le redémarre, il n'y a donc pas de problème côté client. Le client VPN pousse déjà la route vers le client, le problème est que le serveur VPN ne semble pas autoriser les machines de 192.168.8.0 à accéder au réseau 192.168.2.0

— Petr

Vous comprenez mal: un itinéraire doit exister dans les deux sens pour que les paquets passent par les deux. Vous pouvez facilement vérifier si les paquets sont reçus à l'aide de Wireshark. // De plus, vous obtenez automatiquement un itinéraire vers le sous-réseau de l'adresse IP d'un adaptateur. Toujours.

— Daniel B

0

vous aurez besoin d'ip_forward défini dans le sysctl et d'une ligne d'acceptation dans la table FORWARD dans iptables (qui utilise souvent ACCEPT par défaut)

http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/

— Sirex
source

J'ai déjà ça, ce n'est pas le problème ici.

— Petr

oui, vous aurez également besoin de la ligne de mascarade de ce lien.

— Sirex

MASQUERADEn'est nécessaire que lorsqu'une configuration entièrement routée n'est pas possible. C'est possible, il ne faut donc pas l'utiliser.

— Daniel B

0

Tout d'abord, les itinéraires nécessaires:

Les clients VPN ont besoin d'une route vers 192.168.2.0/24, via votre passerelle VPN (probablement à l' 192.168.8.1intérieur du réseau virtuel)
Les périphériques sur lesquels il est 192.168.2.0/24nécessaire d’acheminer une route 192.168.8.0/24- car il apparaît que votre serveur VPN réside sur la passerelle par défaut, aucune configuration supplémentaire n’est requise.

Ensuite, la configuration. Les spécificités dépendent de la topologie (net30 / p2p ou sous-réseau), mais c'est comme ça en général:

topology net30    
server 192.168.8.0 255.255.255.0

push "route 192.168.2.0 255.255.255.0"

J'ai omis ici toutes les options non pertinentes (mais néanmoins obligatoires). Notez cependant que le routen'est poussé que vers les clients. Il ne doit pas être défini sur le serveur .

Étant donné que le client reçoit tous les paramètres nécessaires via Push, aucune configuration spéciale n'est nécessaire.

— Daniel B
source