Serveur d'impression

Comment connecter votre réseau sur site à Windows Azure en utilisant Windows Server en tant que passerelle VPN – Bien choisir son serveur d impression

Par Titanfall , le 10 octobre 2019 - 15 minutes de lecture

Parallèlement au lancement de l'infrastructure IaaS (Windows Azure) cet été, Microsoft a également permis aux clients de connecter leurs réseaux locaux à Windows Azure à l'aide d'un VPN de site à site.

Le service responsable de cette fonctionnalité s'appelle Windows Azure Gateway. Il utilise IPSec pour établir un tunnel VPN de site à site entre votre réseau et vos réseaux dans Windows Azure. Ajouter efficacement un deuxième site à votre réseau. Actuellement, seuls les périphériques Cisco et Juniper sont officiellement pris en charge en tant que partie locale du tunnel. Cependant, étant donné que Windows Azure Gateway utilise le tunneling site à site IPSec standard, vous pouvez théoriquement utiliser tout périphérique prenant en charge les exigences. Un tel scénario utilisant Windows Server 2008 R2 en tant que routeur sur site correspond à l'objectif de ce port. (Si vous vous demandez pourquoi je n'utilise pas Windows Server 2012, la réponse est simplement: il ne prend pas en charge la configuration requise. Plus précisément, Windows Server 2012 ne gère pas NAT-T comme Windows Server 2008 R2.)

La documentation de Windows Azure Gateway répertorie les exigences suivantes pour le périphérique VPN sur site:

  • Le périphérique VPN doit avoir une adresse publique IPv4
  • Le périphérique VPN doit prendre en charge IKEv1
  • Établir des associations de sécurité IPsec en mode tunnel
  • Le périphérique VPN doit prendre en charge NAT-T
  • Le périphérique VPN doit prendre en charge la fonction de cryptage AES 128 bits, la fonction de hachage SHA-1 et le secret Diffie-Hellman Perfect Forward en mode «Groupe 2».
  • Le périphérique VPN doit fragmenter les paquets avant de s’encapsuler avec les en-têtes VPN

Heureusement pour nous, Windows Server 2008 R2 supporte tout cela! Alors mettons-le en place.

Avant de pouvoir configurer votre périphérique local, vous devez suivre ces étapes dans le portail de gestion Windows Azure:

  • Créer un ou plusieurs réseaux virtuels (WAVN) dans Windows Azure
    Celles-ci hébergeront vos machines virtuelles Windows Azure et seront vos réseaux locaux dans Windows Azure.
  • Définir un réseau local dans Windows Azure
    Configurez ce réseau avec tous les sous-réseaux que vous exécutez sur votre réseau sur site, ainsi que l'adresse IP publique de votre périphérique VPN.
  • Ajouter au moins un serveur DNS à Windows Azure
    Ceux-ci peuvent être n'importe quel serveur DNS; sur site, dans Windows Azure et DNS public. Tous les serveurs que vous ajoutez seront assignés avec Windows Azure DHCP à vos ordinateurs virtuels.
  • Mettez de côté un sous-réseau au sein des réseaux que vous avez créé dans Windows Azure en tant que réseau de liaison.
    Ce réseau représente le lien entre vous et Windows Azure. Il doit se situer dans la limite des réseaux que vous avez créés dans Windows Azure à l'étape précédente.
  • Entrez l'adresse IP publique de votre périphérique VPN
    Le périphérique VPN ne peut pas être derrière un NAT, pas même un NAT 1: 1 avec des adresses IP publiques.
  • Démarrer la passerelle Windows Azure

Ce sont des étapes de haut niveau. La documentation de Windows Azure fournit des informations détaillées sur la configuration de vos réseaux de cloud, etc. Cet article traite de l'utilisation de Windows Server en tant que périphérique VPN local. Par conséquent, je ne vais pas répéter les étapes spécifiques décrites ici. Au lieu de cela, je vous renvoie à la documentation:

Une fois la configuration terminée dans Windows Azure, vous êtes prêt à configurer votre périphérique local.

Le correctif 2523881 doit être installé sur l'ordinateur Windows Server 2008 R2 que vous utiliserez comme périphérique VPN. Ce correctif active l'ancien mode Windows Server 2003 de NAT-Traversal (NAT-T) requis par Windows Azure Gateway. Si ce correctif n'est pas installé, vous recevrez du trafic sur votre réseau, mais le trafic de retour ne fonctionnera pas. Voici le lien vers le correctif:

Voici la topologie du réseau local dans mon environnement de test:

Notre tâche ici est de connecter notre réseau sur site à nos réseaux Windows Azure, puis de promouvoir un serveur dans Windows Azure en tant que contrôleur de domaine pour notre domaine Active Directory.

Votre serveur VPN local n'a pas besoin d'être la passerelle par défaut de votre réseau local, mais si c'est le cas, cela facilitera votre configuration. Disons simplement que vous devez définir les exigences de routage dans votre environnement. Dans cet exemple, je suppose que le serveur VPN est également votre passerelle locale par défaut. Votre serveur VPN ne doit pas avoir d'adresse IP de passerelle par défaut définie sur la carte réseau connectée au réseau local (LAN). Si vous souhaitez que le routage personnalisé utilise RRAS, la commande route ou NETSH pour configurer vos itinéraires.

Votre ordinateur Windows Server local a besoin d’au moins deux cartes réseau, l’une connectée à votre réseau local et l’autre à l’Internet public. Le serveur n'a pas besoin d'être associé à votre domaine. Je vous recommande vivement de garder le pare-feu Windows activé sur le serveur VPN. Avoir un serveur directement connecté à Internet sans pare-feu n'est pas une bonne idée.

Étapes d'installation de haut niveau

  • Documentez l'adresse IP publique de votre serveur VPN et l'adresse IP publique de votre point de terminaison Windows Azure Gateway, ainsi que de vos réseaux Windows Azure et des réseaux locaux. Vous en aurez besoin lors de l'installation.
  • Recherchez votre clé de cryptage IPSec sur le portail Windows Azure.
  • Activer le routage
  • Tunnel Configue IPSec
  • Vérifier la connectivité
  • Ajoutez une machine virtuelle dans Windows Azure et passez au contrôleur de domaine.

Récupérer la clé de cryptage IPSec

Connectez-vous au portail Windows Azure et sélectionnez Réseaux. Cliquez sur le réseau auquel vous êtes connecté sur votre réseau sur site et sélectionnez Afficher la clé (vous le trouverez en bas de l'écran):

Copiez la clé affichée:

Activer le routage

Installez le Routage et accès distant (RRAS) Service de rôle qui fait partie du Serveur de stratégie réseau et services d'accès rôle. Vous devrez sélectionner à la fois le service d'accès à distance et le routage, l'un ne pouvant être installé sans l'autre. Vous pouvez le faire via le Gestionnaire de serveur ou PowerShell.

La commande PowerShell est la suivante:

Ajouter-WindowsFeature NPAS-RRAS-Services –IncludeAllSubFeature

Activez et configurez le service Routage et accès distant pour le routage LAN uniquement. Cliquez avec le bouton droit sur Routage et accès distant et sélectionnez Configurer et activer le routage et l'accès à distance:

Sélectionner Configuration personnalisée et le select Routage LAN:

Ce que cette étape fait est de transformer Windows en un routeur IPv4 / IPv6. Il lui dit simplement de commencer à transmettre les datagrammes IP. Sauf si vous avez des exigences de routage particulières dans votre environnement, vous avez terminé de configurer RRAS.

Configurer le tunnel IPSec

Dans Windows Server 2008 et les nouveaux paramètres IPSec ont été fusionnés dans le Pare-feu Windows.

1. Ouvrir Pare-feu Windows avec sécurité avancée et sélectionnez Règles de sécurité de la connexion:

2. Faites un clic droit et sélectionnez Nouvelle règle. Sur le Type de règle page, sélectionnez Tunnel:

3. Sur le Type de tunnel écran, laissez la valeur par défaut Configuration personnalisée et Non pour les exemptions IPSec sélectionnées et cliquez sur Prochain:

4. Sur le Exigences écran laissez la valeur par défaut: Exiger une authentification pour les connexions entrantes et sortantes sélectionné et cliquez sur Suivant:

5. Ensuite, sur le Points de terminaison de tunnel écran, configurez les points de terminaison du tunnel et les réseaux. (Vous devrez faire défiler l'écran pour configurer les réseaux Point final 2):


REMARQUE: Il est extrêmement important que les réseaux que vous définissez ici correspondent à la configuration de votre réseau local dans Windows Azure, sinon votre trafic ne sera pas routé.

6. Sur le Méthodes d'authentification écran, sélectionnez Avancée puis appuyez sur le Personnaliser bouton:

7. Dans le Personnaliser l'authentification avancée dialogue ajouter une authentification par clé pré-partagée pour le Premières méthodes d'authentification:

8. Sur le Profil sélectionnez les profils de pare-feu auxquels cette règle s'appliquera. Habituellement ce sera tous les trois:

9. Dans l'écran Nom, attribuez à la règle un nom et une description appropriés:

10. Windows Azure Gateway nécessite que vous modifiiez la taille de segment maximale TCP (MSS) en fragmentation à distance. Vous faites cela avec NETSH sur votre interface externe (avec accès à Internet). Commencez par lister vos interfaces:

interface netsh sous-interfaces show ipv4

Dans la colonne Interface, vous devez reconnaître les noms de vos interfaces. Maintenant changez la valeur TCP MSS:

netsh interface ipv4 set subinterface “”Mtu = 1350 magasin = persistant

Exécutez à nouveau la première commande NETSH pour vérifier le changement.

11. Configurez les durées de vie des clés IPSec Quick Mode. Windows Azure Gateway utilise une durée de vie de clé du mode rapide (phase 2) de 1 heure (3 600 secondes) ou 100 Go de trafic, selon la première éventualité. La durée de vie de la clé de la phase 1 est de 8 heures. Il s'agit de la valeur par défaut dans Windows Server 2008 R2. Il n'est donc pas nécessaire de le modifier.

Cliquez avec le bouton droit sur le nœud Pare-feu Windows avec fonctions de sécurité avancées en haut de la console du Pare-feu Windows, puis sélectionnez Propriétés. Puis sélectionnez le IPSec onglet, et appuyez sur le Personnaliser bouton:

Ensuite, sélectionnez le Avancée bouton radio sous Protection des données (mode rapide) et appuyez sur le Personnaliser bouton. Sous Intégrité des données et cryptage sélectionnez l'entrée appelée ESP / SHA1 / AES-CBC 128, etc. et appuyez sur le bouton Modifier bouton:

Sous Durée de vie clé la valeur du délai d’expiration en minutes est déjà correctement définie sur 60 minutes (3600 secondes); il suffit donc de configurer le KB temps libre. Réglez-le sur 102 400 000 Ko (100 Go).

Quittez toutes les cases en appuyant sur OK.

REMARQUE: Il s'agit de paramètres globaux qui affectent toutes les règles de sécurité de connexion sur le serveur. Si vous souhaitez spécifier ces paramètres uniquement dans la règle de sécurité de la connexion associée à Windows Azure, utilisez NETSH. Malheureusement, vous ne pouvez pas configurer les paramètres de mode principal ou de mode rapide spécifiques aux règles de sécurité de connexion dans l'interface graphique. De plus, vous ne pouvez pas utiliser NETSH pour configurer les paramètres globaux du mode rapide, mais uniquement les paramètres du mode principal. La logique derrière cela m'échappe… Si vous décidez de configurer des paramètres de mode rapide spécifiques à une règle avec NETSH, l'interface graphique vous informera que votre règle «… contient des propriétés qui ne sont pas prises en charge par cette interface». Cela dit, je vous recommanderais en fait d’utiliser des paramètres de mode rapide spécifiques aux règles, car vous n’auriez ainsi pas à modifier les paramètres par défaut de l’ordinateur, ce qui pourrait éventuellement causer des problèmes pour d’autres règles. Bien que cela ne soit pas nécessaire pour Windows Azure Gateway, étant donné que les paramètres par défaut correspondent aux paramètres requis, vous pouvez également configurer des règles de mode principal spécifiques qui correspondent par exemple à. points de terminaison, en utilisant NETSH. Plus d'informations sur les différences entre l'interface graphique de Firewall et NETSH ici. Jetez également un coup d'oeil à la section des scripts à la fin du post.

12. Vérifiez que le tunnel IPSec a été créé à l’aide du bouton surveillance nœud de la console Pare-feu Windows avec sécurité avancée. Sous Associations de sécurité vous devriez avoir une association sous les deux Mode principal et Mode rapide noeuds:

Si vous ne voyez aucune association de sécurité, essayez d'envoyer une requête ping à une adresse de l'un de vos réseaux Windows Azure. Cela devrait établir le tunnel.

13. Vérifiez la connectivité sur le portail Windows Azure:

Vous pouvez maintenant ajouter des machines virtuelles Windows Azure à vos réseaux Windows Azure. Ces ordinateurs recevront des adresses IP du service DHCP Windows Azure. Les adresses seront louées à la machine pour sa durée de vie, donc ce sera la même chose que d'avoir une adresse IP statique. Windows Azure DHCP configurera également les serveurs avec les serveurs DNS que vous avez définis dans Windows Azure. Ceux-ci peuvent être à la fois sur site et dans le cloud. Les passerelles par défaut pour les machines seront définies sur la première adresse du sous-ensemble auquel la machine est connectée.

Une fois que la première machine virtuelle Windows Azure est en ligne (et que son pare-feu est ouvert), vous devriez pouvoir envoyer du trafic sur le VPN. Dans mon cas, je peux maintenant faire un ping entre ma machine virtuelle Windows Azure et des machines sur site:

Maintenant, je peux ajouter la transformation de la machine virtuelle Windows Azure en contrôleur de domaine:

Les périphériques réseau tels que les routeurs et les commutateurs étant généralement configurés à l'aide de scripts, voici les commandes NETSH permettant de configurer Windows Server en tant que périphérique VPN à partir de la CLI:

  1. Activer le routage IPv4:
    RRAS n’est pas vraiment nécessaire pour que Windows Server route le trafic IPv4. Vous pouvez configurer la même fonctionnalité directement avec NETSH. Cela supprime la nécessité d'installer RRAS. Pour configurer le routage, vous devez d’abord trouver les noms d’interface ou les index de vos interfaces réseau. Dans ce cas, les miens sont 12 et 14. 12 est l'interface externe connectée à Internet et 14 est l'interface interne connectée au réseau local. Le routage, ou le transfert de datagramme IP, doit être configuré sur les deux. Utilisez NETSH:
    netsh interface ipv4 set interface “12” forwarding = enable netsh interface ipv4 set interface “14” forwarding = enable
  2. Créez une règle de sécurité de connexion avec les paramètres de mode rapide spécifiques à la règle:
    netsh advfirewall consec ajoute le nom de la règle = "Windows Azure" endpoint1 = "192.168.0.0/16" endpoint2 = "10.1.0.0/16" action = "requireinrequireout" description = "VPN de site à site pour Windows Azure" mode = " tunnel ”profile =” any ”type =” static ”localtunnelendend =” 80.212.96.194 ”- remotetunnelendendend =” 168.63.16.208 ”protocole =” any ”: auth1 =” computerpsk ”auth1psk =” wL8fC… ”qmsecmethods =” ESP: SHA1-AES128 + 60min + 102400000kb ”
  3. Créez une règle de mode principal qui correspond au trafic entre le réseau local et Windows Azure. Cette règle sera ensuite utilisée par la règle de sécurité de la connexion. Il s'agit d'une étape redondante puisque les paramètres par défaut de Windows Server 2008 R2 correspondent aux exigences de Windows Azure. C’est juste pour montrer comment c’est fait…
    netsh advfirewall mainmode add nom de règle = "Paramètres de mode principal Windows Azure IPSec" mmsecmethods = "dhgroup2: aes128-sha1" "mmkeylifetime =" 480min, 0sess "description =" Paramètres de mode principal compatibles avec Windows Azure Gateway "endpoint1 =" 192.168.0.0/ " 16 "terminal2 =" 10.1.0.0/16 "
  4. Configurez la taille de TCPMSS:
    netsh interface ipv4 set subinterface “”Mtu = 1350 magasin = persistant

Donc, si vous combinez toutes les commandes dans un joli fichier cmd, vous obtenez quelque chose qui ressemble à un script de configuration de routeur.

Plus d'informations sur la syntaxe NETSH sont disponibles ici:

  • IPv6 n'est actuellement pas pris en charge par Windows Azure. Par conséquent, vous ne disposez d'aucune connectivité IPv6 native. Peut-être pourrez-vous utiliser certaines des technologies de transition. Je n'ai pas testé ça.
  • Le serveur VPN lui-même ne pourra pas communiquer avec les machines virtuelles dans Windows Azure. Seuls les ordinateurs situés derrière le serveur VPN seront en communication.
  • J'ai pu mesurer une vitesse de transfert d'environ 9 Mbps entre mon réseau local et une machine virtuelle de petite instance fonctionnant sous Windows Azure. J'ai utilisé IPERF pour tester.
  • Cette solution est instable, mais je ne sais pas si cela concerne Windows Server ou Windows Azure. Laissez un commentaire avec vos expériences.
  • Le pare-feu Windows protège votre serveur VPN sur Internet. assurez-vous qu'il est configuré correctement. Puis-je également suggérer de supprimer toutes les liaisons inutiles sur Internet face à la carte réseau. N'oubliez pas non plus que le trafic VPN n'est pas inspecté par le pare-feu puisqu'il se trouve à l'intérieur du tunnel.
  • Les scripts de configuration disponibles pour les périphériques de passerelle pris en charge, actuellement Cisco et Juniper, sont très utiles pour comprendre les paramètres nécessaires à la configuration de votre serveur VPN. Vous pouvez les télécharger via le portail Windows Azure Managmenet, sous Réseaux.
  • Windows Azure PowerShell peut également être utilisé pour gérer et configurer vos réseaux et votre passerelle.
Click to rate this post!
[Total: 0 Average: 0]

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.