OPENVPN Route

Support Debian
#1

Bonjour,
n’etant pas un spécialiste LINUX, j’ai un petit soucis avec mon serveur OPENVPN

La connexion se fait mais impossible d’accéder à mon LAN.

Voici ma config

2 cartes réseaux:

  • Carte LAN 192.168.1.245/24 gtw 192.168.1.1 eth0
  • Carte DMZ 10.8.0.1/24 eth1

Réseau du tunnel
10.10.0.0/24

j’ai suivit plein de tuto qui dise de faire :

  • Mettre un 1 dans le fichier /proc/sys/net/ipv4/ip_forward
  • Modifier le fichier /etc/sysctl.conf en de-commentant la ligne Net.ipv4.ip_forward=1

Toujours rien

Je me connecte sans problème mais toujours rien

La connexion se fait mais impossible de me d’accéder au LAN

Merci de votre aide

#2

Le client du VPN sait-il comment atteindre le réseau local ?
Les machines du réseau local ou la passerelle par défaut savent-elles comment atteindre le réseau du VPN ?
En clair : ont-ils les routes nécessaires ?

#3

Bonjour

Une fois connecté a mon server OPENVPN j’ai (en gras mon LAN coté VPN):

IPv4 Table de routage

Itinéraires actifs:
Destination r‚seau Masque r‚seau Adr. passerelle Adr. interface M‚trique
0.0.0.0 0.0.0.0 192.168.50.254 192.168.50.150 266
0.0.0.0 128.0.0.0 10.10.0.9 10.10.0.10 31
10.10.0.1 255.255.255.255 10.10.0.9 10.10.0.10 31
10.10.0.8 255.255.255.252 On-link 10.10.0.10 286
10.10.0.10 255.255.255.255 On-link 10.10.0.10 286
10.10.0.11 255.255.255.255 On-link 10.10.0.10 286
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
128.0.0.0 128.0.0.0 10.10.0.9 10.10.0.10 31
192.168.1.0 255.255.255.0 10.10.0.9 10.10.0.10 31
192.168.50.0 255.255.255.0 On-link 192.168.50.150 266
192.168.50.150 255.255.255.255 On-link 192.168.50.150 266
192.168.50.255 255.255.255.255 On-link 192.168.50.150 266
193.251.59.211 255.255.255.255 192.168.50.254 192.168.50.150 11
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.50.150 266
224.0.0.0 240.0.0.0 On-link 10.10.0.10 286
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.50.150 266
255.255.255.255 255.255.255.255 On-link 10.10.0.10 286

#4

Bonjour, pour moi, il te reste 2 choses à faire pour réussir à joindre ton LAN :

  1. Ton client risque de ne jamais avoir de route vers le réseau 192.168.1.0/24. En effet, si ton client VPN se trouve dans un réseau qui est déjà en 192.168.1.0, il cherchera toujours d’atteindre ses voisins directs.
    Il te faut donc changer l’adresse réseau de ton LAN. (Le mien est en 192.168.125.0).

  2. Les machines de ton LAN et de ta DMZ ont-elles une route pour atteindre le VPN?
    Plutôt que de leur donner une route, j’ai choisi d’activer le NAT sur tout ce qui vient du VPN. Voici la commande netfilter que j’utilise, tu devras peut-être la modifier un peu :

#Variables du script loopback='lo' IPLan='192.168.125.0/24' IPVPN='10.10.20.0/24' #On remet le nat pour le routage vpn -> LAN iptables -t nat -A POSTROUTING -s $IPVPN -d $IPLan -j MASQUERADE

#5

Cele ne répond qu’à la moitié de mes questions.

Aucun risque :

  • Le client n’est pas dans un réseau en 192.168.1.0.
  • Même s’il l’était, ont voit que les routes poussées par openvpn ont une métrique inférieure à celles des routes locales, donc une priorité plus élevée. Ce serait le réseu local qui ne serait plus accessible, voilà tout.

Mouais, la solution de facilité pas très propre pour les paresseux.
Je répète ce que je dis tout le temps : le NAT ne devrait être utilisé qu’en dernier recours quand on n’a pas d’autre solution.

#6

[quote=“PascalHambourg”]
Mouais, la solution de facilité pas très propre pour les paresseux.
Je répète ce que je dis tout le temps : le NAT ne devrait être utilisé qu’en dernier recours quand on n’a pas d’autre solution.[/quote]

Bon j’arrête de bouder… J’avais mal pris ta remarque au début, mais 1h plus tard, je suis en partie d’accord avec toi, sauf que :
-Dans mon cas, je n’ai pas besoin de logger les utilisateurs du VPN à l’intérieur du réseau : Je suis le seul!
-Simplification du réseau = simplification de la sécurité. Sur le FW de windows Server, je n’autorise qu’un seul réseau à se connecter.
-Les clients de mon LAN sont parfois des gens que je ne connais pas beaucoup. Je n’ai pas envie de leur annoncer de route vers mon VPN, ni de commencer à créer plusieurs pool dhcp suivant la confiance que j’ai de ces utilisateurs. Etant étudiant, je désinstalle, réinstalle très souvent de nouveaux serveurs (ESXi power!), perdre du temps à chaque fois dans la configuration me semble inutile (y a du debian, du windows 2008, 2012). Chaque fois une manip différente pour rajouter des routes statiques.

Donc voilà, un petit HS juste pour dire que le NAT a des inconvénients, mais sa simplicité d’utilisation fait qu’il est plus rentable à utiliser pour moi, que de rajouter des routes statiques.

#7

On n’est pas obligé d’ajouter la route statique sur chaque machine du LAN. Il suffit de l’ajouter sur le routeur utilisé comme passerelle par défaut. Autre option : définir le serveur VPN comme passerelle par défaut.

Le masquerading (NAT source) a l’air simple au début. Mais ce n’est simple qu’en surface, car ça introduit une complexité cachée et ça casse un des principes du protocole internet, la connectivité de bout en bout : les connexions ne passent que dans un sens. De plus certains protocoles ne fonctionnent pas, ou pas sans aide. Exemples typiques parmi les plus courants : FTP, TFTP, SIP, RTSP, IPSec…

#8

Bonjour et merci pour vos commentaires

Bon voici mes besoins:
Des postes utilisateurs doivent avoir accès a une application sur mon LAN (192.168.1.0/24)ou qu’ils se trouvent (3G, WIFI).
Je veux qu’ils passent par un VPN.

Mon serveur VPN:
Un serveur DEBIAN avec 2 interfaces.
Une interface sur le LAN en 192.168.1.0/24 et une interface sur la DMZ en 10.8.0.0/24
Mon Tunnel a comme réseau 10.10.0.0/24
Fichier server.conf
port 1194
proto udp
dev tun

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

server 10.10.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push “route 192.168.1.0 255.255.255.0”

push “redirect-gateway def1”

keepalive 10 120

persist-key
persist-tun

Sur mon serveur voici le resultat de IFCONFIG
eth0 Link encap:Ethernet HWaddr 00:25:86:e6:b5:c1
inet adr:192.168.1.245 Bcast:192.168.1.255 Masque:255.255.255.0
adr inet6: fe80::225:86ff:fee6:b5c1/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9134540 errors:0 dropped:0 overruns:0 frame:0
TX packets:439858 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:661702428 (631.0 MiB) TX bytes:47240786 (45.0 MiB)
Interruption:11 Adresse de base:0xc000

eth1 Link encap:Ethernet HWaddr 00:27:19:b0:05:09
inet adr:10.8.0.1 Bcast:10.8.0.255 Masque:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interruption:10 Adresse de base:0x400

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:69 errors:0 dropped:0 overruns:0 frame:0
TX packets:69 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:6802 (6.6 KiB) TX bytes:6802 (6.6 KiB)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet adr:10.10.0.1 P-t-P:10.10.0.2 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:100
RX bytes:0 (0.0 B) TX bytes:720 (720.0 B)

Sur mon serveur applicatif il peut voir le réseau du TUNNEL en 10.10.0.0/24

Ma connexion de mon poste client se fait bien sur le serveur VPN mais je n’arrive pas à accéder au serveur sur mon LAN

Merci pour votre aide

#9

Cela ne répond toujours pas à ma deuxième question, que je répète donc : les machines du réseau local ou la passerelle par défaut savent-elles comment atteindre le réseau du VPN ?

#10

Bonjour

Les postes se trouvant sur le LAN connaissent la route pour aller sur le réseau TUN en 10.10.0.0/24.

par contre une fois le tunnel créé, entre le poste client et le serveur OPENVPN le poste a bien une adresse IP en 10.10.0.X mais je n’arrive pas à pinguer depuis ce poste l’adresse IP du serveur 10.10.0.1

Voici le résultat de route sur le poste client une fois la liaison créée
IPv4 Table de routage

Itin‚raires actifsÿ:
Destination r‚seau Masque r‚seau Adr. passerelle Adr. interface M‚trique
0.0.0.0 0.0.0.0 192.168.50.254 192.168.50.150 266
10.10.0.1 255.255.255.255 10.10.0.5 10.10.0.6 31
10.10.0.4 255.255.255.252 On-link 10.10.0.6 286
10.10.0.6 255.255.255.255 On-link 10.10.0.6 286
10.10.0.7 255.255.255.255 On-link 10.10.0.6 286
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.1.0 255.255.255.0 10.10.0.5 10.10.0.6 31
192.168.50.0 255.255.255.0 On-link 192.168.50.150 266
192.168.50.150 255.255.255.255 On-link 192.168.50.150 266
192.168.50.255 255.255.255.255 On-link 192.168.50.150 266
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.50.150 266
224.0.0.0 240.0.0.0 On-link 10.10.0.6 286
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.50.150 266
255.255.255.255 255.255.255.255 On-link 10.10.0.6 286

#11

Si le ping vers 10.10.0.1 ne répond pas, je ne vois que deux causes possibles :

  • routes incorrectes sur le serveur openvpn ou le client (a priori non)
  • filtrage intempestif par un pare-feu sur le client ou le serveur. Vérifie déjà les règles iptables sur le serveur avec iptables-save.

Faire une capture de paquets sur chaque interface réseau impliquée pendant un ping pourrait éclairer la situation.

#12

[quote=“PascalHambourg”]Si le ping vers 10.10.0.1 ne répond pas, je ne vois que deux causes possibles :

  • routes incorrectes sur le serveur openvpn ou le client (a priori non)
  • filtrage intempestif par un pare-feu sur le client ou le serveur. Vérifie déjà les règles iptables sur le serveur avec iptables-save.

Faire une capture de paquets sur chaque interface réseau impliquée pendant un ping pourrait éclairer la situation.[/quote]

Et comment fait on cella ? vérification des routes sur le serveur ?
car quand je fais “route” j’ai le résultat ci-dessous
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
10.10.0.2 * 255.255.255.255 UH 0 0 0 tun0
10.10.0.0 10.10.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.0 * 255.255.255.0 U 0 0 0 eth1
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

Et comment capturer les packets sur LINUX ?

c’est mon premier serveur LINUX que je met en place

MErci d’avance

#13

La table de routage du serveur semble correcte, comme je m’y attendais.

Avec un programme de capture comme tcpdump (ligne de commande), wireshark (graphique) ou sa variante tshark en ligne de commande.