Partage de fichier depuis OpenVPN vers Green - new topic

[The cop]

Re Bonjour à tous,

Maintenant que j'ai un peu mieux cerné le problème je refait un post avec illustrations et procédure :

Cahier des charges :


WAN ------- client Open VPN @ 10.xx.xx.10
...|
...|
Box en DMZ ---- IpCop [green et VPN : OUVERT] ---- Pc en ecoute sur tcp:8933[bureau à distance]@192.xx.xx.112
.....................................................................................partage de fichier windows (normalement tcp:445)

-> acceder au bureau a distance : ok si port 8933
-> partage de fichier windows depuis vpn vers lan : PROBLEME


Mes recherches :

Pour tous les tests, tout firewall logiciel et antivirus désactivés.

Lors de mes test, je n'ai pas réussi à accéder au bureau à distance depuis le client VPN vers l'adresse 192.xx.xx.112 lorsqu'il écoutait sur le port 3389 (standard du bureau à distance), j'ai du le paramétrer sur dans le registre sur 8933 et ca marche. Pourquoi ?
Le VNC fonctionne aussi lorsque j'utilise un port 6xxx.

Le partage de fichier windows NE fonctionne PAS, et je n'arrive pas à le faire fonctionner. (Il fonctionne parfaitement sur mon LAN)
De même le ping n’aboutis pas non plus.

Ci après quelques screen de ma configuration. Avant de faire des règles interne, j'ai essayé sans aucunes règles, puisque VNC et Remote Desktop fonctionnent sans avoir besoin de règles. Ca n'avait rien donné. Le fait de faire des règles permet d'avoir des traces dans le log qui plus est.

Mes règles de test :




Mes log en test de ping et tentative d'accès \\192.xx.xx.112 :




Mes log lorsque je génère un tracert du client vpn vers la destination .112 du lan :





Merci d'avance !!

[Franck78]

On sent que tu as envie de bien faire mais franchement, c'est si mal présenté qu'on a pas envie de chercher !

D'abord à quoi bon perdre du temps à cacher des IP privées et des mac address........ Parfaitement inutile

Ensuite l'objectif :

- accéder au bureau a distance : ok si port 8933 SINON ?
- partage windows, à quoi bon si la base ne fonctionne pas, PING par exemple ?

Les logs en images, c'est très chiants !!!!!

Efface tout et recommence la config d'un client OPenvpn en suivant un vrai tuto. Spécialement attentions aux routes 'pushées' qui est la base de la base de la base....

[The cop]

Salut Franck,

merci pour tes conseils, cependant je vais quand même réagir sur deux points. La masquage des adresses IPs ainsi que MAC me sont imposé par une charte interne.
Je pensais pour ma part que les logs en images seraient plus visuels que du texte brut. Mais ca peux s'arranger si y'a que ca.

Hormis les images, d'autres conseil à me donner sur la présentation pour que qqun ai envie de regarder ? Parce que ça me paraissait plutôt structuré, donc je ne vois pas comment faire différemment.


Pour ce qui est du client OpenVPN, je pense en avoir monté suffisamment en Ubuntu server, pour pouvoir m'en sortir sur une GUI, d'autant que j'ai justement précisément regardé des tutos pour m'assurer que ce que je voulais faire est compatible.

Spécialement attentions aux routes 'pushées' qui est la base de la base de la base....

Pourtant cela fonctionne comme l'indique la partie écrite (toi qu'aime pas les images :p )
Puisque le bureau à distance, A CONDITION de ne pas utiliser le port de base, ainsi que le VNC fonctionnent. Par ailleurs, sur mon windows client, un netstat -nr montre que la route pushé est correcte, conformément à la petite case cochée dans les paramètres avancés lors de la création d'un client .

Il semblerai donc qu'il y ai un souci lorsque les services utilisés (bureau a distance sur le 3389, ping, netbios etc) sont utilisés sur les ports "usine". Et la je pense que pas besoin de recréer un 50eme client test.


Des idées ?

[Franck78]

si tu penses que le routage est correct entre les extrémités du VPN, c'est à dire que client A contacte client B (vpn monté), tu as peu de problème possible

- ports bloqués/changés
- protocole bloqué (udp/tcp/...)

et tu disposes d'un outil magnifique qui se nomme 'tcpdump' pour trouver le coupable !


F.