Euh, j’ai juste fait ‘reset firewall’ dans webmin apres avoir sauvé etc/iptables.up.rules, du coup il est sur ‘accepter tout le traffic’. Désolé si la méthode est pas très conventionnelle mais j’improvise. 
Ca ne change rien, des clients je ne peux pinger que le serveur en (192.168.1.1 ou par son nom netbios). Si je ping un client par son nom netbios il me donne bien l’ip locale attribué par openVPN mais ne répond pas. Je devrait peut être désactiver Samba pour faire des tests sur openVPN, non ?
Mais tes clients ce ne seraient pas des windows avec le parefeu qui ne bloque que ce qui est utile ?
Bon j’ai du nouveau, les tests précédents ont étés effectués de mon PC sous XP, ou je ne pouvais pinger que le serveur. J’ai refait les tests de mon PC sous Vista et je peux pinger tous les clients sauf celui sous XP. J’imagine que c’est un problème de config sur mon XP, j’effectue donc les tests à partir de maintenant sous le client Vista: je peux donc pinger d’autres clients Vista qui sont connectés à mon VPN, de plus tout le monde apparait dans mon voisinage réseau windows (même XP) mais toujours personne dans le LAN local d’un programme.
Edit: je n’ai pas de pare feu sur la connexion VPN des différents windows, le pare-feu windows est juste sur la connexion internet, pas plus.
mmmmh.
Mais tes clients sont bien dans le même workgroup ?
Il y aurait bien moyen en configurant ton serveur (winbind) en wins de “forcer” le réfèrencement wins des machines clientes lors de la connection, et par l’envoi des bons paramètres dhcp par le service openvpn, de signaler à tes clients d’utiliser le serveur pour résoudre en wins, mais il va falloir fouiller dans la doc d’openvpn et de winbind parceque je n’ai qu’une vague idée de comment faire.
C’est bizarre aussi cette histoire avec ton serveur samba qui doit écouter toutes les interfaces.
Le serveur WINS marche, il me résout bien les noms netbios en adresses IP.
J’avais activé le serveur WINS de Samba et rajouté ça dans la config vpn:
client-to-client
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option WINS 192.168.1.1"
et j’ai configuré Samba pour qu’il soit dans le même groupe de travail que les PC windows. Tout cela me semble opérationnel.
Peut être que je devrait faire un push des DNS…
essayes l’option client-to-client dans la config serveur, pour voir.
Sans cette option je pense que je n’aurais pas pu voir les autres clients dans le voisinage réseau. Je l’avais mise dès le début en fait.
bon. je vais me coucher, tiens… 
héhé bonne nuit
Je crois que je dois faire des excuses à Core pour lui avoir fait recompiler un noyau pour rien, à cause de ma méconnaissance d’OpenVPN.
Si j’ai bien compris - cette fois-ci - l’option “mode server” (impliquée par l’option “server-bridge” de la config de mattotop) permet à openvpn d’accepter plusieurs clients simultanément, mais, détail essentiel, avec une seule interface TAP pour tous les clients. Donc il n’y a qu’une interface tap0 quel que soit le nombre de clients connectés, alors que je pensais qu’openvpn créait une interface TAP par client connecté. Du coup le pont br0 ne sert à rien puisque tap0 est la seule interface dedans ; tap0 peut remplacer br0 dans toute la configuration. Et donc pas besoin d’un noyau supportant le pontage ethernet.
Et en effet en “mode server” l’option “client-to-client” est nécessaire pour que les clients puissent communiquer entre eux.
Concernant les règles iptables, c’est un peu n’importe quoi, il vaut mieux attendre d’avoir bien figé la configuration réseau (notamment pont ou pas pont) avant d’écrire les règles.
Note : Pour vérifier la communication entre les clients, le ping peut être insuffisant si certains clients le bloquent. Par contre l’examen du cache ARP du client source même après un ping sans réponse permet de vérifier si la résolution ARP a réussi, dans ce cas le cache contient l’adresse MAC de l’interface TAP du client destination.
Core :
J’avais écrit “ifconfig -a” OU “ip addr”. Inutile de fournir les deux, comme tu vois ils donnent à peu près les mêmes informations.
Salut pascal et merci pour tes infos, c’est pas grave pour la compilation du noyau, au moins je sais comment on fait maintenant
Pour l’instant je suis un peu limité dans mes tests car je n’ai que des PC de mon LAN qui peuvent se connecter (ce soir j’aurais des clients de l’extérieur).
Ok je touche pas aux iptables pour l’instant, suis sans FW…
Sinon ton histoire d’arp m’intéresse mais j’ai pas tout compris, de quel cache parles tu ? L’arp c’est le protocole qui permet de se voir dans le LAN d’un jeu par ex ?
Sinon j’ai trouvé un petit prog (advanced LAN scanner) qui trouve bien les PC du LAN et qui est sencé me donner les ports ouverts, je vais voir ce que je peux en tirer.
Petite précision, j’avais touché au Master browser dans la base de registre Windows, les clients sont sur MasterBrowser=no et le serveur est le Masterbrowser et localMaster, je le précise au cas ou, mais je pense qu’il n’y a pas de soucis de ce côté là… Je vois tous les clients connectés au VPN dans le voisinage réseau windows avec leurs noms netbios.
Ok, j’ai trouvé:
[code]D:\browstat>arp -a 192.168.1.1
Aucune entrée ARP trouvée
D:\browstat>arp -a 192.168.1.2
Aucune entrée ARP trouvée
D:\browstat>arp -a 192.168.1.3
Aucune entrée ARP trouvée[/code]
1 = serveur
2 = client XP
3 = client Vista
Je vais essayer d’un autre client…
Edit: de mon client Vista ça marche, j’ai bien les adresses mac…
ARP est le protocole permettant de retrouver l’adresse MAC associée à une adresse IP dans un LAN. En effet pour envoyer un paquet IP à une machine dans le même LAN, l’adresse IP ne suffit pas : il faut connaître son adresse MAC.
Cf. wikipedia pour les détails sordides.
Les jeux en réseau n’utilisent pas ARP (qui n’est utilisé qu’en interne par la pile TCP/IP) mais IP, voire IPX pour les plus vieux.
En ce qui concerne le cache ARP (ou table ARP), il faut regarder rapidement après avoir tenté une communication (ping ou autre) avec l’adresse IP cible, car son contenu expire dans le temps (typiquement 10 minutes).
Merci pour tes précisions sur l’ARP, je ne pense pas qu’il y ait de soucis de ce côté là.
Bon, je crois que je tiens une piste. Puisque en effet tout marche excepté le jeu en LAN et suite à la lecture de cet article, j’en conclue qu’il ne reste plus qu’un problème de broadcast…
Voilà la solution proposée par l’article:
Bon, y a le petit schéma qui va bien, sauf que j’ai un peu de mal à faire l’analogie avec ma configuration. Je continue à creuser…
D’après ce que j’ai compris je suis déjà dans un broadcast commun… Par contre après quelques tests je m’apperçois que la résolution de nom netbios s’effectue en IPv6 
[code]C:\Users\Core>ping sildhar
Envoi d’une requête ‘ping’ sur Sildhar [fe80::9561:8c1c:71d7:880a%12] de fe80::c
10d:71cc:4e43:9815%12 avec 32 octets de données :
Réponse de fe80::9561:8c1c:71d7:880a%12 : temps=74 ms
Réponse de fe80::9561:8c1c:71d7:880a%12 : temps=74 ms
Réponse de fe80::9561:8c1c:71d7:880a%12 : temps=74 ms
Réponse de fe80::9561:8c1c:71d7:880a%12 : temps=76 ms
Statistiques Ping pour fe80::9561:8c1c:71d7:880a%12:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 74ms, Maximum = 76ms, Moyenne = 74ms[/code]
Et si je désactive le protocole IPv6 sur le PC sildhar, le ping me trouve bien l’IPv4 (192.168.0.4) mais pas de réponse…
si tout ce que tu veux, c’est l’affichage du voisinage réseau, déjà, tu peux configurer ton serveur en wins:
ac-creteil.fr/reseaux/system … a-pdc.html
Aprés, tu auras le temps d’investiguer le pb du broadcast.
Non ça marche le serveur WINS et l’affichage réseau aussi, (cf. un peu plus haut). Mon problème est au niveau du broadcast ou/et de l’IPv6, tout le reste fonctionne, grâce à votre aide.
Si la résolution ARP fonctionne entre deux clients, alors les broadcasts devraient passer puisque les requêtes ARP sont transmises en broadcast. Ou alors openvpn fait des choses pas très avouables genre proxy ARP.
Oui en effet je pense aussi que ce ne sont pas les broadcasts le problème, mais plutôt l’IPv6… Est-ce que je ne peut pas enlever le support IPv6 de l’interface d’OpenVPN voire du dédié, ou bien juste des clients ?
sur le serveur, tu crées un fichier /etc/modprobe.d/blacklist.perso dans lequel tu mets blacklist ipv6.