pb connection vpn

par **testeur290306** » 10 Mai 2006 10:30

bonjour,

suite à mes differents post concernant un vpn multi-sites je souhaiterais trouver quelque infos,
en recherchant j'ai trouver le fonctionement mais pas de détails.

je voulais tout d'abord savoir si un idée est vraie :

quand on monte un vpn, l'ip publique est "réservé" par le vpn, et seul les postes du vpn peuvent la pinguer et avoir accès aux ressources des lans du vpn?
depuis l'extérieur(n'importe quel poste) il est impossible de se connecter sur un serveur se trouvant dans un vpn?

j'ai mis en place un vpn 3 sites(deux sites se connectent sur un troisième derrière lequel se trouve un tse.

l'accès au tse fonctionnent, mais quand j'ai voulu restreindre l'accès au tse uniquement aux lans distant, plus d'accès.

certains d'entre vous m'ont conseiller de faire des tests pour vérifier.

pinguer les postes des autres lans et inversement.

depuis le site du lan avec le tse je pingue les postes des sites distants, tracert fonctionne.
les paquets passent directement de green à green.
mais depuis un site distant je ne peux pas pinguer plus loin que l'interface interne de l'ipcop.
j'ai tester avec tcpdump et ethereal, dans un sens j'ai les echo request et reply, pas dans l'autre.

si quelqu'un peut m'aider

par **pkaer** » 10 Mai 2006 11:36

Salut,

J'ai des configs similaires à la tienne et voici ce que je constate :

quand on monte un vpn, l'ip publique est "réservé" par le vpn, et seul les postes du vpn peuvent la pinguer

Non je ne vois pas pourquoi le tunnel VPN monopoliserait l'@IP Publique

et avoir accès aux ressources des lans du vpn?

Vrai si tu n'as fais aucune redirection par l'onglet "transfert de port"

depuis l'extérieur(n'importe quel poste) il est impossible de se connecter sur un serveur se trouvant dans un vpn?

Même réponse que précedement. Si le poste, qui se connecte de l'extérieur, n'appartient pas au LAN d'une des extrémités du VPN et que tu n'as fait aucune redirection par l'onglet "Transfert de port", il n'y a (à priori) aucune possibilité pour se connecter sur un serveur se trouvant dans le LAN de l'autre extrémité du VPN.

l'accès au tse fonctionnent, mais quand j'ai voulu restreindre l'accès au tse uniquement aux lans distant, plus d'accès.

Par quel biais as-tu restreint l'accès ??

mais depuis un site distant je ne peux pas pinguer plus loin que l'interface interne de l'ipcop.

Curieux, cela ressemble a un problème de passerelle mal renseignée. En clair si ton serveur TSE a pour passerelle l'IPCop de son LAN, tu devrais avoir un "retour" sur les ping que tu emets à partir des postes des sites distants

J'espère que cela pourra t'aider :wink:

@+
PK

par **testeur290306** » 10 Mai 2006 11:52

merci de ta réponse,

j'avais entendu pour le vpn que quand il était monté, personne de l'extérieur pouvait avoir accès au lan.

dans le transfert de ports ipcop j'ai mis une règle pour accepter le traffic sur le port 3389 vers le serveur tse.

par défaut vers l'ip de mon serveur tse dans le lan.

la règle est du type

default ip (source) et l'ip du serveur(destination) port souce et destination 3389

avec cette règle sur chaque ipcop

si j'ai pas cette règle de redirection, aucun acè possible.

mais avec cette règle j'autorise n'importe quelle ip à se connecter depuis n'importe ou.

même depuis chez moi ça fonctionne!!!

je voulais mettre un règle dans le transfert de ports ipcop pour restreindre l'accès au tse au lan distants de mon vpn. en mettant comme source l'ip publique de mes ipcops ou le réseau (192.168.0.0)
il ya une methode
transfert de ports puis un accès externes dessus, après on voit accès autoriser depuis l'ip

mais quand je fais ça, plus d'accès possible.

donc certains m'ont dis de faire des tests, pings des postes des sites distants et inversement.
ça fonctionne dans le sens lan tse vers sites distants mais pas dans l'autre

en utilisant tcpdump je vois que le chiffrement des données se fait entre les interfaces pppoe

mais en faisant ipsec verify j'ai ça :

Checking your system to see if IPsec got installed and started correctly
Version check and ipsec on-path [OK]
Checking for KLIPS support in kernel [OK]
Checking for RSA private key (/etc/ipsec.secrets) ipsec showhostkey: no default key in "/etc/ipsec.secrets"
[FAILED]
Checking that pluto is running [OK]
DNS checks.
Looking for forward key for ipcopniepce.gretadomain [NO KEY]
Does the machine have at least one non-private address [OK]
Two or more interfaces found, checking IP forwarding [OK]
Checking NAT and MASQUERADING
tun0x1008@X.x.x.x:0 [FAILED]
REDNAT from 0.0.0.0/0 to 0.0.0.0/0 kills tunnel X.X.X.X: 0 -> X.X.X.X :0
tun0x1007@X.X.X.X:0 [FAILED]

tu a une idée?

merci d'avance
REDNAT from 0.0.0.0/0 to 0.0.0.0/0 kills tunnel X.X.X.X /24:0 -> X.X.X.X /24:0

par **jdh** » 10 Mai 2006 12:00

Je ne peux que constater que pkaer est tout à fait en ligne avec ce que j'ai déjà écrit sur le précedent fil.

Un VPN "réseau à réseau" c'est un un moyen de transporter du trafic entre 2 réseaux au travers d'Internet de façon sécurisée.

Quand le VPN est correctement monté, un PC d'un réseau accède en totalité à un serveur de l'autre côté. Pour autant que les règles de routage permettent bien ce trafic !

Premierement résouds ton pb de routage. Deuxièmement mets en oeuvre ton VPN pour le premier site jusqu'à ce qu'un ping entre 2 PC de 2 réseaux fonctionne. Troisièmement ajoutes le VPN pour le 3me site.

par **pkaer** » 10 Mai 2006 12:22

Salut jdh,
Dsl j'avais pas vu le post antérieur et tes réponses. J'ai donc perdu un peu de temps à redire ce que tu avais déjà expliqué

@testeur290306,
Essayes ne ne faire qu'un seul "topic" pour le même problème. Sinon, tu risques d'avoir plusieurs fois les mêmes réponses :wink:

Si tes passerelles sont correctes, c'est que tu as un problème de VPN. Cherches de ce coté.
En tout les cas je confirme que dans le cas d'un tunnel VPN, tu n'as pas besoin de "transfert de port" pour accéder aux ressources. Sinon à quoi servirait le VPN si tu devais établir des regles pour chaque service que tu souhaites accéder :?:

@+
PK

par **testeur290306** » 10 Mai 2006 13:19

MERCI pour vos réponses

je pense au problème du vpn

car sans le transfert de ports, j'ai pas d'accès.

et avec le vpn monté et fonctionnant personne ne doit pouvoir se connecter depuis l'extérieur sur l'ipcop ou sur un serveur qui est derrière l'ipcop?

je vais analyser les trames icmp encore

j'ai les même table de routage sur chaque ipcop sauf pour les lans c'est l'inverse mais sinon c'est les mêmes routes pour accéder au lan distant. et depuis le lan distant la même route pour accéder au lan du tse.

donc je vois pas ou ça bloque.
sur le tse j'ai bien la route du lan distant avec comme passerelle l'ipcop.

je fais des tests et vous tiens au courant.

merci

sinon vous avez une idée pour ça, si c'est normal :

Checking your system to see if IPsec got installed and started correctly
Version check and ipsec on-path [OK]
Checking for KLIPS support in kernel [OK]
Checking for RSA private key (/etc/ipsec.secrets) ipsec showhostkey: no default key in "/etc/ipsec.secrets"
[FAILED]
Checking that pluto is running [OK]
DNS checks.
Looking for forward key for ipcopniepce.gretadomain [NO KEY]
Does the machine have at least one non-private address [OK]
Two or more interfaces found, checking IP forwarding [OK]
Checking NAT and MASQUERADING
tun0x1008@X.x.x.x:0 [FAILED]
REDNAT from 0.0.0.0/0 to 0.0.0.0/0 kills tunnel X.X.X.X: 0 -> X.X.X.X :0
tun0x1007@X.X.X.X:0 [FAILED]

par **testeur290306** » 10 Mai 2006 16:09

ça fonctionne

j'ai réussi à pinguer une machine du lan tse depuis un site distant.
en mettant dans la table de routage du pc la route pour le réseau distant et la passerelle(ipcop)

mais c'est pas logique

le pc à comme passerelle l'ipcop qui à la route dans sa table de routage.
donc pourquoi ça a marché en mettant (deux fois) la route pour le réseau distant?

par **pkaer** » 10 Mai 2006 16:52

@testeur290306,

Si tu n'as qu'une seule "sortie" Internet sur ton LAN "TSE" et sur les réseau de tes sites distants, tu n'as pas à établir manuellement des routes. La passerelle par défaut suffit

sur ton LAN TSE, les PC et les serveurs qui doivent avoir accès au VPN et/ou Internet doivent simplement avoir comme passerelle par default l'@IP LAN de l'IPCOP local (celui qui se trouve sur le site de tes serveurs)

Sur tes sites distants, les PC qui doivent avoir accès au VPN et/ou Internet doivent simplement avoir comme passerelle par default l'@IP LAN de l'IPCOP local. (celui qui se trouve sur le site distant).

Si tu te limites au VPN, sans redirection par le "transfert de port", seuls les PC de tes sites distants pourront avoir accès aux services hébergés sur ton lan "TSE".

Enfin, si tu veux avancer sur ton problème, donnes à la communauté IXUS un minimum d'infos sur tes réseaux. Si il n'est pas nécessaire (et pas recommandé) de poster tes @IP publiques, tu peux au moins décrire tes réseaux coté LAN avec leur masque de sous-réseaux. Il y a peut-être un bleme de ce coté la

@+

PK

par **jdh** » 10 Mai 2006 18:14

Justement dans le fil précédent, j'ai compris qu'il y a plusieurs sorties vers Internet.

Or il est clair qu'il n'y a qu'une passerelle par défaut par PC. Mais si les sorties vers Internet possède les bonnes routes, ça fonctionne parfaitement.

En fait il suffit de faire un dessin avec les réseaux en jeux et les éléments de liaison. Après les routes à ajouter sur chaque élément sont évidentes, et ça roule ...

par **testeur290306** » 11 Mai 2006 11:27

j'ai refais des tests depuis hier.

sur le poste de test distant j'ai mis la route du réseau du tse dans la table de routage.ça fonctionne.
je l'ai effacer ça fonctionne.

j'ai enlever le transfert de ports qui est inutile du fait du vpn sur l'ipcop côté tse.

ça fonctionne plus.

réseau

serveur tse 10.71.6.111

pctest1 10.71.6.209-->10.71.6.35(ipcop1)ip publique-->vpn-->ip publique(ipcop2)192.168.71.2-->pctest2(192.168.71.115)

mon serveur tse se trouve comme le pctest1 derrière l'ipcop1

pctest1 à comme passerelle 10.71.6.35
tse à comme passerelle 10.71.6.35

pctest2 à comme passerelle 192.168.71.2

je possède un troisième site avec un ipcop qui est identique à l'ipcop2 avec un réseau en 192.168.0.0
mais je fais déjà des tests sur un site distant.

tous mes réseau ont un masque de 255.255.255.0
depuis 10.71.6.209 je pingue ippublique ipcop2, 192.168.71.2, 192.168.71.115 ça fonctionne

depuis 192.168.71.115 je pingue 192.168.71.2,ippublique ipcop2, ippublique ipcop1,10.71.6.35,10.71.6.209 ça fonctionne.depuis hier
juste le fait de rajouter dans la table de routage de pctest2 la ligne avec comme destination 10.71.6.0 mask 25.255.255.0 passerelle 192.168.71.2 ça fonctionne

après j'ai supprimé cette ligne, ça fonctionne toujours(un cache quelconque?)
alors que ipcop2 à dans sa table de routage la route pour le lan 10.71.6.0

dans l'état du réseau sur ipcop1 j'ai des paquets drop sur l'interface ipsec
normal?

j'espère trouver une solution
vous pouvez m'aider?

pb connection vpn

pb connection vpn

Qui est en ligne ?