# [OpenVPN] déconnexion étrange

## loopx

Bonsoir,

Je dispose d'un vpn sous openvpn (linux de chaque coté). J'aimerais savoir si il existe des "techniques" de dissuasion de l'utilisation d'un VPN (qu'y a t'il comme moyen pour empecher ou perturber une connexion VPN non authorisée par exemple).

En fait, je perd le liens toute les minutes, le débit chute brusquement, puis remonte à quelques k, puis retombe, puis crache encore quelques octets et se bloque (puis c'est un timeout qui relance la connexion). Extrènement désagréable: je ne sais pas si c'est un admin qui bloque la ligne ou si c'est un problème avec le serveur/client. Peut etre le FAI ?

Enfin, si vous aviez réponse à une de mes questions, ca pourrait ptet m'avancer un peu   :Cool: 

NB: le seul moyen actuel de contrer, c'est de diminuer fortement le temps de reconnexion ... Pas très propre, mais c'est quand meme plus utilisable...

----------

## truc

j'dis ça totalement au pif, alors faut le prendre avec des pincettes... ta config openvpn est bien en proto UDP? car sinon (proto TCP pour ceux qui ne suivent pas..  :Razz:  ) tu peux avoir des problèmes si la fenètre TCP à l'interieur du tunnel est >= à la fenètre TCP entre le client et le serveur openvpn

----------

## loopx

Je suis en TCP, pas en UDP... je dois passer a travers le net donc ...

Sinon, jte filerais les configs client/serveur pour que tu puisse voir (demain)

----------

## truc

bah donc ça pourrait éventuellement  venir de là cf ce que je viens d'essayer de dire (apparemment, j'n'ai pas été clair., tiens c'est bizarre ça, c'est pas courant, ah si en fait   :Evil or Very Mad:  )  :Wink: 

Bon maintenant, j'comprends pas trop le lien entre le fait que tu dois en TCP, et le fait que tu doives passer à travers le net ?

----------

## guilc

 *loopx wrote:*   

> Je suis en TCP, pas en UDP... je dois passer a travers le net donc ...

 

Le fait de passer par le net n'a rien a voir avec le fait de faire passer le VPN sur TCP.

Songes aux protocoles que tu vas utiliser dans ton tunnel qui ont besoin de cette fiabilité : ce sont déjà des protos TCP (quand ils ont besoin des apports de TCP) !

Donc en gros, tu empiles du TCP dans du TCP, ce qui n'apporte... rien si ce n'est des problèmes... UDP est beaucoup plus intéressant : il n'a pas de contraintes de fenêtres, une empreinte moins importante et donc fait moins chuter la réactivité/débit du tunnel, etc...

De manière générale, le VPN n'a pas à assurer la fiabilité de la liaison (tu demandes à ethernet d'assurer la fiabilité de la liaison sur ton LAN toi ?), c'est les protos encapsulés qui font leur sauce comme si le VPN n'existait pas.

Donc toujours connecter les VPN en UDP, sauf au cas marginal où l'un des endpoints ne peut être atteint qu'en TCP (cas de firewalling par exemple).

----------

## loopx

Ben tiens  :Surprised:   :Embarassed: 

La je suis embrouillé (comme les oeuf s)  :Very Happy: 

Je me disais que, TCP était un meilleur choix, parce que y a de la fiabilité en plus (mais bon, ce que tu dis est tout a fais vrai, pourquoi réencapsuler du TCP dans du TCP!  La tu m'a kc d'un coup! ). De deux, mon choix porte sur le fait que je suis firewallé ...     

Ah, de trois.... Jpense que l'UDP n'est pas permis du coté du client => la connexion sera impossible (firewallé, filtré... en gros, j'ai pris un port courant pour y faire transiter le vpn :p ).

Enfin, je vais toujours donner les 2 fichiers de configuration. Si vous pouviez me dire ce qui est utile et ce qui ne l'es pas du tout ...  :Smile: 

SERVEUR

```

serveur loopx # cat /etc/openvpn/openvpn.conf

port 443 # or any other port you want to use

dev tap

tls-server

#cd /etc/openvpn/serveur

proto tcp-server

client-to-client

ca ca.crt

cert serveur.crt

key serveur.key

dh dh1024.pem

tls-auth ta.key 0

mode server

duplicate-cn

ifconfig 10.2.1.190 255.255.255.192 # openvpn gateway

#ifconfig-pool 192.168.1.1 192.168.1.20 255.255.255.0 # ip range for openvpn client

#push "dhcp-option DNS 10.1.0.1" # push DNS entries to openvpn client

#push "dhcp-option DNS 10.2.0.2"

#push "route-gateway 192.168.1.254" # push default gateway

#mtu-test

tun-mtu 1500

tun-mtu-extra 32

mssfix 1450

ping 10

#ping-restart 60

ping-restart 10

push "ping 10"

push "ping-restart 10"

#push "route 192.169.0.0 255.255.255.0 192.168.1.254" # add route to to protected network

#push "route 0.0.0.0 0.0.0.0 192.168.1.254"

comp-lzo

status openvpn-status.log

verb 4

```

CLIENT

```

bla loop # cat /etc/openvpn/openvpn2.conf

port 443 # or any other port you want to use

dev tap0

remote blabla.bla

#remote 10.59.4.5

proto tcp-client

persist-tun

connect-retry 10

tls-client

ca ca.crt

cert bla.crt

key bla.key

tls-auth ta.key 1

#mtu-test

tun-mtu 1500

tun-mtu-extra 32

mssfix 1450

pull

comp-lzo

verb 4

ifconfig 10.2.1.189 255.255.255.192

#route 0.0.0.0 0.0.0.0 10.2.1.190

```

Ah uh oh... y aurait'il un programme pour tester la connectivité (ici UDP) d'un pc à l'autre ??

NB: pour mieux situer le souci ... je n'arrive meme pas à conserver une connexion "fluide" avec ssh ... le vpn saute (ca va de 10 secondes à 2-3 minutes ...). Super hein  :Wink: 

----------

## loopx

J'ai une question toute conne ...

C'est quoi la différence entre TUN et TAP ???  Parce que moi j'ai des TAP, et des gens on des TUN ...   :Rolling Eyes: 

----------

## guilc

 *loopx wrote:*   

> J'ai une question toute conne ...
> 
> C'est quoi la différence entre TUN et TAP ???  Parce que moi j'ai des TAP, et des gens on des TUN ...  

 

Tun est sur IP

Tap est sur Ethernet

Suivant ce que tu fais (bridging par exemple), c'est tap obligatoire.

Mais pour openvpn, tun va aussi très bien. C'est un choix moins impactant en configuration "standard". Le choix est plus critique avec des exotismes  :Wink: 

[EDIT]

Pour répondre à ton problème de connexion qui saute : commence par retirer les options de MTU et MSS. c'est sans doute ça qui fait sauter la connexion en causant une très forte fragmentation :

- Sur ton réseau ethernet, t'es déjà à 1500, un peu moins pour ta liaison ethernet sans doute (ou pareil si dhcp et RFC 1483).

- Si dans ton VPN passe un paquet de environ 1500 octets, tu ajoutes l'overhead ssl pour l'encapsulation VPN => le paquet va faire disons  1550 (valeur arbitraire non calculée, mais ça doit tourner dans ces eaux là) => fragmentation moche, qui va arriver sur presque chaque paquet !

Et ça, ssh il aime pas, mais alors pas du tout niveau stabilité...

----------

## sd44

je comprend pas tout je croyais que tun c'est le mode routed et tap le mode bridged (permet de faire un pont reseau) ? 

perso ca marche en tun + udp et aucun probleme linux ou windows

----------

## guilc

 *sd44 wrote:*   

> je comprend pas tout je croyais que tun c'est le mode routed et tap le mode bridged (permet de faire un pont reseau) ? 
> 
> perso ca marche en tun + udp et aucun probleme linux ou windows

 

Oui mais pour bridger une interface : il faut pouvoir agir au niveau ethernet, donc interface tap obligatoire

tun s'appuyant sur la couche IP, trop haute pour bridger l'interface, il ne reste que le routage  :Smile: 

Le fait que tun serve pour du routage et tap pour du bridge est une conséquence de leur propriété respective  :Wink: 

----------

## sd44

ok vu sous cet angle   :Smile: 

perso j'avais essayer tap mais j'avais eu beaucoup de probleme pour creer l'interface sous linux, j'ai pas trouver une doc vraiment a jour ...

----------

## guilc

 *sd44 wrote:*   

> ok vu sous cet angle  
> 
> perso j'avais essayer tap mais j'avais eu beaucoup de probleme pour creer l'interface sous linux, j'ai pas trouver une doc vraiment a jour ...

 

Je dois dire que moi aussi mon VPN est construit sur une interface tun en UDP, et ça ne m'a jamais posé aucun problème de fonctionnement. les features de tap ne sont en général pas utile pour un vpn  :Wink: 

Le tap je me le garde pour bridger mes virtualbox  :Wink: 

----------

## sd44

[off]merci guillc je vient de decouvrir virtualbox et c'est vraiment sympa   :Very Happy:  [/off]

----------

## truc

 *sd44 wrote:*   

> ok vu sous cet angle  
> 
> perso j'avais essayer tap mais j'avais eu beaucoup de probleme pour creer l'interface sous linux, j'ai pas trouver une doc vraiment a jour ...

 

Bah on n'y pense pas forcément, mais la doc officielle est souvent à jour... par exemple, la doc d'openvpn, est vraiment très bien, j'l'ai déjà dit sur ce forum tout  plein de fois, on va finir par croire que j'ai des actions chez eux (hum.. ah non en fait c'est con ce que j'dis..  :Laughing:  )

Ainsi pour créer une interface tap avec openvpn, tu fais simplement quelque chose du style openvpn --mktun --dev tap0 et ensuite tu peux jouer avec brctl tu créé d'abord ton 'pont' et ensuite tu lui rajoutes les interfaces une par une  :Smile: 

----------

## loopx

 :Laughing: 

C'est trop marrant ce topic qui est le mien   :Cool: 

Parce que bon, la on me raconte que : 

TAP=> ethernet

TUN=> IP

Moi, je me fou de ethernet, et j'ai TAP (jamais eu de problème de création de cette TAP) alors que c'était pas trop utile   :Rolling Eyes: 

Bon, je vous explique brievement comment faire un VPN avec un TAP:

fournir les configs et les clé au serveur/client

et préciser que c'est TAP ou TAPx (x=num de la tap)   et lancer le service  :Smile:     compliqué hein  :Very Happy: 

Bon, faudra quand meme que je test le TAP en UDP (je suppose que c'est pas le choix TAP/TUN qui pose des soucis dans mon cas).

Dans tout les cas, un grand merci pour les infos, j'avais visiblement de grosse lacune sur le sujet  :Smile: 

EDIT: j'ai toujours aucun moyen de tester la connexion UDP entre 2 points, personne n'a une chtit idée ??? ou jvais devoir faire un truc de fou pour y arriver   :Laughing: 

----------

## loopx

Bonjour, 

ptit up   ...

J'ai modifié un truc dans la config ... En fait, j'avais mis le ping-restart à 10 secondes coté client et serveur, je me suis appercu que ca se reconnectais tout le temps, j'ai donc passé cette valeur à 1000 coté serveur, et maintenant c'est au client de décider (après 10 secondes) une reconnection (il semblerait que le serveur, ne recevant aucun packet, restartait la connexion toute les 10 secondes).

Donc, ca se reconnecte moins souvent, mais ca le fait toujours, et particulièrement quand on augmente la charge ...

Pour l'instant, mon serveur me dis ceci : 

```

Oct  2 22:16:30 serveur openvpn[18204]: le-client/123.321.123.321:52262 MULTI: Learn: 6a:eb:23:18:89:ba -> le-client/123.321.123.321:52262

Oct  2 22:16:30 serveur openvpn[18204]: le-client/123.321.123.321:52886 MULTI: Learn: 6a:eb:23:18:89:ba -> le-client/123.321.123.321:52886

Oct  2 22:18:27 serveur openvpn[18204]: le-client/123.321.123.321:52262 MULTI: Learn: 6a:eb:23:18:89:ba -> le-client/123.321.123.321:52262

Oct  2 22:18:27 serveur openvpn[18204]: le-client/123.321.123.321:52886 MULTI: Learn: 6a:eb:23:18:89:ba -> le-client/123.321.123.321:52886

```

Cela ne semble pas etre une reconnection ... il "découvre" un hote sur le VPN, mais je comprend pas les :52XXX (numero de port  :Surprised:  ?)... Et surtout, pourquoi il le fait plusieurs fois! alors qu'avant ca le faisait une seule fois ... 

Fin, c'est toujours le bordel, si la connexion saute (ce qui se fait tjs), 10 secondes et hop, une reconnexion ... et mon kde peut alors continuer la copie  :Very Happy: 

----------

## sd44

t'es toujours pas sur udp ? j'ai en gros la conf a bouletbill (openvpn section documentaire) et aucun probleme !

----------

## loopx

nop, tjs en TCP (qui fonctionnais à un moment ... pendant 1 an meme, mais depuis 1 an, l'es kc ...). Un autre à tester un autre vpn en UDP, mais ca passais pas, je testerais .. pour etre sur.  En tout cas, jpige pas les lignes plus haut, il jongle avec 2 ports sources... Pourquoi ????

```

Oct  2 22:40:07 serveur openvpn[18204]: MULTI: multi_create_instance called

Oct  2 22:40:07 serveur openvpn[18204]: Re-using SSL/TLS context

Oct  2 22:40:07 serveur openvpn[18204]: LZO compression initialized

Oct  2 22:40:07 serveur openvpn[18204]: Control Channel MTU parms [ L:1576 D:168 EF:68 EB:0 ET:0 EL:0 ]

Oct  2 22:40:07 serveur openvpn[18204]: Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]

Oct  2 22:40:07 serveur openvpn[18204]: Local Options String: 'V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_SERVER,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'

Oct  2 22:40:07 serveur openvpn[18204]: Expected Remote Options String: 'V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_CLIENT,comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'

Oct  2 22:40:07 serveur openvpn[18204]: Local Options hash (VER=V4): '3c14feac'

Oct  2 22:40:07 serveur openvpn[18204]: Expected Remote Options hash (VER=V4): 'e39a3273'

Oct  2 22:40:07 serveur openvpn[18204]: TCP connection established with 123.321.123.321:13350

Oct  2 22:40:07 serveur openvpn[18204]: Socket Buffers: R=[131072->131072] S=[131072->131072]

Oct  2 22:40:07 serveur openvpn[18204]: TCPv4_SERVER link local: [undef]

Oct  2 22:40:07 serveur openvpn[18204]: TCPv4_SERVER link remote: 123.321.123.321:13350

Oct  2 22:40:07 serveur openvpn[18204]: 123.321.123.321:13350 TLS: Initial packet from 123.321.123.321:13350, sid=cc3b6cb3 0c75e13d

Oct  2 22:40:08 serveur openvpn[18204]: 123.321.123.321:13350 VERIFY OK: depth=1, BLABLABLA

Oct  2 22:40:08 serveur openvpn[18204]: 123.321.123.321:13350 VERIFY OK: depth=0, BLABLABLA2

Oct  2 22:40:08 serveur openvpn[18204]: 123.321.123.321:13350 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key

Oct  2 22:40:08 serveur openvpn[18204]: 123.321.123.321:13350 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

Oct  2 22:40:08 serveur openvpn[18204]: 123.321.123.321:13350 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key

Oct  2 22:40:08 serveur openvpn[18204]: 123.321.123.321:13350 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

Oct  2 22:40:08 serveur openvpn[18204]: 123.321.123.321:13350 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

Oct  2 22:40:08 serveur openvpn[18204]: 123.321.123.321:13350 [le-client] Peer Connection Initiated with 123.321.123.321:13350

Oct  2 22:40:08 serveur openvpn[18204]: le-client/123.321.123.321:13350 MULTI: no dynamic or static remote --ifconfig address is available for le-client/123.321.123.321:13350

Oct  2 22:40:09 serveur openvpn[18204]: le-client/123.321.123.321:13350 PUSH: Received control message: 'PUSH_REQUEST'

Oct  2 22:40:09 serveur openvpn[18204]: le-client/123.321.123.321:13350 SENT CONTROL [stargate]: 'PUSH_REPLY,ping 10,ping-restart 10' (status=1)

Oct  2 22:40:20 serveur openvpn[18204]: le-client/123.321.123.321:13350 MULTI: Learn: 6a:eb:23:18:89:ba -> le-client/123.321.123.321:13350

Oct  2 22:40:26 serveur openvpn[18204]: le-client/123.321.123.321:58069 MULTI: Learn: 6a:eb:23:18:89:ba -> le-client/123.321.123.321:58069

Oct  2 22:40:26 serveur openvpn[18204]: le-client/123.321.123.321:13350 MULTI: Learn: 6a:eb:23:18:89:ba -> le-client/123.321.123.321:13350

Oct  2 22:41:05 serveur openvpn[18204]: le-client/123.321.123.321:58069 MULTI: Learn: 6a:eb:23:18:89:ba -> le-client/123.321.123.321:58069

Oct  2 22:41:05 serveur openvpn[18204]: le-client/123.321.123.321:13350 MULTI: Learn: 6a:eb:23:18:89:ba -> le-client/123.321.123.321:13350

Oct  2 22:42:23 serveur openvpn[18204]: le-client/123.321.123.321:58069 MULTI: Learn: 6a:eb:23:18:89:ba -> le-client/123.321.123.321:58069

Oct  2 22:42:23 serveur openvpn[18204]: le-client/123.321.123.321:13350 MULTI: Learn: 6a:eb:23:18:89:ba -> le-client/123.321.123.321:13350

Oct  2 22:45:06 serveur openvpn[18204]: le-client/123.321.123.321:57790 read TCPv4_SERVER [NO-INFO]: Connection timed out (code=110)

Oct  2 22:45:06 serveur openvpn[18204]: le-client/123.321.123.321:57790 Connection reset, restarting [0]

Oct  2 22:45:06 serveur openvpn[18204]: le-client/123.321.123.321:57790 SIGUSR1[soft,connection-reset] received, client-instance restarting

Oct  2 22:45:06 serveur openvpn[18204]: TCP/UDP: Closing socket

```

Donc, le problème est tjs le meme, Learn assez étrange (ceci ce fait sur seulement 5 minutes, voir moins!

Bete question, pourquoi est-ce que : "TCP/UDP: Closing socket" ... et que ... je download toujours à travers le VPN ... ?????????????? Je suis complètement perturbé la, en tout ca, ca fonctionne encore ^^

----------

## sd44

non de non, change donc tcp par udp et regarde et tire tes conclusions, deja tu sera pas en mode connecté ! t'aura donc pas de deconnections   :Laughing: 

----------

## loopx

lol, terrible ta déduction  :Very Happy: 

en fait, je fais mon lourd, j'ai pas trop envie de changer, parce que jvais perdre la connex pendant un moment sinon ....  mais je testerais quand meme ... 

Faut changer quoi pour que ca fonctionne (j'ai mis mes configs plus haut), je change juste TCP en UDP et hop, c bon ?

Suis tjs à la recherche d'un progz pour test la connex UDP ...   udptraceroute peut etre :p (pff, c'est nul, autant y a tout pour tcp, autant il y a rien pour udp)

----------

## sd44

oui c'est tout (client et srv) 

pour info voila ma conf client, moi je suis en mode routed

```

client

dev tun

proto udp

remote 82.239.xx.xx

resolv-retry infinite

nobind

persist-key

persist-tun

ca /usr/share/openvpn/easy-rsa/keys/ca.crt

cert /usr/share/openvpn/easy-rsa/keys/sd.crt

key /usr/share/openvpn/easy-rsa/keys/sd.key

ns-cert-type server

comp-lzo

log         /var/log/openvpnsd.log

log-append  /var/log/openvpnsd-old.log

verb 3

```

et ma conf srv

```

mode server

tls-server

port 1194

proto udp

dev tun

ca /usr/share/openvpn/easy-rsa/keys/ca.crt

cert /usr/share/openvpn/easy-rsa/keys/freestux.jallais.net.crt

key /usr/share/openvpn/easy-rsa/keys/freestux.jallais.net.key

dh /usr/share/openvpn/easy-rsa/keys/dh1024.pem

server 192.168.100.0 255.255.255.0

ifconfig-pool-persist ipp.txt

push "route 192.168.1.0 255.255.255.0"

push "route 192.168.2.0 255.255.255.0"

push "route 192.168.3.0 255.255.255.0"

push "route 192.168.4.0 255.255.255.0"

push "dhcp-option DNS 192.168.1.252"

push "dhcp-option DNS 192.168.100.1"

push "route-gateway"

client-to-client

keepalive 10 120

comp-lzo

max-clients 10

persist-key

persist-tun

status openvpn-status.log

log         /var/log/openvpn.log

log-append  /var/log/openvpn.log

verb 1

```

----------

## truc

 *sd44 wrote:*   

> non de non, change donc tcp par udp et regarde et tire tes conclusions, deja tu sera pas en mode connecté ! t'aura donc pas de deconnections  

 

loul, celle là, j'la ressortirai c'est sûr!  :Razz:   :Laughing: 

 *loopx wrote:*   

> en fait, je fais mon lourd, j'ai pas trop envie de changer, parce que jvais perdre la connex pendant un moment sinon .... mais je testerais quand meme ... 

 

euh? mais attends, tu nous dis que ta connexion n'est pas stable de toute façon? je ne comprends pas pourquoi? tu la perdrais? (hormis le temps que ça peut te prendre de changer TCP en UDP?)

Arpès, j'avoue que pour la science, ça serait interessant de modifier la taille des fenêtres TCP à l'interieur et pour le tunnel, mais je ne sais pas spécialement comment faire, mais serait ravi que tu nous racontes tout ça  :Smile: 

----------

## loopx

Ben en fait, j'ai pas vraiment accès au client si celui-ci se déconnecte du vpn  :Very Happy:    ou si, ce qui arrive, le service openvpn ne redémarre pas...

Tu me dis que tu es en mode "routed", donc, tu utilise tun (tu n'es pas au niveau ethernet mais ip). Je pourrais tester, mais il faut modifier le kernel du client (qui est loin de chez moi ^^). 

Question: puis-je utiliser une TAP avec un TUN (client=tap, serveur=tun) sans que cela pose problème ???

Je vous promet que j'y regarderais  :Very Happy:    mais la, je suis meme pas chez moi ...

Enfin, merci pour les infos  :Wink: 

----------

## sd44

chez moi j'ai une interface tap et une tun , je me sert de la tap pour virtualbox et tun pour vpn, tap et eth0 etant sur mon bridge br0.

je te conseil de créé une tun sur le client (c'est automatique de toute facon avec openvpn) car tun <=> tap je suis pas sur que ca passe.

tu n'as pas a modifier ton kernel car si tu a une tap c'est que l'option tun/tap est coché

en gros change tap par tun et tcp par udp et verif ta conf avec la miene et ca roule ...

----------

## truc

je crois effectivement me rappeller que tu peux être en mode routé avec une interface tap (mais pas l'inverse ( tun en mode bridge )), ça doit tout simplement être marquer sr le site d'openvpn

----------

## loopx

Question: j'ai 2 réseaux (A et B). A=10.0.0.0/24, B=10.0.1.0/24. Il y a du PAT pour sortir de A vers B donc, on peut pas remonter facilement de B vers A. Dans B, il y a le un groupe de travail windows auquel j'aimerais accéder (avoir une liste de pc via smb4k par exemple...). Actuellement (on mode routage... pat...), impossible d'y accéder (le scan fonctionne pas, parce que je suis sur le réseau A et non B. 

Je pense donc à un truc: si je cré un pont entre A et B (sur une autre interface, ou alors je retire le PAT et je garde juste le bridge). En gros, j'espère pouvoir faire une recherche samba grace à ce pont   :Laughing:  parce que j'aurais une interface directement connecté sur le réseau B ... (fin, je sais pas trop si c'est réaliste, je m'y perd facilement avec les pont   :Embarassed:  )

Donc, je suis au point A, ou il y a le réseau A. Je crée un pont pour accéder à B et pour espérer que smb4k arrivera à lister tout les ordi de B (niveau samba) pour que je puisse m'y cononecté   :Surprised: 

Alors, je suis déjà fou ou presque ?   :Rolling Eyes: 

----------

## sd44

du pat ? c'est quoi ca ? du NAT plutot ? perso avec openvpn je suis en mode routed (ca tu le sais deja   :Very Happy:  ) et je n'est pas de probleme pour voir les reseaux d'un coté ou de l'autre

juste une remarque, prefere autoscan-network a smb4k car le mode de fonctionnement n'est pas basé uniquement sur ping (mais plutot arp) et en plus tu detecte mieux les machines non windows avec une foule d'infos en plus

pour info : http://autoscan-network.com et je suis le mainteneur gentoo de ce projet, mais j'ai pas encore fini de tester l'ebuild.

d'autre part le mode bridge sera plus adapté a ce que tu veux faire il me semble.

----------

## truc

@ sd44:

Le PAT cest très certainement ce que tu appelles par abus de langage le NAT, Port address Translation, avec les ports quoi... ce que tu fais généralement sur ton LAN perso pour sortir avec ta seule IP publique

@loopx, un bridge pourrait t'aider, mais tu utiliseras alors typiquement openvpn avec une interface TAP, en mode bridge  :Smile: 

Maintenant je ne sais pas si le bridge est le seul moyen pour pouvoir lister des partages? ça serait etonnant (comprendre, ça serait étonnant que les partages samba ne se voient que par des broadcast   de niveau 2 ? )

----------

## loopx

Ben en fait, j'ai accès au samba, le samba fonctionne ... Le seul truc qui fonctionne pas, c'est que je n'arrive pas à lister les partages samba sur un réseau (liste des pc d'un groupe de travail quoi ...). C'est betement pour ca que je pense au bridge. De plus, si on ne peut pas scanner les pc samba, on ne peut pas effectuer de "recherche" sur ces partages...

Y aurait'il moyen en utiliser un bon vieux windows ? Il faut savoir que c'est mon serveur qui gère le VPN, et que tout packet en direction du net traverse le serveur (routage donc ...). Le truc, c'est que le windows serait directement connecté au réseau A et non B. Il faudrait qu'il puisse "voir" les machines de manière automatique (sans scan de port ou quoi de manière manuel) sinon, l'intérret du samba tombe à l'eau (en partie).

@Truc:

Pour le PAT, c'est effectivement du NAT ... mais on nous à appris à l'appelé PAT à l'école (ou pour pouvoir passer du réseau A vers le réseau B, on parle de PAT statique ...). Il y a 2 ans, grace à gentoo, j'ai meme réussis à appelé cela du SNAT (NAT ou on change l'adresse/port source)... Bon, va savoir ce qu'il faut utiliser, moi j'y pige rien, de plus ca dépend ptet du pays (belgique/france)... Rah les langues   :Laughing: 

----------

## truc

bah un moyen pseudo-mémotechnique pour distinguer les deux, c'est que le SNAT à lieu après le routage(chaine POSTROUTING), et le DNAT avant le routage (PREROUTING)  :Smile: 

Sinon, je fais la distinction entre du NAT statique et du NAT dynamique, j'vois bien ce qu'on appelle du PAT,(c'est le NAT de monsieur tout le monde en gros), mais alors du PAT statique, j'dois avouer que là je sèche?   :Shocked: 

BOn, j'viens de lancer tcpdump et un smbtree, et... bah ça semble effectivement êtres des broadcast arp qui sont balancés, donc tu peux faire joujou avec le mode bridge d'openvpn, par contre c'est tout de suite plus chiant (à mon avis) car il faut que vous soyez sur la même plage réseau ensuite etc..., bref, galère quoi  :Razz: 

Heureusement, que tout est expliqué sur le HOWTO 2x sur http://www.openvpn.net

Après, j'n'ai pas ton architecture en tête donc ça peut même être plus lourd que prévu:P

----------

## sd44

j'ai du mal a cerner tes probleme loopx, moi ca me parait pourtant simple :

2 reseaux + un pont + du routage

en mode routed j'arrive parfaitement a ouvrir des partage etc ... d'un reseau a l'autre.

de plus :

NAT : network adresse translation

SNAT : Le Source NAT correspond à la modification de l'adresse source dans un paquet translaté

DNAT : Le Destination NAT correspond à la modification de l'adresse destination dans un paquet translaté

le NAT c'est avec iptables (et la table nat   :Very Happy:  ) pour rerouter des paquets 

quand au pat il semble que je l'utilise sans le savoir   :Laughing: 

# redirection pour squid (PAT)

 *Quote:*   

> $IPTABLES -t nat -A PREROUTING  -i $LAN -p tcp --dport 80 -j REDIRECT --to-port 8080

 

#exemple DNAT : redirection des paquets a destination du port imap sur mon serveur imap (qui arrive sur mon firewall)

 *Quote:*   

> $IPTABLES -t nat -A PREROUTING -i $INTERNET -p tcp --dport 143 -j DNAT --to-destination 192.168.1.246

 

#exemple SNAT : mes regles pour openvpn

 *Quote:*   

> 
> 
> $IPTABLES -t nat -A POSTROUTING -s 192.168.100.0/255.255.255.0 -d ! 192.168.100.1 -j SNAT --to-source 192.168.1.252
> 
> $IPTABLES -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0 -j MASQUERADE
> ...

 

quand a ton probleme de partage n'est ce pas simplement un probleme de routage ? tu peut atteindre les pc, mais eux peuvent t'ils te repondre ?

d'autant plus qu'en mode routed le broadcast ne passe pas (il me semble) et windows est un peu perdu  :Smile: 

[edit] truc on a posté en meme temps[/edit]

----------

## truc

son problème n'est pas vraiment d'afficher les partages d'une hôte en particulier, mais de lister les partages de tout le monde (enfin si j'ai bien compris c'est ça que tu veux loopx c'est ça?)

----------

## loopx

Merci pour vos réponse  :Smile: 

Alors, je m'explique ...  :Very Happy: 

Le PAT = le nat de monsieur tout le monde  :Wink:    ... Si je me trompe pas, le packet du client A du resaux X arrive sur le serveur ou il y a du PAT, l'adresse source ET le port source sont mémorisé pour pouvoir renvoyer la réponse au client A, parce que les pc derrière le serveur ne connaisse pas l'adresse de client A ... (ex: réseau privé/public[= internet]). Le PAT statique, c'est le truc ou tu redirige un port du serveur/routeur vers une autre machine du réseau à un port (différent ou égal); c'est donc pour le PAT, un moyen de remonter dans le réseau privé (lol, imaginer un barrage et le truc à saumon ^^).

Alors, comme le dis le poste juste au dessus, c'est bien un problème de listing des partages d'un réseau et non un listing des partage d'un hote; comme dis plus haut, j'accède sans problème aux partage d'un autre réseau, mais impossible de connaitre toutes les machines présentes (ainsi que leur groupe de travail) et cela, certainement parce que je ne suis pas sur le même réseau.

Je vais expliquer un peu mon architecture:

réseau:

- A => le réseau chez moi (entre serveur et client)

- B => le réseau chez moi (entre serveur et routeur)

- C => le réseau chez moi et chez les participants du VPN (entre serveur et client OpenVPN)

- X => le réseau distant, rempli de partage samba   :Laughing: 

C'est 3 premier réseaux sont en fait basé sur une classe C, ce sont des sous réseaux qui fonctionne parfaitement ( /26 ).

X est un réseau différent (class C).

en gros, voilà la connex VPN:

SITE_DISTANT[ serveur1(client OpenVPN) => des_routeurs_fous(ou j'ai pas accès ^^) ] => INTERNET => MAISON[ routeur => serveur(serveur OpenVPN) ]

des_routeurs_fous : ce sont des routeurs entre le réseau X et internet; ils sont cause de problème de connexion via UDP et bien d'autre...

Donc, le SITE_DISTANT et le site MAISON ont tout deux 1 serveur permettant de router les packets. Par router j'entend: ip_forward=1, 1 NAT (SNAT, PAT...) pour tout ce qui sort sur le réseau X). Les routes sont gérée par un protocole de routage dynamique (OSPF via quagga ). Sur mon serveur à la maison, j'ai donc 3 réseaux directement connecté et 1 réseau (X) distant. Tout les pc contacté sur le réseau X ne savent pas que c'est un pc provenant du réseau A qui fait la connexion, il ne voit qu'une connexion provenant du serveur situé sur le SITE_DISTANT (ainsi, je peux dire qu'aucun firewall ou problème de route manquante ne viens me pourrir la vie). J'ai aussi accès à d'autre réseau distant du réseau X et j'y ai accès, comme tout pc sur le réseau X (vu qu'il y a du PAT).

En gros, mon VPN est en TCP   :Laughing:   et dans le VPN, le protocole UDP peut circuler   :Rolling Eyes: 

Tous est accessible, ormi le fait que la "signalisation des partages samba" du réseau X n'atteind jamais le réseau A.

Ahhh, j'oubliais:

MAISON:

Client A => AP ( bridge linksys) => [réseau A] SERVEUR [réseau B] => routeur => INTERNET

Client B

Client C

Les clients A, B et C sont connecté sur le réseau A dont la passerelle (gateway) n 'est autre que SERVEUR. Une fois la connexion VPN établie, le réseau C est accessible par tout client (A, B, C) puisque leur packet traverse le SERVEUR ... une route en plus sera ajoutée par la TAP gérée via OpenVPN ce qui aura pour effet que le packet vers le réseau X ne passe pas directement sur internet mais est encapsulé dans le VPN qui lui, passe sur internet... fin, c'est du VPN quoi.

Vous appeleriez ca comment ? Du routage NATé, du NAT routé ? Ou du routage avec NAT/PAT ???   :Wink: 

Alors, meme question, comment arriver à récuperer un listing des partages samba ? Y a pas moyen de rediriger les broadcast arrivant sur le serveur du SITE_DISTANT vers mon serveur et vers mes réseaux ???

----------

## sd44

etant donné que tu as deux reseaux different, que le broadcast nécéssaire a win pour voir les autres machines ne passera pas, as tu envisagé de mettre 1 ou 2 serveur wins ? bien sûr il faut configurer les clients.

----------

## loopx

Je ne connais pas les serveurs wins, et il m'est impossible de configurer tous les clients du reseau X...

Il n'y a pas un moyen de transmettre le broadcast sur un autre réseau grace à une règle iptables ???   :Laughing: 

EDIT: il n'y a pas un moyen automatique d'attribuer un server WINS aux clients ??? Tout le réseau est géré par des gentoo   :Rolling Eyes: 

----------

## sd44

un broadcast c'est un paquet du style 192.168.1.255 sur un reseau classe c. le fait d'adresser ce paquet a 255 fait que tout les pc du meme sous reseau y reponde, c'est comme un joker, donc l'envoyer sur un autre reseau qui n'ecoute pas cette adresse ne servirait a rien ! d'ou wins, et pour ce dernier c'est tout simple si tes pc sont en dhcp, ajoutes ces lignes dans ton dhcpd.conf :

```
option routers 192.168.0.1;

option netbios-name-servers 192.168.0.1;

option netbios-dd-server 192.168.0.1;

option netbios-node-type 8;

```

pour les autres c'est a la main   :Very Happy: 

----------

## loopx

Mmm, ca devient plus intéressant là  :Smile: 

Si les clients peuvent etre configuré automatiquement ...

Pour le serveur WINS, il faut que j'emerge un truc autre que samba ?

Et après, je dois installer un serveur WINS de mon coté et configurer les 2 pours qu'il communique ensemble ?

Et régler mon réseau puis ca pourrais fonctionner ...

----------

## sd44

oui samba suffit, et 1 seul serveur wins aussi (et 1 pour la replication si tu veux)

cette ligne dans samba suffit :

```
wins support = yes
```

----------

## loopx

Mmm, intéressant  :Smile: 

Jvais penser à installer ca, ca m'évitera la modification de la connex vpn pour avoir un pont   :Cool: 

Question: est-ce que WINS est toujours d'actualité dans vista ? Histoire de pas apprendre trop de vieille tech   :Wink: 

----------

## sd44

quand je vois vista, parfois je prefere les "vielles" tech ! ok   :Arrow:  []

----------

