Toujours à mon habitude, j’essaye d’utiliser ce qu’a fait Debian pour moi. Point de compilation, de création de machin-bidule à la main lorsque ce n’est pas une absolue nécessité.

Pour le contexte, on va dire que le VPN va être installé sur une machine de type passerelle Internet-LAN. Pourquoi pas une Debian avec shorewall et 2 pattes : loc, net (et $FW of course). Je parlerai rapidement des modifications de firewall à la fin. Vous pouvez trouver une introduction à shorewall sur ma doc d’initiation à Debian.

Je vais développer en 3 parties : thèse, anti-thèse, foutaises, comme disait mon prof de philo au siècle dernier installation, paramétrage du serveur, paramétrage du client, firewalling. Ca fait 4 ? bien, au moins y’en a qui suivent.

Let’s go.

Installation de l’outil

Ca devient presque rasoir, on commence direct dans le feu de l’action :

aptitude install openvpn

Tout descend par dépendances, comme d’habitude.
Je n’ai pas pris de notes, mais je pense qu’à ce niveau là déjà, une interface réseau « tun0″ est créée. Le futur sous-réseau du VPN est 10.0.8.x. Le serveur n’est pas lancé car il n’a aucune conf. Ca veut dire /etc/openvpn/ vide ou pas loin. Et c’est tant mieux.

Paramétrage serveur

Rappel : permissions

On va jouer avec les clefs cryptées et les clefs publiques d’un outil donnant accès à l’intérieur de votre réseau. Faites un peu attention aux permissions des fichiers.

Clef privée = permission limitée au niveau de l’OS, root:root + chmod 600
Clef publique = root:root + chmod 644
Ce qui ne concerne que le service et son lancement = root:root + chmod 640

Notez que le service openvpn sera lancé par root même s’il tournera au nom d’un utilisateur « openvpn ».

Traditionnellement, les clefs privées ont un nom en .key, les certificats publics en .crt.
Notez bien les permissions de votre conf OpenVPN lorsqu’on l’aura monté et gardez ça à l’esprit tout le long :

serveur:/etc/openvpn# ls -l
total 40
-rw-r--r-- 1 root root  1176 2009-09-14 14:46 ca.crt
-rw------- 1 root root   245 2009-09-14 14:47 dh1024.pem
-rw------- 1 root root    16 2009-09-23 08:23 ipp.txt
-rw------- 1 root root   232 2009-09-23 08:32 openvpn-status.log
-rw-r----- 1 root root 10560 2009-09-22 17:02 server.conf
-rwxr-xr-x 1 root root  1352 2008-09-18 00:33 update-resolv-conf
-rw-r--r-- 1 root root  3813 2009-09-14 14:46 vpnserveur.crt
-rw------- 1 root root   887 2009-09-14 14:46 vpnserveur.key

En résumé, seules la clef publique de l’autorité de certification et la clef publique du serveur doivent être publiques.

Présentation rapide de easy-rsa

« easy-rsa » est un ensemble de scripts simplifiant votre vie pour gérer les certificats. Que ce soient ceux du serveur pour créer sa configuration ou ceux de vos postes clients.
Vous savez aussi sans doute qu’il vous faudra gérer votre base de certificats autorisés (et surtout révoqués). Lorsque le portable de votre collègue est oublié dans le train, il est intéressant d’être mis au courant dans la seconde pour révoquer le certificat en question. Sinon c’est la porte d’entrée dans l’entreprise, suivant le profil du voleur type qui a trouvé le portable.
Cet outil descend avec OpenVPN et l’ensemble des scripts se situe dans /usr/share/doc/openvpn/examples/easy-rsa/2.0/. Il y a une version 1.0. J’ai opté pour la 2.0. Je ne me suis pas trop documenté sur le sujet.

Il y a un tout petit peu de paramétrage à faire sur easy-rsa.
Je recommande de dupliquer le fichier /usr/share/doc/openvpn/examples/easy-rsa/2.0/vars en /usr/share/doc/openvpn/examples/easy-rsa/2.0/vars.maconf et de travailler dedans.
Je vous montre un « diff » entre le fichier d’origine et le mien. C’est le minimum syndical à renseigner :

serveur:/usr/share/doc/openvpn/examples/easy-rsa/2.0# diff -h vars vars.maconf
64,68c64,68
< export KEY_COUNTRY="US"
< export KEY_PROVINCE="CA"
< export KEY_CITY="SanFrancisco"
< export KEY_ORG="Fort-Funston"
< export KEY_EMAIL="me@myhost.mydomain"
---
> export KEY_COUNTRY="FR"
> export KEY_PROVINCE="France"
> export KEY_CITY="Petaouana"
> export KEY_ORG="MaBoite"
> export KEY_EMAIL="adminvpn@maboite.fr"

Notez : pour utiliser les scripts Easy-RSA, il faut à chaque fois positionner les variables d’environnement du fichier vars.maconf. Donc, à chaque nouvelle session dans laquelle vous jouez avec les scripts easy-rsa, il faudra commencer par la commande suivante :

. /usr/share/doc/openvpn/examples/easy-rsa/2.0/vars.maconf #sans oublier le point au début !!!

.

Le répertoire où sont stockées les clefs générées (et d’autres choses, liste de certificats, certificats révoqués etc) est le sous-répertoire keys/. Inutile de préciser (?) que ce répertoire doit être archi-protégé :

serveur:/usr/share/doc/openvpn/examples/easy-rsa/2.0# ls -ld keys
drwx------ 2 root root 4096 2009-09-14 18:22 keys

Enfin, la première fois uniquement (ou tant que vous testez), vous pouvez nettoyer ce répertoire via la commande ./clean-all.

Création de l’autorité de certification

Maintenant que vos « variables » sont prêtes et chargées dans votre session, on attaque.
Bien évidemment, cette manip n’est à faire qu’une fois. Seule la manip de création de certificats pour vos clients (postes clients) sont à faire X fois.
L’autorité de certification est « un nom et des clefs » signant vos certificats. Un exemple connu est Verisign. Ici, on va signer nous-même. Sur un serveur web, ça ferait des warnings de certificats bidouilleux, ici on s’en fout.

./build-ca

Vous obtenez le baratin standard de génération de clefs, lisez ce qui y est dit et renseignez le « Common Name ». Le reste doit descendre du fait du fichier « vars » chargé au préalable. Pour « Common Name », mettez le nom de votre serveur.

Création de la clef Diffie-Hellman

La clef Diffie-Hellman est une clef permettant au client et au serveur de s’entendre sur une clef secrète pour crypter la conversation.
Si je me souviens bien, les clefs publiques/privées servent à l’initialisation de la communication, mais, étant lourdes en calculs, on opte pour un cryptage plus simple pour le reste de la communication. C’est la clef DH. En gros hein. Et pardon aux puristes. Ou dites moi si je me trompe complètement.

On la génère comme suit, grâce aux script Easy-RSA :

./build-dh

Rien à saisir, ça prend juste un peu de temps.

Génération du certificat serveur

On continue, pour le dernier élément du serveur : sa propre clef.

./build-key-server

(trop cool les scripts Easy-RSA non ?)
Ca sort aussi le baratin standard de génération de clefs. Vous devrez préciser le « Common Name », éventuellement un mot de passe (je ne l’ai pas fait, je suppose qu’il demanderait du coup un mot de passe au lancement du service openvpn ; ça peut être contraignant lors de reboot).
Par défaut, votre certificat sera valable 10 ans.
Ca termine par l’inscription du certificat dans la « base » :

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Création des certificats d’un client

Rappel : lorsque plus tard, vous créerez un autre certificat pour un autre PC, pensez à « sourcer » le fichier vars.maconf.
Le script de génération se lance comme suit :

./build-key pc123

Je suggère un nom éloquent rappelant ou bien le PC, ou bien la personne.
Là non plus, rien de sorcier : le « Common Name » sera le nom du PC et vous « committez » le certificat.

Création des certificats d’un client avec mot de passe

Tout pareil que le paragraphe du dessus, mais le script est ./build-key-pass pc123
Il faudra alors renseigner le mot de passe là :

Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

Rien à voir avec le « Challenge password » demandé plus tard.

La révocation de certificats

Si à ce niveau là de la configuration on n’a pas besoin de révoquer des certificats, ça deviendra obligatoire à mesure que les utilisateurs arriveront, partiront et perdront leur PC portables. Evidemment que c’est du vécu
La commande Easy-RSA est :

./revoke-full pc123

Il faut copier le fichier résultant, après chaque révocation :

cp keys/crl.pem /etc/openvpn/

Ce fichier est lu dès l’instant que vous avez mis en place l’option « crl-verify » dans votre fichier de conf serveur (voir plus haut).
Notez aussi qu’il est relu à chaque tentative de connexion. Pas besoin de recharger OpenVPN après une révocation. Juste de recopier le fichier à jour. Si vous pensez faire un lien symbolique, attention aux permissions (c’est l’utilisateur openvpn qui fait tourner openvpn). Je n’ai pas testé la solution par lien symbolique.

Vous pourrez consulter la liste des certificats révoqués grâce à la commande :

openssl crl -in /chemin/vers/keys/crl.pem -text

CRL = Certificate Revocation List

Lancement du service

A ce niveau là, on a généré tout ce qu’il faut, mais le service ne tourne pas.
Le contenu de votre sous-répertoire keys ressemble à ça :

serveur:/usr/share/doc/openvpn/examples/easy-rsa/2.0# ls -l keys/
total 80
-rw-r--r-- 1 root root  3813 2009-09-14 14:06 01.pem
-rw-r--r-- 1 root root  3698 2009-09-14 14:29 02.pem
-rw-r--r-- 1 root root  1176 2009-09-14 14:03 ca.crt
-rw------- 1 root root   887 2009-09-14 14:03 ca.key
-rw-r--r-- 1 root root  3698 2009-09-14 14:29 client_test.crt
-rw-r--r-- 1 root root   668 2009-09-14 14:29 client_test.csr
-rw------- 1 root root   887 2009-09-14 14:29 client_test.key
-rw-r--r-- 1 root root   245 2009-09-14 14:32 dh1024.pem
-rw-r--r-- 1 root root   205 2009-09-14 14:29 index.txt
-rw-r--r-- 1 root root    20 2009-09-14 14:29 index.txt.attr
-rw-r--r-- 1 root root    21 2009-09-14 14:06 index.txt.attr.old
-rw-r--r-- 1 root root   101 2009-09-14 14:06 index.txt.old
-rw-r--r-- 1 root root     3 2009-09-14 14:29 serial
-rw-r--r-- 1 root root     3 2009-09-14 14:06 serial.old
-rw-r--r-- 1 root root  3813 2009-09-14 14:06 vpnserveur.crt
-rw-r--r-- 1 root root   664 2009-09-14 14:05 vpnserveur.csr
-rw------- 1 root root   887 2009-09-14 14:05 vpnserveur.key

On y retrouve les clefs de l’autorité de certification (ca*), le certificat serveur (vpnserveur.crt et vpnserveur.key) et un futur poste client (client*.[crt|key]). Les fichiers .csr sont les demandes de signatures, étape intermédiaire de la création des certificats, masquée par l’enrobage de commandes d’Easy-RSA. Inutile par la suite
Il faut recopier (avec les bonnes permissions !!!) les fichiers suivants :

cp -p dh1024.pem vpnser*crt vpnser*key ca* /etc/openvpn

Ensuite, on va faire tourner le service sous un utilisateur/groupe sans droit, c’est mieux côté sécurité.

groupadd openvpn
useradd -d /dev/null -g openvpn -s /bin/false openvpn

Enfin, il faut créer le fichier de conf du serveur. Un exemple est donné dans le fichier /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz. Une fois dézippé et mis dans /etc/openvpn, on l’adapte.
Voici son contenu, sans les commentaires :

serveur:/etc/openvpn# egrep -v "^$|^#|^;" server.conf
port 1194
proto udp
dev tun
ca ca.crt
cert vpnserveur.crt
key vpnserveur.key  # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.X.0 255.255.255.0"
push "dhcp-option DNS 192.168.X.Y"
push "dhcp-option DOMAIN maboite.net"
push "dhcp-option WINS 192.168.X.Y"
keepalive 10 120
comp-lzo
user openvpn
group openvpn
persist-key
persist-tun
status openvpn-status.log
verb 3
;crl-verify crl.pem # j'ai triché, j'ai ajouté le ";" il n'aurait pas dû sortir vu la commande egrep passée. Voir ci-dessous.

Les 4 paramètres push route et push dhcp-option sont à adapter. Ce sont eux qui feront ajouter à votre PC client les règles de routages et DNS, domaine (et optionnellement WINS) à utiliser. Sinon, point de résolution de nom, point de routage depuis votre PC, tantôt vers sa connexion web, tantôt vers le VPN.
Suivant la configuration de votre passerelle, le simple ajout de ces push ne sera pas suffisant pour permettre à vos postes client VPN de rebondir de votre passerelle vers le LAN. Voir plus bas le chapitre dédié.
Enfin, le paramètre « crl-verify » prendra son importance avec les révocations de certificats (voir plus bas).Pour l’instant, il est en commentaire car j’ai noté que OpenVPN plantait (volontairement ?) lorsqu’on lui dit de tenir compte d’une liste de révocation et que cette liste n’existe pas, ou est un fichier vide. Ce sera donc à activer plus tard, après votre première révocation.

Ah, j’oubliais :

/etc/init.d/openvpn start

Vérifiez dans les logs que tout va bien. Et ifconfig qui doit avoir affecté une IP à tun0, probablement 10.8.0.1.

Paramétrage client (poste Windows dans mon cas)

On a généré un premier ensembles de clefs d’un poste client.
Dans le cas d’un PC sous Windows (cas à mon avis le plus courant lorsqu’il s’agit de fourni des portables d’appoint à des utilisateurs distants), installez OpenVPN avec le GUI.
Injectez (par un moyen sûr, éviter d’envoyer la clef cryptée par mail à votre destinataire) les fichiers suivants dans le répertoire C:\Program Files\OpenVPN\config :

ca.crt # et pas le .key !!!
client_test.key
client_test.crt

Puis créez un fichier de configuration client nommé nimportequoi.ovpn dans le même sous-répertoire config. Il contiendra la conf suivante, si on oublie les commentaires :

client
dev tun
proto udp
remote votre.serveur.vpn.votresociete.fr 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client_test.crt
key client_test.key
comp-lzo
verb 3

Enfin, lancez le GUI d’OpenVPN situé dans le sous-répertoire bin/ d’OpenVPN, bouton droit dans le « system tray » sur l’icône qui vient d’apparaitre, menu « Connect » et lisez ce qui passe pour commencer à débugger s’il y a un hic niveau réseau entre le PC portable et le serveur VPN. Attention à vos règles de firewalling en vigueur, que vous testiez de l’extérieur ou de l’intérieur (ce qui semble un peu stupide), vous pourriez ne pas être en mesure d’atteindre le service, d’où le chapitre ci-dessous.

Considérations de firewalling

Bon là, c’est bien beau, vous atteignez votre serveur VPN depuis l’extérieur, et encore, si vous avez bien ouvert la porte d’entrée vers le port UDP 1194 de votre serveur.
Mais pour l’instant, point de rebond vers le LAN. Et heureusement que ça ne marche pas par défaut.

Méthode gore pour tester vite fait

En activant l’IP Forwarding à la main et en définissant quelques routes entre votre réseau VPN et votre LAN, vous obtiendrez vite fait un résultat. Mais c’est pas terrible je trouve.
Activation de l’IP Forwarding comme un cochon :

echo 1 > /proc/sys/net/ipv4/ip_forward

Puis définition de routes. Plutôt que de donner un exemple qui ne sera pas le votre, tâchez plutôt de raisonner sur la liste des routes que vous avez et ajoutez celles qu’il faut, avec les commandes route, route add et route delete.

Méthode réfléchie pour shorewall

Si vous utilisez iptables, je ne peux rien pour vous. Enfin si, un conseil : songez à utiliser shorewall.
Si vous ne connaissez rien à shorewall, c’est le moment de vous y mettre. Mais dans ce cas, faites vous la main *avant* d’installer le VPN, quand même. Voyez ma doc Debian au besoin, il y a un chapitre consacré à shorewall.
Sinon, dans une conf shorewall à 2 pattes (net, loc), on la modifie pour qu’elle passe à 3 pattes. Dans un cas idéal (mais néanmoins courant), ça se passera comme ça :

• Ajout de la ligne vpn ipv4 dans /etc/shorewall/zones.
• Ajout de la ligne vpn tun0 detect dans /etc/shorewall/interfaces
• Ajout de la ligne eth0 tun0 dans /etc/shorewall/masq pour activer le Masquerading entre votre VPN et votre LAN, ici situé sur l’interface eth0
• Ajout de toutes les règles par défaut dans /etc/shorewall/policy, concernant la probable interdiction par défaut d’aller de n’importe quelle zone vers le VPN et réciproquement. Le VPN doit en effet, à mon avis, être un moyen de secours pour donner accès à quelques services internes, pas à tout le LAN. A base de vpn loc REJECT info + réciproque.
• Enfin, le vrai travail, l’ouverture du minimum d’autorisation entre toutes vos zones et le VPN. J’y consacre le paragraphe suivant.

Ouvertures minimum sur le firewall

En considérant net=eth1 ; loc=eth0 et vpn=tun0, voici ce qu’il faudra ajouter au minimum, à mon avis :
Déjà l’accessibilité du service VPN depuis le NET :

ACCEPT          net     $FW         udp     openvpn

Ensuite des règles du VPN vers le LAN :

ACCEPT          vpn     loc:$dns1      tcp     domain # sinon on ne touche pas le serveur DNS => pas de résol de nom => problème...
ACCEPT          vpn     loc:$dns1      udp     domain # je ne sais pas s'il faut le TCP ou l'UDP. Oops.
Ping/ACCEPT     vpn     loc # pratique pour du dépannage
ACCEPT          vpn     loc:$leserveurapplicatif1 # c'est un exemple
ACCEPT          vpn     loc:$leserveurapplicatif2 tcp 80 # un exemple plus restreint, limité au port http

Les variables « $dns1″ (par exemple), sont à définir dans /etc/shorewall/params, ou alors vous tapez l’IP en dur.

Et enfin quelques accès minimums vers la passerelle elle-même :

Ping/ACCEPT     $FW     vpn # pratique pour les tests
SSH/ACCEPT      vpn     $FW # pour les admins tout au moins ?
ACCEPT          vpn     $FW     tcp     80 # s'il y a des intranets à consulter (outil de supervision, par exemple)

A noter aussi, pour le Masquerading, de forcer l’activer (valeur « On ») ou de laisser tel quel (valeur « Keep ») l’IP forwarding. Ca se passe dans /etc/shorewall/shorewall.conf, paramètre IP_FORWARDING.
Il me semble que c’est ce paramètre qui force ou pas la modification du paramètre noyau /proc/sys/net/ipv4/ip_forward. Il me semble.

Voilà. Ca devrait marcher.
Evidemment, comme c’est fortement lié à toute votre infrastructure réseau, tout ce qui précède est plutôt un guide des trucs-à-pas-oublier-pour-que-ça-marche.

Divers

Ce que je n’ai pas abordé

• Testez avant de déployez !!!! notamment les certificats révoqués, et avec eux la CRL et l’option crl-verify.
• Il y a une notion de règles de routages paramétrables par certificat client. Ca peut être utile.
• Vous utilisez Orange Business Everywhere pour votre clef 3G ? attention, ça semble intercaler un proxy sur votre Internet Explorer. Résultat, l’accès à des Intranets via le VPN ne marchait pas. Firefox passait bien. Je n’ai pas creusé plus pour l’instant.

Comportement lors d’une connexion avec un certificat révoqué

Côté serveur, on voit cette discrète ligne dans /var/log/syslog :

Sep 23 11:57:49 gw ovpn-server[24224]: 192.X.Y.Z:1120 CRL CHECK FAILED: /C=FR/ST=France/L=Petaouana/O=SOCIETE/CN=pctest/emailAddress=adminvpn@chezmoi.fr is REVOKED

Côté client, c’est moins flagrant, on tourne en rond et tente de se reconnecter.
Peut-être qu’en montant le niveau de verbosité (paramètre verb), on en saurait plus. Mais à la limite, ça intéresse qui ? (à part l’utilisateur qui s’est fait révoquer son certificat par erreur).

=> Aujourd’hui, j’en parle pour bloquer cette saloperie d’outil qui peut apporter de gros ennuis au boulot

Pour rappel, c’est un VPN « zero-conf » qui permet à l’utilisateur nullissime en informatique (c’est-à-dire que vous n’avez rien besoin de connaître en info pour installer/utiliser ce truc) d’installer un VPN pour atteindre ses copains au boulot ou son PC chez lui. Au-delà de ça, ça peut rapidement se transformer en une passerelle entre un réseau bien sale (celui de l’utilisateur lambda chez lui, nul en informatique je le rappelle) et votre entreprise. D’où problèmes. D’où envie de donner des baffes.

Voici comment le bloquer (du moins maintenant il ne passe plus à mon boulot et pourtant il essaye – donc je dois avoir fait le tour de la question), tant au niveau shorewall – si l’accès Internet est direct – qu’au niveau squid si vos utilisateurs *doivent* passer par le proxy pour atteindre Internet.

Analyse à 2 balles du comportement de hamachi pour mieux le bloquer

Au départ, installez hamachi pour tester. Ca devrait se connecter sans problème. Je pense qu’il va chercher la conf proxy dans les paramètres de IE.
C’est typiquement le genre d’outils qui a prévu tout un tas de modes de connexions genre :
- essayer tout un tas de ports standards
- avoir plein de noms de machines pour atteindre le serveur par plusieurs chemins

MAIS, comme c’est un outil avec un point central (le serveur chez eux pour s’authentifier – puisque ça a une vocation commerciale, payante, tout ça), on peut à un moment donné repérer tous les serveurs centraux et les bloquer. C’est pas comme pour des protocoles décentralisés type peer-to-peer.
Bon après, s’ils changent leurs noms ou IP tout le temps, ça peut devenir pénible.

Une fois connecté, allez voir vos logs squid, vous devriez voir tout un tas de requêtes du style :

1221661590.889 350758 votre.ip.sur.lan TCP_MISS/200 3734 CONNECT ssl-24.hamachi.cc:443 - DIRECT/74.201.74.26 -

De là, avec quelques commandes hosts, genre :

for i in `seq -f '%02g' 1 40`
do
host ssl-$i.hamachi.cc
done

Ainsi que :

for i in `seq 1 255`
do
host 74.201.74.$i
done

Ce qui donne :

...
103.74.201.74.in-addr.arpa domain name pointer ns3.3amlabs.com.
104.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
105.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
106.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
...

Vous verrez qu’en gros, la plage IP 74.201.74.0/24 est à eux et qu’avec 4/5 noms de domaines génériques, vous pourrez tout bloquer.

Blocage niveau shorewall

En considérant que votre shorewall fonctionne bien, vous pouvez soit blacklister dans le fichier /etc/shorewall/blacklist (si vous avez bien activé l’option « blacklist » dans le fichier /etc/shorewall/interfaces), soit faire une règle dans /etc/shorewall/rules.
Dans « blacklist », ajoutez la ligne :

74.201.74.0/24

Ou, dans « rules », ajoutez :

DROP    lan     net:74.201.74.0/24      all

Relancez shorewall via /etc/init.d/shorewall reload

Blocage niveau Squid

Allez dans le fichier /etc/squid/squid.conf et à l’endroit où sont définies des « ACL », ajoutez celles-ci – c’est un exemple à adapter.

acl tout_mon_lan src 172.16.0.0/255.255.0.0
acl vilain_hamachi dstdomain .hamachi.cc .logmeinhamachi.com .logmein.com .3amlabs.com logmeinrescue.com logmeinrescue-enterprise.com
http_access deny tout_mon_lan vilain_hamachi

Ici je me base sur les noms de domaines, pas les IP. C’est un choix motivé par le fait que le client hamachi semble tenter des noms de machines, pas des IP. A voir si l’éditeur fait évoluer ça dans le temps.
Et pensez à recharger squid : /etc/init.d/squid reload

Validez que ça ne marche plus

Retestez la connexion à Hamachi. Vous devriez le voir s’exciter dans les logs squid sur quelques ssl-xx.hamachi.cc pris au hasard puis plus rien :

1221666080.309      0 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-14.hamachi.cc:443 - NONE/- text/html
1221666199.615      0 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-15.hamachi.cc:443 - NONE/- text/html
1221666283.816      5 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-13.hamachi.cc:443 - NONE/- text/html

En images, ça reste sur ça :

Accéder à l’interface réseau virtuelle

OpenVPN 2.0 ne permet pas d’exploiter la carte virtuelle si vous n’êtes pas admin, d’après ce que j’en comprends vu la remarque sur la version 2.1 sur le site :

TAP-Win32 adapter can now be opened from non-administrator mode

En fait sur ce sujet, avec OpenVPN 2.0, je ne sais plus si j’avais simplement un problème pour accéder à l’interface virtuelle ou pour créer des « routes » ou les 2. J’ai opté pour la 2.1 RC7 (et tant pis si ce n’est pas la finale).

Pour résoudre à coup sûr ce problème, utilisez la version 2.1.

Ajouter des « routes »

Une fois que l’utilisateur sans droit est capable de lancer l’openvpn, vous vous chopez des erreurs sur vos routes ajoutées dans la conf de votre VPN histoire que tout ce petit monde communique avec le reste de votre infra. En effet, sous Windows, le « add route » est réservé à l’admin… ou plus simplement aux personnes du groupe « Opérateurs de configuration réseau ».
Donc ajoutez vos utilisateurs sans droits là-dedans. Ils ne seront pas admin complet mais pourront déjà abîmer leur configuration réseau…

Impossible d’écrire des logs par le GUI

Si vous avez cette erreur, pensez à donner les droits d’écriture sur tout le répertoire C:\Program Files\OpenVPN\log, pour tout le monde, ou, moins bourrin, pour votre utilisateur.
Notez : le GUI OpenVPN est intégré à OpenVPN 2.1 maintenant. Ce n’est pas le cas avec le package 2.0

Cette fois, c’est bon, votre utilisateur presque-sans-droit peut faire du VPN et massacrer involontairement votre LAN depuis chez lui… :/

Au fait à quoi ça sert ? En gros un VPN à la maison, ça sert en général à des groupes d’amis un peu geeks voulant vraiment avoir leur VPN flottant au-dessus d’Internet pour s’échanger des fichiers facilement, avoir leurs réseaux fermés de je ne sais quoi.

Si maintenant on imagine que ce réseau fermé est – exemple tout à fait au hasard – un serveur de jeu que vous voulez rendre accessible comme si vous étiez en LAN, alors que vous êtes sur Internet, certains trouveront cet outil complètement génialissime. Va savoir pourquoi…
Enfin, si j’ai choisi Hamachi, c’est parce-que VOUS êtes quelqu’un aimant un peu l’informatique (sinon vous ne liriez pas cet article) et que vos amis joueurs sont des buses en informatique (cas classique). Ainsi, si vous leur demander d’installer un client VPN hyper compliqué, vous n’êtes pas près de jouer…

En relisant, je vois que l’article est long. Comme quoi, « zero-conf » <=> beaucoup d’explications. Allez, visite guidée.

Je vais décrire ce cas : un serveur de jeu (quel qu’il soit) sur un Linux, configuré pour un LAN, que je souhaite rendre accessible sur Internet à mes amis via ce VPN (donc comme si j’étais en LAN). Je vais donc vous expliquer trois choses. Premièrement : comment installer le client sur Linux et créer votre réseau d’amis. Deuxièmement : comment installer le client sur Windows et rejoindre votre réseau. Enfin, tout au long de la doc, quelques considérations de sécurité, des concepts derrière Hamachi etc.
Notamment, si je ne parle pas de serveur Hamachi, c’est parce-qu’il n’y en a pas. Si j’ai bien tout compris, la mise en relation des utilisateurs (vous et vos amis) entre eux passe à un moment donné par un point central (chez l’éditeur d’Hamachi je suppose). Mais ce n’est pas pour autant ques tous les utilisateurs du VPN Hamachi peuvent se voir (il faut se donner l’accord mutuel). C’est un peu la seule solution pour rendre le tout « zero-conf ». Ensuite, les transferts passent en direct évidemment.

La plupart des trucs que je raconte sort des README et de la doc d’Hamachi, mais comme vous ne le lisez pas (ou que vous ne comprenez rien à l’anglais) et que, même en ayant lu tout ça, ça reste un peu opaque sans pratiquer, je vous commente la chose avec un exemple de bout en bout.

J’oubliais : ce n’est pas opensource mais c’est gratuit dans la limite de création de réseaux de 16 personnes (je crois).

Enfin, si vous voulez comprendre le principe avant de mettre en place, survolez tout l’article avant d’envoyer la purée

Les différences entre Hamachi Linux et Windows sont :

- Sous Linux, il n’y pas d’interface graphique pour Hamachi

- Sous Linux, il faudra créer votre brin VPN à la main (3/4 commandes à recracher telles quelles)

- Sous Linux, il faudra balancer 3/4 commandes (simples) pour créer votre « compte » et votre réseau

- Sous Windows, tout cela sera graphique et automagique

- Sous Windows, vous faites tourner des serveurs de jeux vous ? Je serais surpris. Ben zappez la partie Linux dans ce cas.

Le principe d’Hamachi (valable pour Linux et Windows) :

Vous allez vous créer un compte, identifié par une couple de clef de cryptage (pensez à les sauvegarder si vous réinstaller votre PC ou votre serveur Linux). Vous vous donnerez un surnom et le système Hamachi vous donnera une IP privée (de la plage 5.x.y.z) qui vous caractérise sur le VPN. En fait, tous les utilisateurs Hamachi sont plus ou moins tous le même VPN (puisqu’on a tous une IP 5.x.y.z qu’on ne contrôle pas et puisqu’on passe à un moment par un serveur Hamachi pour se connecter etc).
Sauf que, histoire que ce ne soit pas une poubelle géante (un réseau interconnectant des gens entre eux qui ne le souhaitent pas), vous ne pouvez pas communiquer avec une IP 5.x.y.z (qu’elle corresponde ou non à un compte Hamachi) si vous ne faites pas partie d’un « réseau » (sorte de channel sur IRC si on voulait comparer – ou une chatroom à la limite), réseau protégé par un mot de passe et pour lequel n’existe aucune liste mentionnant son existence.
En gros, si votre réseau s’appelle chezmoionsamuse, que le pass n’est pas trop bidon, il n’y a aucune chance qu’un intrus vienne vous perturber par hasard (je suppose). Si vous voulez vous en convaincre, finissez de mettre en place le bazar et essayez des ping sur des IP au hasard, ou mieux, sur l’IP 5.x.y.z d’un ami nouvellement inscrit (avant qu’il ait rejoint votre réseau et après qu’il l’ai fait).
De plus, sous Linux, votre firewall refusera toute communication par défaut, je décrirai comment autoriser ce qu’il faut plus bas (notamment pour atteindre le serveur de jeu, c’est le but de mon exemple).
Sous Windows, ça semble grand ouvert par défaut (encore une fois, aux personnes figurant sur un réseau où vous êtes vous-mêmes).
Pas la peine de flipper, ça semble bien pensé à ce niveau-là.

Sous Linux : installation de l’application
Téléchargez l’outil, décompressez l’archive quelque part, passez root et faites ceci :

root$ make install

Copying hamachi into /usr/bin ..
Creating hamachi-init symlink ..
Compiling tuncfg ..
Copying tuncfg into /sbin ..

Hamachi is installed. See README for what to do next.

En gros, vous venez de vous rajouter un binaire /sbin/tuncfg qui va servir à exploiter une carte réseau virtuelle, votre brin VPN.

Sous Linux : installation de ce qu’il faut pour exploiter les tunnels virtuels
Votre noyau Linux doit avoir chargé le module « tun » (plus d’infos là). Le plus simple est de charger le module grâce à l’outil modconf (apt-get install modconf). Ca donne ça :

Si vous ne trouvez pas ce module, c’est que votre noyau est compilé main (et vous avez fait l’impasse sur plein de choses) ou que votre distribution Linux est naze Dans ce cas, recompilez-en un avec ce module (démerdez-vous un peu).
Pour vérifier qu’il est chargé :

$ lsmod | grep tun
tun                    11776  0

Avec modconf, ce module sera chargé à chaque boot.

Il faut ensuite créer à la main (une seule fois) un périphérique réseau qui sera exploité pour ces tunnels. Si vous tapez actuellement tuncfg (en tant que root), vous obtenez :

root$ tuncfg
tuncfg: cannot stat() /dev/net/tun -- No such file or directory
tuncfg: visit http://www.hamachi.cc/tuntap for more information

Donc, en root, tapez ceci :

root$ mkdir /dev/net
root$ mknod /dev/net/tun c 10 200

Alors le lancement de tuncfg ne dit plus rien (preuve qu’il s’est bien lancé, faites un ps pour contrôler)

Optionnel sous Linux : comment faire en sorte que tuncfg soit chargé au reboot ?
Si vous n’avez pas envie de devoir relancer à chaque reboot la commande tuncfg, vous pouvez par exemple créer un script qui sera appelé au boot. Je ne détaille pas le principe sous Linux, juste la procédure. Faites des man sur les commandes utilisées si vous êtes curieux.
Créez un fichier /etc/init.d/hamachi_tuncfg avec les permissions d’exécution, contenant :

#!/bin/sh
#script simple pour /etc/init.d de demarrage de tuncfg pour HAMACHI
#auteur : michauko

test -x /sbin/tuncfg || exit 0
. /lib/lsb/init-functions

export PATH="${PATH:+$PATH:}/usr/sbin:/sbin"

case "$1" in
  start)
        log_daemon_msg "Demarrage TUNCFG pour HAMACHI" "tuncfg"
        if start-stop-daemon --start --quiet --oknodo --exec /sbin/tuncfg ; then
            log_end_msg 0
        else
            log_end_msg 1
        fi
        ;;
  stop)
        log_daemon_msg "Arret TUNCFG pour HAMACHI" "tuncfg"
        if start-stop-daemon --stop --quiet --oknodo --name tuncfg ; then
            log_end_msg 0
        else
            log_end_msg 1
        fi
        ;;

  restart)
        log_daemon_msg "Redemarrage TUNCFG pour HAMACHI" "tuncfg"
        start-stop-daemon --stop --quiet --oknodo --retry 30 --name tuncfg
        if start-stop-daemon --start --quiet --oknodo --exec /sbin/tuncfg ; then
            log_end_msg 0
        else
            log_end_msg 1
        fi
        ;;

  *)
        log_action_msg "Usage: /etc/init.d/hamachi_tuncfg {start|stop|restart}"
        exit 1
esac

exit 0

Ensuite, on crée les raccourcis qui vont bien dans les runlevels :

# update-rc.d  hamachi_tuncfg defaults
 Adding system startup for /etc/init.d/hamachi_tuncfg ...
   /etc/rc0.d/K20hamachi_tuncfg -> ../init.d/hamachi_tuncfg
   /etc/rc1.d/K20hamachi_tuncfg -> ../init.d/hamachi_tuncfg
   /etc/rc6.d/K20hamachi_tuncfg -> ../init.d/hamachi_tuncfg
   /etc/rc2.d/S20hamachi_tuncfg -> ../init.d/hamachi_tuncfg
   /etc/rc3.d/S20hamachi_tuncfg -> ../init.d/hamachi_tuncfg
   /etc/rc4.d/S20hamachi_tuncfg -> ../init.d/hamachi_tuncfg
   /etc/rc5.d/S20hamachi_tuncfg -> ../init.d/hamachi_tuncfg

Pour simuler le reboot, appelez la commande /etc/init.d/hamachi_tuncfg start (ou stop ou restart). Contrôlez la (non-)présence du processus avec ps.

Voilààààà, tout est prêt au niveau de l’OS Linux pour lancer Hamachi.

Lancement et utilisation de Hamachi sous Linux :

Maintenant que la partie technique est faite (cf. les paragraphes ci-dessus), il faut vous créer un compte. Cette fois, vous allez utilisez un compte utilisateur « normal » (ie, pas root). Par exemple, pour en revenir au serveur de jeu, le compte de l’utilisateur qui héberge ledit serveur. La commande – à faire une seule fois – est la suivante :

toto$ hamachi-init
Initializing Hamachi configuration (/home/toto/.hamachi). Please wait ..

  generating 2048-bit RSA keypair .. ok
  making /home/toto/.hamachi directory .. ok
  saving /home/toto/.hamachi/client.pub .. ok
  saving /home/toto/.hamachi/client.pri .. ok
  saving /home/toto/.hamachi/state .. ok

Authentication information has been created. Hamachi can now be started with
'hamachi start' command and then brought online with 'hamachi login'.

Ensuite, les commandes suivantes servent à chaque fois que vous voulez vous connecter au « système Hamachi » (avant de lancer votre serveur de jeu par exemple).

D’abord lancer hamachi :

toto$ hamachi start
Starting Hamachi hamachi-lnx-0.9.9.9-20 .. ok

Puis vous connecter (passer « online ») :

toto$ hamachi login
Logging in ....>....... ok

Si vous voulez connaitre votre IP sur le VPN (c’est-à-dire à quelle adresse sera hébergée votre serveur de jeu), faites un :

toto$ cat ~/.hamachi/state
Identity   5.168.x.y <---- c'est elle l'IP, c'est là que vos amis iront pour atteindre serveur "LAN sur Internet"
Nickname   votre_nick_quand_vous_l_aurez_choisi
AutoLogin  yes
OnlineNet  vos_reseaux_lorsque_vous_en_aurez_crees_ou_rejoints

Ensuite, choisissez-vous un beau nickname (à faire une seule fois, sauf pour en changer) :

toto$ hamachi set-nick toto_qui_hoste_le_serveur_de_jeu
Setting nickname .. ok

Ensuite, il faut créer un réseau. A noter que celui qui crée le réseau sera le seul à avoir le droit de le détruire ou de kicker des gens. Donc je suggère que le compte qui héberge le serveur de jeu soit celui qui crée ce réseau (rappel : ce réseau = ce point de ralliement, ce channel). Ca se fait comme ça :

toto$ hamachi create mon_reseau mon_mot_de_passe
Creating mon_reseau .. ok

Vous pouvez lister les personnes présentes (d’une part inscrites, d’autre part connectées ou non). Pour l’instant ce sera vide :

toto$ hamachi list
   [mon_reseau]

Vous-même n’êtes pas encore connecté à ce réseau (sinon il y aurait une « * » devant [mon_reseau]). Pour ce faire :

toto$ hamachi go-online mon_reseau
Going online in mon_reseau .. ok

(Ca vous demandera le mot de passe, évidemment).

Lorsque tous vos amis joueurs, sous Windows, auront rejoint votre réseau, ça ressemblera plutôt à :

toto$ hamachi list
 * [mon_reseau]
       * 5.90.x.y       fredo                     83.a.b.c:1043
          5.168.d.e     warlord
        * 5.63.e.f       autrepote               82.g.h.i:1077

Les « * » signifient que les gens sont connectés, vous avez leur IP VPN et leur IP Internet en fin de ligne. Si vous ne voyez pas les surnoms, il faut lancer la commande hamachi get-nicks.

Voilà vous savez tout.

Quelques autre commandes avant que je n’oublie, voyez :

toto$ hamachi --help
Hamachi, a zero-config virtual private networking utility, ver 0.9.9.9-20

  usage: hamachi [-c ] [command]

  -c         overrides default configuration directory (~/.hamachi)
  command    specifies an action. Can be one of the following -

             #  start [debug]
                stop
             #  set-nick 
                login
                logout
             #  list
                get-nicks
             #  create  [
]
                delete 
                evict   <5.x.x.x>
             #  join    [
]
                leave  
             #  go-online 
                go-offline 

  If no command is specified, hamachi displays its status including version,
  pid, online status and the nickname

et aussi, pour quitter Hamachi, le plus brutal est :

toto$ hamachi stop
Shutting down .. ok

Ca sauvegarde votre état, à savoir : online/offline, les réseaux auxquels vous étiez connectés etc. Vous pouvez quitter d’abord proprement tout ça (c’est pas utile) avec des commandes style hamachi logoff et hamachi go-offline mon_reseau (pour rejoindre un réseau : hamachi go-online mon_reseau).

Bon voilà, vous savez tout sous Linux pour :

- mettre en place hamachi

- créer votre compte, vous connecter

- créer votre réseau et vous y (dé)connecter

- voir qui est dessus

- et surtout : connaitre votre IP sur le VPN, IP qui sera à donner à tout le monde pour joindre votre serveur.

Sous Linux : quoi faire sur le firewall ?

Si vous avez déjà des amis sous Hamachi sous Windows, vous verrez que ces amis n’arrivent pas à « ping-er » l’IP du VPN de l’utilisateur Hamachi sous Linux (donc potentiellement ils ne pourront pas joindre votre serveur de jeu).
Il faut ouvrir le firewall proprement.
En effet, sans ça, si vous tentez des ping dans un sens ou dans l’autre (depuis votre compte Hamachi Linux et depuis un compte que vous aurez sur une autre machine Windows par exemple), vos logs risquent de vous dire quelque chose comme ça :

Listed by source hosts:
 Rejected 5 packets on interface ham0
    From 5.x.y.z - 4 packets
       To 5.a.b.c - 4 packets
          Service: 8 (icmp/8) (Shorewall:INPUT:REJECT:) - 1 packet
          Service: www (tcp/80) (Shorewall:INPUT:REJECT:) - 3 packets
    From 5.x.y.z - 1 packet
       To 5.a.b.c - 1 packet
          Service: 3 (icmp/3) (Shorewall:OUTPUT:REJECT:) - 1 packet

Les curieux auront vu avec ifconfig qu’une nouvelle interface réseau est née : ham0.
J’utilise shorewall (cf. ma doc Debian pour plus d’infos). Si vous n’ utilisez « que » iptables, vous êtes autiste et vous pourrez transposer ce qui suit.

Dans le fichier /etc/shorewall/interfaces, vous déclarez une zone correspondant à l’interface réseau virtuelle de Hamachi, ça donne quelque chose comme ça :

net     eth0            detect          dhcp,tcpflags,norfc1918,routefilter,nosmurfs,logmartians,blacklist
#pour hamachi :
ham     ham0            detect          tcpflags,detectnets,nosmurfs

Ensuite, dans /etc/shorewall/zones, vous expliquez que cette « zone » est de type ipv4 classique :

fw      firewall
net     ipv4
ham     ipv4
loc    ipv4

Enfin, comme vous souhaitez sûrment être restrictif pour l’accès à ce réseau, il n’est sûrement pas la peine de préciser quelque chose dans le fichier /etc/shorewall/policy : tout est droppé par défaut. Le retour d’information du firewall (le serveur de jeu) vers les clients sera autorisé même sans règle type ACCEPT fw ham puisque la communication aura été initié dans l’autre sens (client joueur qui s’adresse au serveur). N’oublions pas que le firewall Linux est « stateful ».
Donc on n’a plus qu’à ouvrir ce qui nous intéresse. Ci-dessous le port du jeu « Call Of Duty UO » et l’autorisation de ping (ça aide toujours un peu à débugger) dans le fichier /etc/shorewall/rules :

# HAMACHI
Ping/ACCEPT     ham             fw
ACCEPT          ham             fw      udp 28960 # CALL OF DUTY

Vous relancez shorewall (/etc/init.d/shorewall restart), contrôlez son bon lancement (tail /var/log/shorewall-init.log). Et ô magie, le ping Windows/ip_hamachi -> Linux/ip_hamachi passe.

Pour ce qui est de la connexion au serveur de jeu dont il est question dans cet article, il faut encore que vous le lanciez en lui expliquant d’une manière ou d’une autre qu’il est configuré en LAN et que son adresse d’attachement est 5.x.y.z et non pas votre IP publique. Pigé ? Certains pourraient même avoir besoin de désactiver des contrôles de clefs…

Maintenant pour vos amis qui ne demandent qu’à jouer, pas à geeker, voici le chapitre qu’il leur faut :

Installation & utilisation sous Windows

Ca, c’est le chapitre où vous expliquez au reste de votre équipe de bras cassés de l’informatique comment faire pour se connecter à votre VPN-machin sous Windows pour (enfin) pouvoir jouer. ‘y comprennent rien c’est grave
Il faut installer le client Windows, le lancer et suivre ce que ça raconte. Il y a même un tuto obligatoire qui explique le B-A.BA pour prendre en main Hamachi. Ensuite, vos amis rejoindront votre réseau (qu’on a nommé ici « mon_reseau ») et c’est terminé.
En image, ça donne ça :

Et je vous le donne en mille, dans le cas ci-dessus, l’utilisateur Linux (vous) qui a créé le réseau est la personne dont le nick est « ze_serveur ». Plus haut, j’ai du le nommer « toto_qui_hoste_le_serveur ». Pigé ?

Voilà. C’est fini. Fraggez bien.