Tunnel OpenVPN sous HTTPS (port 443)

[HP77]

Bonjour,

J'aimerais savoir s'il existe une solution simple au problème suivant :

- Je souhaite me connecter à mon serveur SME 7.4 en utilisant OpenVPN depuis l'entreprise où je travaille.
- L'entreprise semble n'autoriser que le traffic sur les ports HTTP, HTTPS et FTP.
- SSH, SFTP fonctionnent si j'adopte le port 443 (HTTPS) au lieu du port 22. Pour cela, j'ai dû configurer une redirection du port 443 sur le 22 sur le serveur visé.
- OpenVPN ne parvient pas à établir de connection depuis l'entreprise mais aucun souci si je ne suis pas dans l'entreprise (i.e. cybercafé ou chez des amis).

Pour information :

- Je ne suis pas expert en réseau bien qu'étant capable de faire pas mal de petites choses. (mais sans la théorie, on ne va pas très loin non plus ; d'où ma venue sur ce forum.)
- "OpenVPN server" est hébergé sur un serveur Web et fichiers basé sur SME 7.4.
- OpenVPN fonctionne parfaitement en UDP et TCP sur le port 1194.
- Accès SSH au serveur par le port 443 (HTTPS) via un port forwarding 443 => 127.0.0.1:22.
- SFTP possible via le logiciel WinSCP si j'utilise le port 443 au lieu de 22, normal si tout est basé sur SSH.

Essais déjà tentés sans succès :

- OpenVPN en écoute sur port 443 (=> SSH en écoute sur port 22 ; Redirection port 443 => 127.0.0.1:1194)

Dans ce cas, le Log OpenVPN indique un problème de taille de packets liés à l'encapsulation HTTPS.
Pas de souci côté SSH pour lequel la redirection de port 443 sur 127.0.0.1:22 est toujours active.

Extrait du fichier Log du client sous MS-WinXP Pro :

Code: Tout sélectionner

...
Attempting to establish TCP connection with aaa.bbb.ccc.ddd:443
TCP connection established with aaa.bbb.ccc.ddd:443
Socket Buffers: R=[8192->8192] S=[8192->8192]
TCPv4_CLIENT link local: [undef]
TCPv4_CLIENT link remote: aaa.bbb.ccc.ddd:443
WARNING: Bad encapsulated packet length from peer (21331), which must be > 0 and <= 1576 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attemping restart...]
Connection reset, restarting [0]
TCP/UDP: Closing socket
SIGUSR1[soft,connection-reset] received, process restarting
Restart pause, 5 second(s)
Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
...

- Redirection du port 443 sur le port OpenVPN 1194 (=> SSH en écoute sur port 443 ; Redirection port 443 => 127.0.0.1:1194)

Dans ce cas, la connexion OpenVPN via TCP n'aboutie pas.

Extrait du fichier Log du client sous MS-WinXP Pro :

Code: Tout sélectionner

...

OpenVPN 2.0.7 Win32-MinGW [SSL] [LZO] built on Apr 12 2006
Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
LZO compression initialized
Control Channel MTU parms [ L:1576 D:168 EF:68 EB:0 ET:0 EL:0 ]
Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
Local 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'
Expected Remote 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'
Local Options hash (VER=V4): 'e39a3273'
Expected Remote Options hash (VER=V4): '3c14feac'
Attempting to establish TCP connection with aaa.bbb.ccc.ddd:1194
...

Déjà, Merci d'avoir lu jusqu'ici

Salutations,
HP[/list]

[jdh]

(toujours un peu verbeux, mais au moins il y a de l'info ...)


Concernant OpenVPN, il y a plusieurs points intéressants à lire dans la doc :

- pourquoi udp et non tcp ?
=>contrairement à ce qu'on pourrait penser, il faut utiliser de préférence udp ! (Je doute que l'implantation SME d'OpenVpn fonctionne en udp et tcp simultanément ...)

- utilisation de tcp/443=https avec openvpn ?
=> OpenVPN est capable de traiter tcp/443 tout en laissant la possibilité d'avoir https pour un serveur web ! Bon à savoir (même si je n'ai pas lu ni testé cela)

[ccnet]

UDP et TCP à la fois, j'en doute aussi.

TCP 443 est possible pour openvpn. J'ai en production une configuration de ce type. Il reste néanmoins qu'il faut préférer UDP.

La seule modification nécessaire est celle du fichier de conf du serveur et bien sur les clients doivent être configurés en rapport. Le filtrage réseau aussi.

[HP77]

Bonsoir,

Tout d'abord, Merci d'avoir prété attention à mon messsage même s'il vous semble un peu long à vous aussi. (désolé JDH mais, comme tu dis, c'est pour les infos...)

Concernant le choix UDP ou TCP, j'avais bien compris que UDP était préférable pour bien des raisons même si je ne me souviens pas de tout car OpenVPN-Bridge a été installé et la doc lue il y a maintenant 2 mois...
Je me souviens, entre autres choses, qu'avec UDP on bénéficie d'une "auto-adaptation" du MTU mais, de mémoire, cela ne semblait pas être la raison essentielle.

D'ailleurs, je fonctionnais en UDP (mode proposé par défaut, qui plus est) avant d'être contraint de prendre l'option TCP : en effet, il manque un élément d'information : TCP semble donner des résultats (au niveau des Logs) mais pas UDP lorsque je suis dans cette entreprise. D'où ce choix discutable...

... (Je doute que l'implantation SME d'OpenVpn fonctionne en udp et tcp simultanément ...) ...

UDP et TCP à la fois, j'en doute aussi.

Désolé d'avoir introduit cette impression par l'utilisation de UDP et TCP au lieu de UDP ou TCP lorsque je disais avoir essayé, et l'un, et l'autre mais, bien sûr, chacun leur tour...
(encore une erreur de débutant fonçant "la tête dans le guidon"...)

- utilisation de tcp/443=https avec openvpn ?
=> OpenVPN est capable de traiter tcp/443 tout en laissant la possibilité d'avoir https pour un serveur web ! Bon à savoir (même si je n'ai pas lu ni testé cela)

TCP 443 est possible pour openvpn. J'ai en production une configuration de ce type. Il reste néanmoins qu'il faut préférer UDP.

La seule modification nécessaire est celle du fichier de conf du serveur et bien sur les clients doivent être configurés en rapport. Le filtrage réseau aussi.

Bonne nouvelle !!
Bon, il me reste donc à découvrir se qui se cache derrière ce curieux message d'erreur lié(?) à l'encapsulation (cf. log had hoc de mon premier message).

Ccnet, que faut-il comprendre par filtrage réseau ?


Autrement, juste une parenthèse ssur SSH :
Lors de mes premiers essais de redirection du port 443 => 127.0.0.1:22, je n'avais plus l'accès via HTTPS à mon serveur.
Curieusement, depuis plusieurs semaines, je n'ai plus ce problème.
Une idée vous vient également là-dessus ?
Serait-ce là une piste à creuser pour ce "problème d'encqpsulqtioon" ??
(j'avoue que cela me laisse un peu perplexe...)


Bon, je vais coller mes fichiers de configuration clients pour fournir un peu plus d'infos si cela peut rendre service.


Sur ce, Bonne Soirée !

Salutations,
HP

[jdh]

* udp vs tcp :
On ne lit pas les mêmes choses !
Sur le site d'OpenVPN (et d'autres), il est expliqué que l'encapsulation de trafic tcp dans d'autres trames tcp n'est pas optimale. La raison en est fort simple : les paquets tcp sont souvent remplis au max, donc en encapsulant il n'y a pas la place, d'où fragmentation du paquet, d'où perte de perf.
Alors que la partie data d'une trame udp permet de prendre data+entete d'un paquet tcp, d'où pas de fragmentation, d'où performance.

* tcp/443 :
On ne lit pas les mêmes choses !
Sur le site d'OpenVPN, il est détaillé comment laisser accès, sur la même ip, à un serveur https alors qu'OpenVPN écoute sur ce même port.

Le fichier de conf du serveur OpenVPN précise l'ip, le protocole et le port d'écoute. Point.
Il n'y a AUCUN lieu de bricoler une redirection ssh (-L) ! A partir de ce moment, les logs ne sont même pas à regarder puisqu'il y a quelques chose d'anormal (ce bricolage ssh).

C'est tentant de faire écouter sur tcp/443 mais il vaudrait mieux insister sur udp/1194. (J'ai un cas comme cela).

[HP77]

Voici donc les fichiers de configurqtion côté clients lors de mes essais réussis sur port 1194 :

1.1. UDP :

Code: Tout sélectionner

rport 1194
proto udp
dev tap
nobind
remote MonServeur.dyndns.com
tls-client
tls-auth ta.key 1
tls-remote server
ns-cert-type server
auth-user-pass
ca ca.crt
cert test_sme.crt
key test_sme.key
mtu-test
pull
comp-lzo
verb 4

1.2. TCP :

Code: Tout sélectionner

rport 1194
proto tcp-client
dev tap
nobind
remote MonServeur.dyndns.com
tls-client
tls-auth ta.key 1
tls-remote server
ns-cert-type server
auth-user-pass
ca ca.crt
cert test_sme.crt
key test_sme.key
;mtu-test      ;utilisation de la valeur par defaut de --tun-mtu (1400)
pull
comp-lzo
verb 4

Concernant les essais ratés :

Seul le port change : rport 443

Remarques :
- Côté serveur :

- la contribution SME installée génère tout à partir des éléments sélectionnés et fournis via une interface Web intégrée à "Server-Manager" (pour ceux qui connaissent).
- La sécurité est au niveau 4 = utilisateur doit fournir son login+pass en plus de popsséder les ses certificat et clef en complément de ceux du serveur.

- côté clients :

- Les fichiers de config sont fournis par cette même interface.
- Seuls les fichiers suivants sont requis côté clients :
- user.ovpn
- user.crt
- user.key
- ca.crt
- ta.key

Bon, je vais ajouter aussi une copie d'écran PuTTY pour la configuration côté serveur...

[HP77]

Et voilà la copie d'écran promise :

Code: Tout sélectionner

12:22 AM 1/28/2010


login as: root
root@MonServeur.dyndns.com 's password:
Last login: Tue Jan 26 21:06:58 2010 from 192.168.xxx.yyy
[root@sme7.4 ~]# elinks https://127.0.0.1/server-manager/

                                                                     Mitel Networks server manager (1/3)
SME Server


admin@MonServeur.dyndns.com                                                      ?    Logout
--------------------------------------------------------------------------------------------------------
¦                                          Advanced Configuration
¦
¦ Click here to return to the main page
¦
¦ This page is for advanced users, it allows a finer control over the daemon. Please, don't change these
¦ settings if you don't know what you're doing because the default values should be the best in most of
¦ case
¦
¦  Enter your external domain name (maybe different from your internal domain if you use something like
¦  dyndns, let empty to use your internal domain name)
¦  External domain Name:                          _________________________________
¦  Enter the name of the bridge interface
¦  Brigde Interface:                              br0______________________________
¦  Enter the name of the local interface to be bridge
¦  Local Interface:                               eth0_____________________________
¦  Enter the tap interface to be bridge
¦  Tap Interface:                                 tap0_____________________________
¦  Which transport protocol ? UDP is recommended for both performances and security but you may choose
¦  TCP for specific firewall rules of your network or if your clients access your VPN server through a
¦  HTTP proxy
¦  Protocol:                                      [tcp]
¦  Enter the local port to listen on.
¦  Port:                                          1194_____________________________
¦  Do you want to use your server as default gateway for the clients ? If set to 'enabled for everyone',
¦  all the data of the clients (even WEB data) will pass through your server. If set to 'disabled for
¦  everyone', this feature won't be used, if set to 'per user', you can choose for each user to use or
¦  not this feature via the certificate manager (only for authentication method 2 and 4)

                                                                        Mitel Networks server manager (2/3)
-----------------------------------------------------------------------------------------------------------
¦  Redirect gateway:                              [disabled for everyone]
|  Do you want to enable the lzo compression ? LZO is a real-time compression system wich can improve the
¦  performance of your VPN
¦  Compression:                                   [enabled_]
¦  Which cipher do you want to use ? Keep in mind that some ciphers are not allowed without a specific
¦  permission.
¦  Cipher:                                        [auto________]
¦  How often do you want the data channel key to be renegotiated ?
¦  renegotiation:                                 [1 hour_]
¦  Allow client to client communications ? If set to enabled, two clients connected at the same time will
¦  be able to communicate
¦  Client to Client:                              [enabled_]
¦  How many client do you want to allow at the same time ?
¦  Max clients:                                   3________________________________
¦  To empirically measure MTU on connection startup. If set to enabled OpenVPN will send ping packets of
¦  various sizes to the remote peer and measure the largest packets which were successfully received.
¦  This process normally takes about 3 minutes to complete. If set to disabled, you can specify a fixed
¦  MTU with the following parameter. If set to enabled, the fixed value will be ignored. Mtu-test only
¦  makes sens if protocol is udp, so if protocol is set to tcp, mtu-test will allways be disabled.
¦  MTU test:                                      [disabled]
¦  Take the TAP device MTU to be this value and derive the link MTU from it (default=1500). In most
¦  cases, you will probably want to leave this parameter set to its default value. The MTU (Maximum
¦  Transmission Units) is the maximum datagram size in bytes that can be sent unfragmented over a
¦  particular network path. OpenVPN requires that packets on the control or data channels be sent
¦  unfragmented. MTU problems often manifest themselves as connections which hang during periods of
¦  active usage. It's best to use the fragmentation option to deal with MTU sizing issues.
¦  MTU:                                           1400_____________________________
Select field, name redirectGW

                                                                        Mitel Networks server manager (3/3)
-----------------------------------------------------------------------------------------------------------
¦  Enable internal datagram fragmentation so that no UDP datagrams are sent which are larger than this
¦  value (in bytes, works only if the protocol is UDP, ignored if the protocol is TCP). Fragmentation
¦  adds 4 bytes of overhead per datagram. It should be noted that this option is not meant to replace UDP
¦  fragmentation at the IP stack level. It is only meant as a last resort when path MTU discovery is
¦  broken. Using this option is less efficient than fixing path MTU discovery for your IP link and using
¦  native IP fragmentation instead. If you let this empty, the directive --fragment won't be used.
¦  Fragmentation:                                 1400_____________________________
¦  Choose the common name of the local certificate to use (You have to generate it first with the
¦  certificate manager, type server). This can be usefull if your server's certificate has been
¦  compromised, but the master CA is still trusted, you can revoke the old server's certificate,
¦  regenerate a new one and your clients will trust it.
¦  Local CN:                                      [server]
¦  Change process priority after initialization (greater than 0 is lower priority, less than zero is
¦  higher priority)
¦  Nice:                                          [0__]
¦  Set output verbosity (default=1). Each level shows all info from the previous levels. Level 3 is
¦  recommended if you want a good summary of what's happening without being swamped by output.
¦  verbose:                                       [3]
¦                                                [ Apply ]
¦
¦ ---------------------------------------------------------------------------------------------------------
¦
¦ Mitel Networks server 7.4
¦ Copyright 1999-2003 Mitel Networks Corporation.
¦ All rights reserved.
¦
¦
Text field, name fragment, hit ENTER to post to https://127.0.0.1/server-manager/cgi-bin/openvpn-bridge

Sur ce, je dois vous laisser : 00h35, réveil à 5h30 (...)

Bonne soirée !

Salutations,
HP

[jdh]

Ce semble assez logique et correct ... (mais je ne connais que très mal SME et de plus je ne pense pas que le mode "bridge" soit le plus efficace versus le mode "routeur" conseillé par OpenVPN).

Les paramètres "client" doivent être en concordance avec ceux "serveur" (au besoin consulter le fichier généré par template).

côté serveur : port 1194, proto udp, server-bridge xxxx, dev tap
côté client : port 1194, proto udp, remote (adr ip publique), dev tap

(D'après ce que je comprends en mode "routeur", on utilise "tun" au lieu de "tap" et "server" au lieu de "server-bridge". Mails il faut rester dans la logique de l'addons SME sans sortir des clous ...)

Il est à noter qu'il faut faire très gaffe au MTU : je préfère ne pas y toucher ! ..

[HP77]

Bonsoir,

Je reviens un peu sur le sujet malgré que la quasi totalité du département électronique de l'établissement scolaire où je travaille a brûlé durant le weekend...
Heureusement pour moi, j'avais mon PC avec moi mais d'autres collègues n'ont pas eu cette chance...

D'où un énorme doublement de mon intérêt pour envoyer mes données sur mon serveur à la maison.

Bon, tout d'abord un remerciement à JDH qui a posté ces quelques réponses (désolé, le temps que j'ajoute mes fichiers de configuration, un message avait été posté) :

* udp vs tcp :
On ne lit pas les mêmes choses !
Sur le site d'OpenVPN (et d'autres), il est expliqué que l'encapsulation de trafic tcp dans d'autres trames tcp n'est pas optimale. La raison en est fort simple : les paquets tcp sont souvent remplis au max, donc en encapsulant il n'y a pas la place, d'où fragmentation du paquet, d'où perte de perf.
Alors que la partie data d'une trame udp permet de prendre data+entete d'un paquet tcp, d'où pas de fragmentation, d'où performance.

Dit comme ça, c'est clair.

* tcp/443 :
On ne lit pas les mêmes choses !
Sur le site d'OpenVPN, il est détaillé comment laisser accès, sur la même ip, à un serveur https alors qu'OpenVPN écoute sur ce même port.

Là, j'aimerais bien avoir la requête G**gle pour tomber dessus car je n'ai pas encore fini de lire ce que j'ai trouvé.
(mais sincèrement, si les histoires d'avoir deux serveurs OpenVPN en écoute sur deux ports différents ou encore de bricoller des interfaces réseau virtuelles sont la solution : 1°/ je doute que ce soit LA solution et car ce n'est pas trop ce à quoi je m'attendais et donc, je suis réticent, 2°/ encore plus réticent du fait que je trouve ces bricollages hors de ma portée actuellement. (sans parler que c'est du bidouillage, Ubuntu ou autre, à adapter à SME...))

Bon, je sais que je n'ai pas l'air doué mais j'ai quand même envie d'apprendre malgré des contraintes sévères (temps et connaissances ~0 et impératifs toujours plus pressants).
Je ne demande pas du tout cuit aux petits oignons, juste d'être un peu guidé sinon j'y arriverais peut-être, mais dans combien d'années...

Le fichier de conf du serveur OpenVPN précise l'ip, le protocole et le port d'écoute. Point.
Il n'y a AUCUN lieu de bricoler une redirection ssh (-L) ! A partir de ce moment, les logs ne sont même pas à regarder puisqu'il y a quelques chose d'anormal (ce bricolage ssh).

Effectivement, c'était du bidouillage mais juste "pour voir" car je n'aime pas non plus faire des redirections de ports à tout va et puis, au final, à quoi servirait d'avoir plusieurs ports dédiés (...) ?
Donc, j'ai tout remis comme c'était car je ne peux pas, actuellement accéder à mon serveur d'une manière ou d'une autre.
A ce sujet, je n'ai toujours pas compris pourquoi je n'ai jamais eu de réponse de mon serveur en lui faisant écouter SSH sur le port 443 au lieu du 22 (la redirection 443 vers 22 était suprimée).
Avec redirection TCP/443 -> 22 ça fonctionne...

C'est tentant de faire écouter sur tcp/443 mais il vaudrait mieux insister sur udp/1194. (J'ai un cas comme cela).

J'ai peut-être une possibilité UDP via un autre port utilisé par le logiciel "Altiris" (in English) mais bon, ce n'est pas garanti que ça passe par là et puis, le port 443, même si ce n'est pas optimal, il m'intéresse au cas où je ne peux pas faire autrement (nous devons laisser le campus actuel pour intégrer un "mega campus" en milieu d'année) donc, je risque de me retrouver encore une fois confronté à ce "challenge".

Juste au cas où on ne se serait pas bien compris, OpenVPN fonctionne très bien en UDP/1194 XOR TCP/1194 lorsque je ne suis pas au boulot. Une fois "dans" les murs, c'est fini. TCP/443 semble être la seule porte ouverte à exploiter (je l'utilise déjà pour SSH via une redirection de port)


Autrement, je partage également ce point de vue :

Il est à noter qu'il faut faire très gaffe au MTU : je préfère ne pas y toucher ! ..

Maximum Transmit Unit de base = 1500
S'il y a un routeur (ou "Box"), ça tombe à 1492 mais dans le cas d'OpenVPN, ne sachant pas encore le contenu ni la longueur exacts de l'entête, j'accepte une valeur aussi "basse" que 1400 ou autre "auto-determinée" dans le cas de l'UDP (su j'ai bien lu et compris ce qui est affiché dans dans l'interface de gestion côté serveur).

Bon, je vais chercher encore un peu mais pour les tests, il va falloir attendre que le réseau soit remis en fonction, les câbles ont brûlés aussi donc, plus de hot spot et cie dans le campus...


Salutations,
HP

[HP77]

Bonjour,

Un court message (pour une fois... Désolé JDH, le précédent devait être motivé par le "feu" des émotions... ) pour dire ceci :

- Le réseau est de nouveau fonctionnel au bahut depuis hier 17h, heure locale =>Tests peuvent reprendre. (on sent bien que ce n'ai pas en France que ça a brûlé... )
- Que je viens de faire un test OpenVPN en écoute TCP/443 chez moi, sans toute l'usine à gaz réseau du boulot et que le résultat est le même : "problème d'encapsulation, blablabla..."

Salutations,
HP



[edit]correction de fautes d'orthogrape, etc...[/edit]

[HP77]

Bonsoir,

Je suis toujours en train de chercher une solution mais je ne trouve pas grand chose de satisfaisant avec les mots clefs suivants :
- openvpn port 443
- openvpn port 80

(désolé si je manque d'inspiration, je suis en train de développer des drivers en C pour écrans LCD "exotiques"..)

Autrement, depuis la page de manuel fournie en résultat de ma recherche avec "443" sur le site d'OpenVPN :

Je me demande si je ne devrais pas tenter quelque chose avec --auto-proxy ou bien encore peut-être tenter une utilisation en mode "routeur" plutôt que "bridge" du serveur OpenVPN comme cet autre lien : http://actux.tuxfamily.org/Documentation/Openvpn peut le laisser penser également.


Sincèrement, je ne sais pas par quel bout attaquer mon problème..
Quant-à "bidouiller", ça va 5 minutes si on sait ce que l'on fait mais ce n'est pas mon cas actuellement.

Côté bidouille, juste pour voir le comportement : udp/443 = ça fonctionne à la maison mais pas si c'est tcp/443.

C'est quand même curieux.
Bon, si quelqu'un qui s'y connaît bien accepte de me mettre sur la bonne voie, ne serait-ce que par le biais d'un cours ou quelque chose comme ça, ce serais bien sympathique.

Je demande simplement une aide pour comprendre comment ça marche et ensuite pour pouvoir m'orienter moi-même dans les actions à entreprendre car un manuel d'options ne renseigne pas sur tout et, généralement, pas sur les bases requises....


Sur ce, Merci de m'avoir lu jusqu'ici et Bonne Soirée.

Salutations,
HP

[jdh]

Je ne comprends pas bien :

- changement de proto et de port :
il faut le faire sur le client et sur le serveur (=en même temps ou presque !), puis redémarrer le service : on fait rarement 5 essais dans la journée !

- mode routeur/mode bridge :
l'addons pour SME est basé (conçue ?) sur le mode bridge, je vois mal comment le reconfigurer en mode routeur, mais j'ai créé des serveurs vpn sur base Debian puis pfSense, et j'ai forcément choisi le mode routeur.

- il ne faut pas s'attendre à des débits merveilleux avec une ligne ADSL :
en général, on a 512 kb montant soit 50 ko/s qui vont d'abord être cryptés ...

[HP77]

Bonsoir JDH,

Je te remercie d'avoir conservé un peu d'intérêt pour ce fil de discussion.

Je ne comprends pas bien :

- changement de proto et de port :
il faut le faire sur le client et sur le serveur (=en même temps ou presque !), puis redémarrer le service : on fait rarement 5 essais dans la journée !

Bon, il me semble nécessaire de remettre tout à plat :

- Serveur SME7.4 en mode 'Server & Gateway'
- OpenVPN server en mode Bridge via la contribution suivante : [url]fsdfdsfs[/url]
- Clients WinXP avec OpenVPN GUI
- Configuration du serveur 100%(?) automatisée via une interface Web ajoutée par la contribution à la panoplie 'Server-Manager'
- Fichiers .ovpn pour les clients sont générés aussi par cette interface Web, juste faire du copier-coller (ça c'est sympa pour le "vite-fait" pour démarrer "simplement")

- Les changements de port, protocoles et redémarrage du serveur sont gérés eux aussi par l'interface Web disponible sur le serveur SME.
- Le changement des de ces mêmes paramètres côté client(s) se fait à la mano via "(un)comment" :

Code: Tout sélectionner

rport 443 ;1194
proto tcp-client ;udp
;mtu-test



- déconnecter puis reconnecter le client (via OpenVPN GUI)
- essais réalisés à la maison via liaison Wi-Fi entre PC portable et la "Box".
- Configuration réseau adoptée il y plus d'un mois et qui ne devrait plus changer :

Code: Tout sélectionner

{Internet}---["Box" :  DMZ]---[WAN SME Server 7.4 ; @IP=publique]
             ["Box" : WLAN]---{plage @IP= 192.168.aaa.xxx}
             ["Box" :  LAN]---{plage @IP= 192.168.aaa.xxx}

             [SME Server 7.4 : LAN]---{plage @IP= 192.168.bbb.xxx}

{WLAN_BOX : plage @IP= 192.168.aaa.xxx}---[PC client ; série de tests 1]
{ LAN_BOX : plage @IP= 192.168.aaa.xxx}---[PC client ; série de tests 2]
{Internet}---[PC client ; série de tests 3]
{Internet}---[WAN : Equipements réseau de l'école : (W)LAN]---[PC client ; série de tests 4]


- Les PC clients ayant servi aux tests étaient reliés soit par câble ou WiFi aux (sous?-)réseaux de la "Box".
- La DMZ à usage dédié à une seule machine / NIC de la "Box" isole la DMZ de son LAN et WLAN (information fournie par le fabricant, contacté lors de mes débuts avec cette "DMZ+" ciomme il l'appelle)
- "Box" de marque 2wire
- Port Forfarding sur Serveur SME = TCP/443=>127.0.0.1:22

En listant tous ces points, je ne me souviens plus si mes essais en cyber-café / coffe-shop et cie portaient sur OpenVPN ou SSH seul via le port 443.

Je vais tenter de refaire un essai OpenVPN hors de chez moi et du boulot pour voir s'il n'y aurait pas un cafouillage au niveau de la "Box", maintenant que j'ai un doute.

Si jamais j'ai une tuile à cause de la "Box", que pourrais-je tenter de faire à part me lancer dans "IPsec" ou le "PPTP" (pour ces deux là, je parts du zéro absolu...)

Tiens, une question me vient :
- Est-ce nécessaire de laisser activer l'option "PPTP" sur mon serveur (N clients) alors que j'utilise OpenVPN ??
- A quoi cela peut-il me servir autrement ??

- mode routeur/mode bridge :
l'addons pour SME est basé (conçue ?) sur le mode bridge, je vois mal comment le reconfigurer en mode routeur, mais j'ai créé des serveurs vpn sur base Debian puis pfSense, et j'ai forcément choisi le mode routeur.

Dans mon cas, j'ai cherché une solution VPN clef en main pour SME et je suis tombé sur une version "bridge" mais ça aurait pu être tout aussi bien une version "routeur" et dans ce cas, ça donnerait du sens au fait que l'on lise qu'il faut deux sous-réseaux différents (ex: SME = 192.168.bbb.xxx et celui du client en 10.71.ccc.xxx)

Je suppose que le nettoyage de la version "bridge" est impératif pour exclure tout interférence avec la version "routeur" si je veux mener des tests "proprement".

- il ne faut pas s'attendre à des débits merveilleux avec une ligne ADSL :
en général, on a 512 kb montant soit 50 ko/s qui vont d'abord être cryptés ...

Ca, c'est sûr !
Pas de souci, je ne m'attends pas au performances GigaBit de mon LAN SME ni même 100Mbps de la "Box".
Pour info, en local via un câble, l'interface TAP de mon PC client WinXP relié à la "Box" (100Mbps) indique un débit maxi de 10Mbps, ce qui n'est déjà pas si mal pour travailler sur des fichiers .c, .h, .txt et cie....


Sur ce, à plus tard !
Bonne soirée !

Salutations,
HP


[edit]
P.S.
Est-ce qu'un PortForwarding UDP/443=>127.0.0.1:1194 aurait du sens ou bien, sommes-nous d'accord que seul TCP/443 est le plus communément autorisé (après TCP/80) ?
Cela n'a PAS fonctionné chez moi. (je viens de faire un test chez moi, on dirait que le port 443, TCP ou UDP ne donne rien de bon. )
(bien sûr, à prendre en compte dans l'épluchage des logs... )
[/edit]

[HP77]

Bonjour,

J'ai pu refaire quelques essais depuis un lieu public hier soir, les résultats sont les suivants :

- UDP/1194 : OK => au moins, la "Box" ne semble pas coupable des problèmes évoqués précédemment.
- UDP/443 : HS
- TCP/443 : HS
- TCP/1194 : HS ; un truc bizarre s'est produit : plus de SSH ni accès à Server-Manager en local lorsque de retour à la maison.


Je vais refaire les mêmes tests ce matin pour être sûr que je n'ai pas eu une "m**de" à retardement avec la "Box" car j'ai dû la rebooter après plus de deux mois en "coupant le jus" la semaine dernière (le WiFi était foireux.)

Salutations,
HP