Nous allons voir ici la création d’un serveur OpenVpn en mode ponté, c’est-à-dire qu’à chaque client du VPN sera attribué une adresse du réseau local côté serveur. C’est le routeur en charge du DHCP côté serveur qui distribuera les adresses aux clients VPN. La carte réseau physique (eth0) et la carte réseau virtuelle (tap0) seront donc bridgées ensemble sous l’interface br0. Nous allons aussi faire en sorte de gérer la révocation des certificats. La base est une installation sans graphique de Debian Wheezy.

Ce tuto est en très grande partie de celui de Mattotop sur le forum debian-fr.org. J’ai fait quelques petites modifications, mais je ne serai certainement pas arrivé à grand-chose sans lui.

Comme le paquet openssl est requis, et que tout le monde parle de Heartbleed en ce moment, on en profite pour vérifier que’on a bien la ligne deb http://security.debian.org/ wheezy/updates main contrib non-free dans notre sources.list :)

Commencer par installer les paquets nécessaires : aptitude install bridge-utils openvpn openssl rcconf

On se positionne dans le répertoire de configuration d’OpenVPN : cd /etc/openvpn

On y copie le dossier easy-rsa contenant tous les scripts de gestion du serveur et des clients :

cp -R /usr/share/doc/openvpn/examples/easy-rsa/2.0/ ./easy-rsa

(note : sous Jessie, il faut installer le paquet easy-rsa, et la conf se trouve directement à /usr/share/easy-rsa)

On rentre dans le dossier easy-rsa :

cd easy-rsa

Puis on édite le fichier vars, qui contient les valeurs communes pour la génération des certificats. Ce sont principalement les informations des dernières lignes à adapter selon nos besoins :

nano ./vars

Puis on “source” ce fichier, pour exporter toutes les valeurs dans nos variables d’environnement. Il faudra faire cette opération chaque fois que nous voudrons agir sur les certificats, par exemple pour générer de nouveaux certificats ou en révoquer.

. ./vars

Le script nous avertir que si on lance la commande ./clean-all, il va (ré)initialiser le répertoire keys, qui contiendra toutes nos clés. Ça tombe bien, c’est une install neuve, nous souhaitons le faire :

./clean-all

Nous préparaons ensuite les clés et paramètres Diffie-Hellman :

./build-dh
./build-ca
./build-key-server monServeurVpn

Sur la phase de création de la clé du serveur, tout comme pour la phase de création des certificats des clients, il n’est pas obligatoire de mettre un mot de passe. Il faut par contre que chaque CommonName soit unique, et il faut valider les 2 demandes de signature à la fin, en tapant “y”.

Nous allons générer puis révoquer un kit quelconque, ce qui permettra d’initialiser le fichier crl.pem. Ce fichier est indispensable pour que le serveur vérifie la liste des certificats révoqués. Sans ce dernier, un certificat révoqué permettra quand même de se connecter sans souci.

./build-key dummy
./revoke-full dummy

Nous avons maintenant le fichier ./keys/crl.pem qui est initialisé. Note : si nous souhaitons voir le contenu de ce fichier, nous puvons lancer la commande suivante :

openssl crl -text -noout -in keys/crl.pem

Nous créons maintenant un kit pour notre premier client, que l’on conservera :

./build-key client1

Nous passons ensuite à la configuration du serveur. le fichier est à mettre dans le répertoire /etc/openvpn pour être lancé par le service openvpn.

nano /etc/openvpn/monServeurVpn.conf

On y colle ceci :

port 1194
proto udp
dev tap0
ca		/etc/openvpn/easy-rsa/keys/ca.crt
cert	/etc/openvpn/easy-rsa/keys/monServeurVpn.crt
key		/etc/openvpn/easy-rsa/keys/monServeurVpn.key  # This file should be kept secret
dh		/etc/openvpn/easy-rsa/keys/dh1024.pem
server-bridge
keepalive 10 120
comp-lzo
persist-key
persist-tun
status 	/etc/openvpn/openvpn-status.log
#log-append	/etc/openvpn/openvpn.log
verb 3
crl-verify /etc/openvpn/easy-rsa/keys/crl.pem

(ce fichier est épuré au maximum ; vous pouvez récupérer ma version commentée et vous pouvez bien sûr lire les commentaires de l’exemple fourni par Debian ici : /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz )

Le fait que la ligne log-append soit commentée est volontaire : ainsi, nous avons directement la sortie affichée sur le terminal. A ce stade, nous pouvons normalement lancer le serveur.

cd /etc/openvpn
openvpn ./monServeurVpn.conf

doit démarrer OpenVpn et finir sur le message “Initialization Sequence Completed”. Il n’est pas fonctionnel pour autant, car nous n’avons pas configuré le réseau et le pont. Coupons le serveur qu’on vient de lancer avec Ctrl-C.

Il faut déjà désactiver le lancement du service openvpn au démarrage de la machine, car le réseau devra être complètement initialisé auparavant, et le lancement se fera via les scripts d’interface. Passer par la commande

rcconf

et décocher openvpn.

On édite ensuite le fichier /etc/network/interfaces, dans lequel on définit le bridge

cp /etc/network/interfaces /etc/network/interfaces.bak
nano /etc/network/interfaces

qui devra contenir ceci :

auto lo
	iface lo inet loopback

auto br0
	iface br0 inet manual
	bridge-ports eth0
	post-up /etc/openvpn/scripts/ovup && service openvpn start
	pre-down service openvpn stop
	post-down /etc/openvpn/scripts/ovdown

On choisit l’option “manual” car lorsque l’interface se lance, on ne va pas la configurer tout de suite. Ce sera fait lors des scripts dans le post-up.

Le but des scripts mentionnés ci-dessus est de déclencher la configuration de tap0 et le lancement du serveur lors de la mise en route de l’interface br0. Créons maintenant les scripts en question :

mkdir /etc/openvpn/scripts
cd /etc/openvpn/scripts
nano ovup

qui contiendra :

#!/bin/sh
openvpn --mktun --dev tap0
brctl addif br0 tap0
ifconfig eth0 promisc up
ifconfig tap0 promisc up
ifconfig br0 hw ether 1c:6f:65:ff:ff:ff  ## si on veut forcer le pont à avoir une adresse mac précise. Normalement elle prend celle de l'interface physique, mais il m'est arrivé qu'elle prenne celle de l'interface tap0, ce qui perturbe mon dhcp basé sur des baux fixes
ifconfig br0 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255

Ce script crée le device tap0, l’ajoute au pont br0 (qui contient déjà eth0), passe eth0 et tap0 en mode Promisc, nécessaire pour que le bridge fonctionne, et configure l’IP de br0. Encore une fois, si on souhaite être en dhcp avec bail fixe, on peut remplace la dernière ligne par dhclient -v br0

nano ovdown

qui contiendra

#!/bin/sh
openvpn --rmtun --dev tap0

On rend ces scripts executables :

chmod +x /etc/openvpn/scripts/ov*

Et normalement, un

service networking restart

devrait tout faire : démarrer le bridge, le configurer, et lancer le vpn. Si la commande se finit par “done.”, c’est que toutes les étapes se sont bien déroulées, et le serveur est prêt à l’emploi :)

Voici des exemples de fichier de conf client fonctionnels, après avoir adapté l’IP du serveur et les chemins du kit de connexion, pour Linux et pour Windows

Avant toute chose, ceci ne traite pas du tout de la configuration du gestionnaire de licence des services Bureau à distance de windows server, ni de leur aspect légal, mais purement de l’aspect technique.

Si l’on souhaite autoriser un utilisateur non-administrateur à se connecter au Bureau à distance sur un Windows Server 2012, il faut procéder à 3 étapes complémentaires :

• Tout d’abord, vérifier dans les Paramètres système avancés (clic droit sur le Poste de travail, puis Propriétés, puis sélectionner Paramètres système avancés sur le côté), dans l’onglet Utilisation à distance, que les connections à distances sont autorisées sur cet ordinateur. Si ce n’est pas le cas, les activer.

• Cliquer sur le bouton Sélectionner des utilisateurs, et ajouter le/les utilisateurs/groupes qui auront le droit de se connecter. Ceci a pour effet de placer l’utilisateur/groupe dans le groupe “Utilisateurs du Bureau à distance”. Ceci est visible dans le profil concerné, dans la gestion des utilisateurs et ordinateurs AD. Utiliser le menu “Séléctionnez des utilisateurs” et le composant Utilisateurs et Ordinateurs Active Directory revient exactement au même. Tout ajout/suppression dans l’un sera effectif dans l’autre.

• Ces personnes désormais ont le droit d’utiliser le protocole RDP, mais n’ont pas le droit d’ouvrir une session sur la machine pour autant. Pour remédier à ceci, il faut aller dans les stratégies locales du serveur, avec la commande gpedit.msc

Puis aller dans : Paramètres ordinateur |-Paramètres Windows |-Paramètres de sécurité |-Stratégies locales |-Attribution de droits utilisateurs

Et remplir la valeur “Autoriser l’ouverture de session par les services Bureau à distance” en conséquence.

Attention. Si on modifie ce paramètres dans les GPO du domaine entier, il sera appliqué à toutes les machines, et surtout le paramètre local par défaut (Administrateurs) sera remplacé par le nouveau paramètre de domaine. Il faut penser à rajouter le groupe Administrateurs si on souhaite qu’ils conservent un accès à distance.

Sous Windows 7 Pro ou Windows Server 2008 (et probablement Server 2003), lorsqu’un client se connecte en RDP, ses imprimantes locales sont redirigées sur sa session sur le serveur, et celle par défaut est mise par défaut sur la session distante.

Pour désactiver ces 2 comportements qui peuvent être gênants, il faut utiliser l’éditeur de stratégies de groupe (sur le serveur).

Lancer l’éditeur avec la commande

gpedit.msc

Puis aller dans

Modèles d'administration
|-Composants Windows
  |-Services Terminal Server
    |- Redirection de données client/serveur
      |- Ne pas autoriser la redirection de l'imprimante client  -> Activé

Il peut être souhaitable, pour différentes raisons, comme par exemple satisfaire la demande d’un client, que les utilisateurs simples d’un domaine, soient admins sur leurs machines, pour la gérer comme ils l’entendent, au niveau de l’installation de logiciels et autres. Ceci se paramètre via les Groupes Restreints.

Sous Windows Server 2012, il faut executer (sur le controleur de domaine)

gpmc.msc

puis descendre dans le domaine à gérer, aller dans les paramètres de la Default Domain Policy, faire un clic-droit puis Modifier, pour ouvrir l’Editeur de gestion des stratégies de groupes.

Puis on va dans

Config ordinateur
|-Stratégies
  |-Paramètres Windows
    |-Paramètres de sécurité
      |-Groupes restreints

On fait un clic-droit -> ajouter un groupe, puis on spécifie le Groupe de sécurité dont les utilisateurs seront élevés en tant qu’Admin locaux. Par exemple Utilisateurs du domaine pour tout le monde, ou encore un groupe Admin Locaux que l’on aura pris le soin de créer auparavant.

Puis dans la fenètre des proprietés de ce groupe restreint qui apparaît, dans le cadre “ce groupe est membre de”, on fait Ajouter, puis on sélectionne le groupe Administrateurs.

On force l’application de la GPO sur un client avec la commande

gpupdate /force

puis on déconnect et reconnecte une session sur un utilisateur faisant partie du groupe sus-spécifié, et il sera désormais admin de sa propre machine.

Source : honteusement pompé (une fois de plus) de http://www.frickelsoft.net/blog/?p=13

Il suffit de taper ces 3 commandes en powershell :

w32tm /config /manualpeerlist:pool.ntp.org /syncfromflags:MANUAL
Stop-Service w32time
Start-Service w32time

Source : honteux copier-coller, après vérification, de ce site, qui explique plus en détail : http://www.sysadminlab.net/windows/configuring-ntp-on-windows-server-2012

Lorsque l’on a plusieurs environnements de bureau installés, par exemple KDE, Gnome 3 et Mate, et que l’on utilise LightDM pour gérer la connexion graphique, la connexion se fera automatiquement sur le DE par défaut. Je suppose, sans être sûr, que c’est le dernier installé. On peut modifier ce choix à la volée, avec le menu déroulant prévu pour, mais ceci est à faire à chaque fois, et peut donc être pénible.

pour définir un nouvel environnement par défaut, à l’échelle du système, il suffit d’utiliser les alternatives. C’est donc la commande :

sudo update-alternatives --config x-session-manager

qui permet de voir et choisir à quel DE correspondra ce choix par défaut !

Sous XP, il peut arriver qu’il soit impossible de rendre accessible des partages réseau, notamment lorsque l’ordinateur essaie d’accéder à ses propres partages réseau ( \127.0.0.1\partage par exemple).

Le message d’erreur est de type : \serveur\partage est inaccessible. […] Mémoire insuffisante sur le serveur pour traiter cette commande.

Ce problème a été rencontré par beaucoup d’utilisateurs lorsque Acronis ou Norton Ghost étaient installés.

Il faut pour corriger ceci modifier une valeur du registre. Aller à la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Modifier (ou créer si elle n’existe pas) la valeur IRPStackSize, de type DWORD, et la positionner à une valeur supérieure. Sous XP, les valeurs peuvent aller de 0x1 (1) à 0x32 (50). La valeur par défaut est 0xF (15). Il est recommandé par Microsoft de monter les valeurs 3 par 3.

Il faut redémarrer la machine pour que les changements soient pris en compte.

Si l’on souhaite que les utilisateurs sans privilèges ne puissent pas se connecter en local sur un poste (par exemple pour en réserver l’accès aux admins), il faut utiliser les stratégies de groupe. Executer :

gpedit.msc

Et aller dans

Config ordi
  |-Paramètres Windows
    |-Paramètres de sécurité
      |-Stratégies locales
        |-Attribution des droits utilisteurs
          |-Permettre l'ouvrture d'une session locale  --> Enlever Utilistaeurs

Et voilà. Ceci n’empêche pas qu’ils ouvrent une session via une connexion RDP.

La comande md5sum, disponible en standard sous Linux (paquet coreutils sous Debian), permet de faire le md5 d’un fichier. Si on souhaite faire directement le md5 d’une chaine de caractères, il faut pour ceci utiliser la syntaxe suivante :

echo -n ma chaine de caracteres meme avec des espaces | md5sum

Il est indispensable de passer l’option -n, qui permet de supprimer le retour chariot (mis automatiquemeent par echo) de fin de chaine, qui modifie radicalement le md5.

Lorsqu’une Livebox est remplacée, il faut qu’elle fasse une actualisation auprès des serveurs H323 (ou SIP selon le protocole) d’Orange. Ceci est fait automatiquement sous 24h.

On peut cependant souhaiter réactiver plus rapidement cet accès à la téléphonie. Il faut pour ceci redémarrer 3 fois la Livebox, à environ 5 minutes d’écart (s’assurer que la connexion au net se soit bien rétablie entre 2 redémarrages), en maintenant la Box débranchée au moins 1 minutes à chaque fois. À chaque redémarrage, elle forcera l’opération suivante d’actualisation du serveur (qui se fait normalement automatiquement toutes les 6 à 8h).

Ainsi, au bout du 3ème redémarrage au max, les informations entre la Livebox et les différents serveurs H323 seront cohérentes, et la connexion au réseau VoIP sera opérationnelle (le voyant téléphonique s’allume environ 2 minutes après que la connexion au net soit effective, c’est à dire que le voyant @ est allumé)

Source : un technicien du 3901 - méthode appliquée avec succès sur une Livebox Pro V2.