VPN IPSEC et OPENVPN
-
Je trouve que c'est complètement fou ça…
Quelque soit le fil de discussion, on retrouve systématique la même problèmatique : réfléchir en terme de solution AVANT de réfléchir en terme de besoin.
Lorsque l'on réfléchit en terme de solution :
- on donne peu d'informations
- on cherche une solution pourvu qu'elle marche
- on comprend rarement ce que l'on fait
- la plupart du temps on n'apprend rien (ou mal)
Lorsque l'on réfléchit en terme de besoin
- on se construit un cahier des charges (terme qui devrait être souvent utilisé alors qu'il n'est jamais présent)
- grâce au cahier des charges on fournit des informations
- grâce aux informations on aboutit à une solution adaptée aux besoins (sans compter qu'on obtient de l'aide beaucoup plus facilement)
- on comprend mieux ce que l'on fait
- quand on comprend on apprend, donc on progresse
Savoir bidouiller est une chose, savoir pourquoi en est une toute autre.
-
+1 Talwyn
-
@Talwyn.
En effet. -
Ce n'est pas parce que tu as ajouté cette route que ça doit fonctionner maintenant. C'est une étape indispensable mais:
1 - une fois cette configuration effectuée, tu devrais vérifier que c'est bien opérationnel coté "client OpenVPN" (e.g. "route print")
La route créé vers 17.0.0.0 n’apparaît pas sur mon PC Windows …
2 - comme je te l'ai déjà écrit, il faut que le client OpenVPN connaisse la route vers le réseau cible mais il faut également s'assurer que coté firewall (de par et d'autre du tunnel IPSec) les flux sont autorisés, y compris pour l'adresse IP allouée à ton client OpenVPN.
Côté routeur client je ne peux pas demander à mon client de modifier les autorisations, aujourd'hui c'est ouvert uniquement pour le réseau 10.0.0.0/8.
Dans OpenVPN je ne peux pas mettre ce réseau car je l'utilise déjà .. -
Au moins on avance un peu :)
C'est curieux que tu ne vois pas le résultat de la commande "push" du serveur OpenVPN sur ton client.
Une fois ton tunnel OpenVPN établi, regarde donc coté client quelle est ta route vers 18.0.0.1 et 17.0.0.1Pour le firewall à l'autre extrémité, si seul 10.0.0.0/8 est autorisé, il te faut "rebondir" sur un serveur en interne sans quoi tu vas être vu avec l'IP du tunnel.
Donc pas de solution simple à grands coups de NAT.C'est assez simple: seul ton LAN en /8 est autorisé, donc tu ne peux pas avoir cette adresse en tant que client OpenVPN donc tu ne peux pas accéder directement chez ton client. 8)
Au delà de cette aspect, je trouve quand même surprenant cet usage immodéré de classe A.
La solution simple (sur le papier), c'est que tu changes ton plan d'adressage sur ton LAN pour quelque chose de plus raisonnable.Et ton client à l'air de faire la même chose. Je n'avais pas fait attention sur ton schéma au plan d'adressage mais c'est également en classe A :o :o :o
Il y a tant d'équipement que ça ??? -
Je "me réponds" pour ne pas froisser les susceptibilités si j'édite ;D
tu pourrait peut-être passer en 10.4.0.0/16 sur ton LAN et faire un tunnel OpenVPN en, par exemple 10.0.10.0/24 (ou autre chose dans le même ordre d'idée)
Sur ce que je lis (rapidement) de tes schémas, ça devrait le faire sauf si tu as d'autres contraintes qui n'apparaissent pas ici.
-
Avancement :
J'ai modifié l'adressage IP attribué au client OpenVPN : 10.5.0.0/24 .
La route est bien prise en compte (route print), en passerelle il m'affiche 10.5.0.13
ps: mon LAN dans pfSense est 10.4.0.254/24 et non 8 …!
Je n'arrive toujours pas accéder à un automate.
-
oui mais là tu pousses une route qui est 17.0.0.0/24 alors que ton schéma montre 17.0.0.0/8
Quelle est l'adresse de ton équipement ?
-
Je viens de corriger, revoir le message précédent …
-
A ce stade, tu devrais pouvoir faire un "tracert 17.x.x.x" (adresse de ton équipement) pour voir par où tu passes.
Si le site distant n'autorise que HTTP et SSH, il est probable que ICMP sera bloqué mais au moins tu verras si tu vas dans la bonne direction.Quel est ton message d'erreur lorsque tu essaies de te connecter ?
-
Il passe par la passerelle de ma VM (@IP publique).
-
Donc ton lien IPSec n'encrypte pas le flux en provenance du subnet "OpenVPN" ? ;)
-
Il faudrait que tu partages un peu quelques infos sur ta conf IPSec, et ce sans tout barbouiller de bleu de peur qu'on lise une adresse IP privée :P
Et je soupçonne quand même un truc pas très clean en termes de réseau car tu vises des adresses (17.0.0.0/8 et 18.0.0.0/8) qui ne sont pas dans la RFC1819 (la 18.0.0.0/8 appartient au MIT et la 11.0.0.0 au DoD ::))Bref, ça m'a l'air assez bizarrement "organisé" ce truc ;D
-
C'est vrai que j'ai pas besoin de les cacher …
En réalité ce n'est pas 17 et 18 ;)Que me proposes tu maintenant ?
Routage ?:-X
-
Que me proposes tu maintenant ?
Routage ?Non, je te propose dans changer la conf de ton lien IPSec parce que le tunnel qui couvre "LAN" (source) ne comprend très probablement pas les IP qui sont issues tu tunnel OpenVPN ;)
-
Encore merci pour tes réponses chris4916.
J'ai modifié la configuration de mon tunnel IPSEC.
Dans la phase 2, j'ai mit 10.0.0.0/24 (pour qu'il prenne en compte l'IP de mon client OpenVPN), ca ne change rien.
Il ne prend toujours pas la bonne route.
-
Je suis un peu largué avec toutes ces plans d'adressage bizarres mais si tu mets 10.0.0.0/24, il y a zéro chances pour que 10.0.4.0 soit prix en compte.
il te faut comprendre ce que /24 ou /8 signifie et ce que ça couvre, sans quoi ça peut tomber en marche… ou pas.
Tu peux faire 10.0.0.0/8 ;) mais il faudrait surtout et en priorité mettre à plat cet aspect "adressage" avant de vouloir connecter les sites et rebondir sur ton LAN pour accéder au site distant.
-
Hé ben… 3 pages pour en arriver là, ça valait le coup d'étaler sa science...
Ha ! Méthodologie quand tu nous tiens...
N'en déplaise au(x) modérateur(s) du forum, mais ça me fout vraiment et sérieusement les boules qu'il y ait des gens comme toi en activité alors qu'il y a des gens comme moi en chômage longue durée.
C'est purement et simplement déprimant...
-
chris4916 : j'ai mis /8 et là il n'emprunte plus l'adresse IP WAN de mon pfSense (tracert).
Talwyn : je t'ai rien demandé … -