[Hands-On] Mise en Place d’un VPN Point-to-Site Azure

Hello,

Nouvelle année : nouveaux sujets. L’article du jour traite d’Azure : la mise en place d’un VPN Point-to-Site.

Relativement simple à mettre en oeuvre comme vous allez le voir, cet article vous permettra surtout de bien réagir si vous rencontrez des difficultés après la mise en place (#CaSentLeVécu).

L’article de référence pour mettre en place ce VPN est celui-ci : https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal . Il décrit très bien le contexte et la raison d’être du P2S : un accès ponctuel au réseau virtuel depuis une machine.

Evidemment, pour commencer, il vous faut un réseau virtuel sur votre tenant Azure. Je pars du principe que vous disposez déjà d’un environnement Azure complet et opérationnel.

Il vous faudra donc créer une « Virtual Network Gateway » (ou passerelle de réseau virtuelle pour les francophones) :

 

 

Pensez à bien intégrer cette ressource dans le bon réseau virtuel.

La suite consiste à générer des certificats auto-signés. Le plus simple et le plus rapide : makecert.exe. La documentation Microsoft explique à nouveau très bien ces manipulations : https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-certificates-point-to-site .

Une fois en possession des deux certificats, l’un doit être installé sur la machine cliente du VPN, le contenu de l’autre doit être copié/collé dans la ressource VPN Azure sous « Point-to-Site configuration ».

Vous téléchargez ensuite & installez l’exe VPN permettant de connecter la machine cliente au réseau virtuel.

Félicitations, vous venez de mettre en place un réseau P2S ! Bon… oui; on a un peu accéléré le processus. Mais ce n’est finalement pas vraiment plus compliqué que cela.

Néanmoins, plusieurs scénarios pourraient survenir à partir de ce point …

1 – Tout fonctionne correctement.

Lucky You ! Vous accéder aux shared folders de votre laptop depuis votre VM et vice-versa. Dans ce cas là, ne tenez pas compte des prochains scénarios, vous faites parti des chanceux

 

2 – Pensez avant tout à checker vos NGS Azure

Elles pourraient vous jouer des tours si vous les avez oublié dans un coin de votre tête…

 

3 – Votre client VPN se connecte mais impossible d’accéder aux shared folders (ni de la VM, ni du laptop).

Vos VM Azure existent depuis Septembre 2016 voir avant ? Vous les allumez/éteignez régulièrement ? Alors vous avez sans doute de nombreux ghosts NIC. Pour vérifier, allez dans votre device manager, et cliquez sur View > Show Hidden Devices. Si vous obtenez un résultat similaire à cette capture d’écran, alors voici le problème :

La bonne nouvelle c’est que vous pouvez trouver facilement des scripts pour supprimer ces périphériques fantômes. En voici un qui a fonctionné pour moi par exemple :

Import-Module c:\script\DeviceManagement\Release\DeviceManagement.psd1 -Verbose

$hiddenHypVNics = Get-Device -ControlOptions DIGCF_ALLCLASSES | Sort-Object -Property Name | Where-Object { ($_.IsPresent -eq $false) -and ($_.Name -like « Microsoft Hyper-V Network Adapter* ») }

$hiddenHypVNics | ForEach-Object {

Write-Verbose « Removing «  »@$($_.InstanceId.Replace(« `0« ,  »)) » » »

c:\script\devcon.exe remove « «  »@$($_.InstanceId.Replace(« `0″,  »)) » » »

}

 

A noter que les prérequis ci dessous sont nécessaires :

Une fois tous les ghosts nettoyés, redémarrez la VM et essayer à nouveau d’accéder à des shared folders.

4 – Votre VM accède aux shared folders de votre laptop… mais pas l’inverse ?

Votre VM est dans un domaine ? Vous arrivez à Pinger votre VM depuis votre laptop sous le VPN ? Pas de paniques, tout va s’arranger, et rapidement !

Pour résoudre ce problème, rendez-vous dans la base de registre de votre laptop, et modifiez la valeur de la clé disabledomaincreds de 0 à 1:

La prise en compte est immédiate, votre laptop devrait maintenant pouvoir accéder aux shared folders de votre VM.

En espérant que cet article puisse en aider quelques-uns !

 

Laisser un commentaire