GSP016

Présentation

Dans cet atelier pratique, vous allez apprendre à effectuer des tâches de mise en réseau élémentaires sur Google Cloud (ce qui inclut les instances Compute Engine). Vous découvrirez en outre les différences entre une configuration Google Cloud et une configuration sur site. Vous allez développer un réseau composé de trois sous-réseaux, ce qui aura pour résultat la création de l'environnement final suivant :

L'ordre dans lequel les exercices de cet atelier sont présentés correspond à une approche fréquemment suivie par les développeurs cloud :

1. Configurez l'environnement de l'atelier et familiarisez-vous avec votre environnement Google Cloud.
2. Déployez un réseau traditionnel incluant des sous-réseaux et différentes régions à l'aide d'outils Open Source courants pour pouvoir y accéder depuis le monde entier.
3. Testez et surveillez votre réseau et vos instances.

Points abordés

• Concepts et construction de base de la mise en réseau Google Cloud
• Configuration des réseaux par défaut et créés par l'utilisateur
• Évaluation des performances et de la latence
• Configurations de sécurité de base des accès, du pare-feu et du routage

Prérequis

• Connaissances de base sur Compute Engine
• Connaissances de base sur la mise en réseau et les protocoles TCP/IP
• Connaissances de base sur la ligne de commande Unix/Linux

Préparation

Avant de cliquer sur le bouton "Démarrer l'atelier"

Lisez ces instructions. Les ateliers sont minutés, et vous ne pouvez pas les mettre en pause. Le minuteur, qui démarre lorsque vous cliquez sur Démarrer l'atelier, indique combien de temps les ressources Google Cloud resteront accessibles.

Cet atelier pratique vous permet de suivre vous-même les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Nous vous fournissons des identifiants temporaires pour vous connecter à Google Cloud le temps de l'atelier.

Pour réaliser cet atelier :

• vous devez avoir accès à un navigateur Internet standard (nous vous recommandons d'utiliser Chrome) ;

Remarque : Ouvrez une fenêtre de navigateur en mode incognito/navigation privée pour effectuer cet atelier. Vous éviterez ainsi les conflits entre votre compte personnel et le temporaire étudiant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.

• vous disposez d'un temps limité ; une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.

Remarque : Si vous possédez déjà votre propre compte ou projet Google Cloud, veillez à ne pas l'utiliser pour réaliser cet atelier afin d'éviter que des frais supplémentaires ne vous soient facturés.

Démarrer l'atelier et se connecter à la console Google Cloud

1. Cliquez sur le bouton Démarrer l'atelier. Si l'atelier est payant, un pop-up s'affiche pour vous permettre de sélectionner un mode de paiement. Sur la gauche, vous trouverez le panneau Détails concernant l'atelier, qui contient les éléments suivants :

   • Le bouton Ouvrir la console Google
   • Le temps restant
   • Les identifiants temporaires que vous devez utiliser pour cet atelier
   • Des informations complémentaires vous permettant d'effectuer l'atelier

2. Cliquez sur Ouvrir la console Google. L'atelier lance les ressources, puis ouvre la page Se connecter dans un nouvel onglet.

   Conseil : Réorganisez les onglets dans des fenêtres distinctes, placées côte à côte.

   Remarque : Si la boîte de dialogue Sélectionner un compte s'affiche, cliquez sur Utiliser un autre compte.

3. Si nécessaire, copiez le nom d'utilisateur inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue Se connecter. Cliquez sur Suivant.

4. Copiez le mot de passe inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue de bienvenue. Cliquez sur Suivant.

   Important : Vous devez utiliser les identifiants fournis dans le panneau de gauche. Ne saisissez pas vos identifiants Google Cloud Skills Boost. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés.

5. Accédez aux pages suivantes :

   • Acceptez les conditions d'utilisation.
   • N'ajoutez pas d'options de récupération ni d'authentification à deux facteurs (ce compte est temporaire).
   • Ne vous inscrivez pas aux essais offerts.

Après quelques instants, la console Cloud s'ouvre dans cet onglet.

Remarque : Vous pouvez afficher le menu qui contient la liste des produits et services Google Cloud en cliquant sur le menu de navigation en haut à gauche.

Activer Cloud Shell

Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud. Cloud Shell vous permet d'accéder via une ligne de commande à vos ressources Google Cloud.

1. Cliquez sur Activer Cloud Shell  en haut de la console Google Cloud.

Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET. Le résultat contient une ligne qui déclare YOUR_PROJECT_ID (VOTRE_ID_PROJET) pour cette session :

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.

2. (Facultatif) Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

3. Cliquez sur Autoriser.

4. Vous devez à présent obtenir le résultat suivant :

Résultat :

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Facultatif) Vous pouvez lister les ID de projet à l'aide de cette commande :

gcloud config list project

Résultat :

[core] project = <ID_Projet>

Exemple de résultat :

[core] project = qwiklabs-gcp-44776a13dea667a6 Remarque : Pour consulter la documentation complète sur gcloud, dans Google Cloud, accédez au guide de présentation de la gcloud CLI.

Concepts de régions et de zones

Certaines ressources Compute Engine sont hébergées dans des régions ou des zones. Une région est un emplacement géographique spécifique où vous pouvez exécuter vos ressources. Chaque région se compose d'une ou plusieurs zones. Par exemple, la région "us-central1" est une région située au centre des États-Unis qui comprend les zones us-central1-a, us-central1-b, us-central1-c et us-central1-f.

Régions	Zones
Ouest des États-Unis	us-west1-a, us-west1-b
Centre des États-Unis	us-central1-a, us-central1-b, us-central1-d, us-central1-f
Est des États-Unis	us-east1-b, us-east1-c, us-east1-d
Europe de l'Ouest	europe-west1-b, europe-west1-c, europe-west1-d
Asie orientale	asia-east1-a, asia-east1-b, asia-east1-c

Les ressources contenues dans des zones sont des ressources dites "zonales". Par exemple, les instances de machines virtuelles et les disques persistants sont deux types de ressources situées dans des zones. Pour associer un disque persistant à une instance de machine virtuelle, vous devez placer ces deux ressources dans la même zone. Si vous souhaitez attribuer une adresse IP statique à une instance, l'instance doit se trouver dans la même région que l'adresse IP statique.

Pour en savoir plus et accéder à une liste complète des régions et zones disponibles sur la page Compute Engine, accédez à la documentation Régions et zones.

Réseau Google Cloud : concepts

Dans Google Cloud Platform, les réseaux fournissent des connexions de données vers et depuis vos ressources cloud (en général ces ressources sont des instances Compute Engine). Il est primordial de sécuriser vos réseaux pour protéger vos données et contrôler l'accès à vos ressources.

Google Cloud Platform, compatible avec les projets, les réseaux et les sous-réseaux, vous permet d'isoler des ressources non associées de façon flexible et logique.

Les projets constituent le type de conteneurs de plus haut niveau de la hiérarchie. Ils permettent de regrouper les ressources qui partagent les mêmes limites de confiance. Chaque projet possédant ses propres règles d'accès (IAM) et sa liste de membres, de nombreux développeurs décident de mapper leurs projets à des équipes. Les projets servent également à rassembler toutes les informations relatives à la facturation et aux quotas, qui reflètent la consommation de vos ressources. Les projets contiennent des réseaux (qui contiennent eux-mêmes des sous-réseaux), des règles de pare-feu ainsi que des routes. Les diagrammes d'architecture ci-dessous illustrent ce système.

Les réseaux connectent directement vos ressources les unes aux autres ainsi qu'au monde extérieur. Ils utilisent des pare-feu et hébergent également les règles d'accès relatives aux connexions entrantes et sortantes. Ils peuvent être soit mondiaux (auquel cas ils offrent une évolutivité horizontale sur plusieurs régions), soit régionaux (auquel cas ils offrent une latence faible au sein d'une unique région).

Les sous-réseaux vous permettent de regrouper des ressources associées (instances Compute Engine) dans des espaces d'adressage RFC1918 privés. Ils sont exclusivement régionaux, et vous pouvez les configurer en mode automatique ou personnalisé.

• Un réseau en mode automatique contient un sous-réseau par région, et chaque sous-réseau possède une plage d'adresses IP et une passerelle prédéterminées. Lorsque vous créez un réseau en mode automatique, des sous-réseaux sont automatiquement créés. Chacun de ces sous-réseaux porte le même nom que le réseau.
• Un réseau en mode personnalisé ne contient aucun sous-réseau au moment de sa création. Si vous souhaitez créer une instance dans un réseau en mode personnalisé, vous devez d'abord créer un sous-réseau dans cette région et spécifier sa plage d'adresses IP. Un réseau en mode personnalisé peut posséder zéro, un ou plusieurs sous-réseaux par région.

Définir votre région et votre zone

Certaines ressources Compute Engine sont hébergées dans des régions et des zones. Une région est un emplacement géographique spécifique où vous pouvez exécuter vos ressources. Chaque région se compose d'une ou plusieurs zones.

Exécutez les commandes gcloud suivantes dans la console Cloud pour définir la région et la zone par défaut de votre atelier :

gcloud config set compute/zone "{{{project_0.startup_script.primary_zone | Zone}}}" export ZONE=$(gcloud config get compute/zone) gcloud config set compute/region "{{{project_0.startup_script.primary_region | Region}}}" export REGION=$(gcloud config get compute/region)

Tâche 1 : Passer en revue le réseau par défaut

Lorsque vous créez un projet, une configuration réseau par défaut fait que chaque région est dotée d'un réseau de sous-réseaux automatique. Vous pouvez créer jusqu'à quatre réseaux supplémentaires dans un projet, qu'il s'agisse de réseaux de sous-réseaux automatiques ou personnalisés, ou encore d'anciens réseaux.

Chaque instance créée au sein d'un sous-réseau obtient une adresse IPv4 fournie par la plage de ce sous-réseau.

• Passez en revue votre réseau. Cliquez sur le menu de navigation > Réseau VPC.

Pare-feu

Pour savoir comment isoler des sous-réseaux à l'aide de règles de pare-feu, consultez les pages concernant les sous-réseaux et les règles de pare-feu.

Chaque réseau dispose d'un pare-feu par défaut qui bloque l'ensemble du trafic entrant vers les instances. Pour autoriser ce trafic, vous devez créer des règles "allow". En outre, le pare-feu par défaut autorise le trafic en provenance des instances, sauf si vous le configurez de façon qu'il bloque les connexions sortantes à l'aide d'une configuration "egress". Vous pouvez donc créer par défaut des règles "allow" pour le trafic entrant que vous souhaitez laisser passer, et des règles "deny" pour le trafic sortant que vous souhaitez restreindre. Vous avez également la possibilité de définir une règle de refus par défaut pour le trafic sortant afin d'empêcher toute connexion externe.

De manière générale, il est préférable de configurer la règle de pare-feu la moins permissive possible, adaptée au trafic que vous souhaitez laisser passer. Par exemple, si vous avez besoin d'autoriser le trafic à accéder à des instances spécifiques, mais de l'empêcher d'accéder à d'autres, vous devez créer des règles n'autorisant le trafic que vers les instances en question. Cette configuration plus restrictive est bien plus prévisible qu'une règle de pare-feu étendue autorisant le trafic à accéder à toutes les instances. Si vous souhaitez que certaines règles "deny" prévalent sur certaines règles "allow", vous pouvez assigner un niveau de priorité à chacune d'elles. Ainsi, la règle ayant la valeur la plus faible (et la priorité la plus élevée) sera évaluée en premier. En créant des ensembles complexes et étendus de règles de priorité, vous avez la possibilité d'autoriser ou de bloquer le trafic non souhaité.

Le réseau par défaut définit automatiquement des règles de pare-feu, décrites ci-dessous. Les réseaux manuellement créés, quel que soit leur type, ne définissent pas automatiquement de règles de pare-feu. Vous devez donc définir vous-même les règles de pare-feu dont vous avez besoin pour vos réseaux, hormis le réseau par défaut.

Voici les règles de pare-feu de trafic entrant automatiquement définies pour le réseau par défaut :

default-allow-internal	Autorise les connexions réseau à partir de tous les ports et protocoles entre les instances du réseau.
default-allow-ssh	Autorise les connexions SSH à partir de toutes les sources vers toutes les instances du réseau via le port TCP 22.
default-allow-rdp	Autorise les connexions RDP à partir de toutes les sources vers toutes les instances du réseau via le port TCP 3389.
default-allow-icmp	Autorise le trafic ICMP à partir de toutes les sources vers toutes les instances du réseau.

• Pour consulter les règles de pare-feu par défaut, accédez à la console, puis cliquez sur le menu de navigation > Réseau VPC > Pare-feu.

Routes de réseau

Tous les réseaux disposent de routes automatiquement créées qui dirigent le trafic vers Internet (route par défaut) et vers les plages d'adresses IP du réseau. Les noms des routes sont générés automatiquement et diffèrent pour chaque projet.

• Pour consulter les routes par défaut, cliquez sur le menu de navigation > Réseau VPC > Routes.

Tâche 2 : Créer un réseau personnalisé

Créer un réseau composé de plages de sous-réseaux personnalisées

Lorsque vous affectez manuellement des plages de sous-réseaux, vous créez tout d'abord un réseau de sous-réseaux personnalisé, puis les sous-réseaux que vous souhaitez utiliser au sein d'une région. Vous n'avez pas besoin de spécifier immédiatement (ni même du tout) de sous-réseaux pour chaque région. Toutefois, vous ne pouvez pas créer d'instances dans une région ne comportant pas de sous-réseaux.

Lorsque vous créez un sous-réseau, son nom doit être unique dans le projet pour la région, même s'il est utilisé dans plusieurs réseaux. Le même nom peut apparaître deux fois dans un projet tant que les deux sous-réseaux se situent dans une région différente. Comme les sous-réseaux ne disposent ni de plage IPv4 au niveau du réseau, ni d'adresse IP de passerelle, ces informations n'apparaissent pas.

Vous pouvez créer votre réseau personnalisé à l'aide de la console ou de Cloud Shell. Nous allons vous expliquer la marche à suivre avec les deux méthodes, mais c'est à vous de décider celle que vous allez employer lors de cet atelier. Par exemple, vous ne pouvez pas effectuer une section en suivant les instructions relatives à la console, puis réaliser les étapes de la même section à l'aide de la ligne de commande gcloud.

Tâche 3 : Créer un réseau personnalisé à l'aide de la console

Remarque : Si vous préférez utiliser la ligne de commande, ignorez cette étape et passez à la section Créer un réseau personnalisé à l'aide de Cloud Shell.

1. Pour créer un réseau personnalisé, cliquez sur le menu de navigation > Réseau VPC.

2. Cliquez sur Créer un réseau VPC et nommez-le taw-custom-network.

3. Dans l'onglet Personnalisé, créez les éléments suivants :

   • Nom du sous-réseau : subnet-
   • Région :
   • Plage d'adresses IP : 10.0.0.0/16

4. Cliquez sur OK.

   

5. Cliquez sur Ajouter un sous-réseau et ajoutez deux autres sous-réseaux dans leur région respective :

   • subnet-, , 10.1.0.0/16
   • subnet-, , 10.2.0.0/16

6. Cliquez sur Créer pour terminer la procédure.

À ce stade, le réseau dispose de routes vers Internet et vers les instances que vous êtes susceptible de créer. Il ne possède toutefois aucune règle de pare-feu autorisant l'accès aux instances, même depuis d'autres instances. Pour autoriser l'accès, vous devez créer des règles de pare-feu.

Passez à la section Ajouter des règles de pare-feu.

Tâche 4 : Créer un réseau personnalisé à l'aide de Cloud Shell

Remarque : Si vous venez de créer un réseau à partir de la console, n'effectuez pas le même exercice à l'aide de Cloud Shell. Recommencez plutôt l'atelier depuis le début pour apprendre à utiliser la ligne de commande gcloud.

• Saisissez la commande suivante dans Cloud Shell pour créer le réseau personnalisé :

gcloud compute networks create taw-custom-network --subnet-mode custom

Résultat :

NAME MODE IPV4_RANGE GATEWAY_IPV4 taw-custom-network custom Les instances de ce réseau ne seront pas accessibles à moins que vous ne créiez des règles de pare-feu. Vous pouvez par exemple autoriser l'ensemble du trafic interne entre les instances ainsi que les connexions SSH, RDP et ICMP en exécutant la commande suivante : $ gcloud compute firewall-rules create --network taw-custom-network --allow tcp,udp,icmp --source-ranges $ gcloud compute firewall-rules create --network taw-custom-network --allow tcp:22,tcp:3389,icmp

C'est maintenant le moment de créer des sous-réseaux pour votre nouveau réseau personnalisé. Vous allez en créer trois.

1. Créez "subnet-" avec un préfixe IP :

gcloud compute networks subnets create subnet-{{{project_0.startup_script.primary_region | Region}}} \ --network taw-custom-network \ --region {{{project_0.startup_script.primary_region | Region}}} \ --range 10.0.0.0/16

Résultat :

Created [https://www.googleapis.com/compute/v1/projects/cloud-network-module-101/regions/{{{project_0.startup_script.primary_region | Region}}}/subnetworks/subnet-{{{project_0.startup_script.primary_region | Region}}}]. NAME REGION NETWORK RANGE subnet-{{{project_0.startup_script.primary_region | Region}}} {{{project_0.startup_script.primary_region | Region}}} taw-custom-network 10.0.0.0/16

2. Créez "subnet-" avec un préfixe IP :

gcloud compute networks subnets create subnet-{{{project_0.startup_script.secondary_region | Region}}} \ --network taw-custom-network \ --region {{{project_0.startup_script.secondary_region | Region}}} \ --range 10.1.0.0/16

Résultat :

Created [https://www.googleapis.com/compute/v1/projects/cloud-network-module-101/regions/{{{project_0.startup_script.secondary_region | Region}}}/subnetworks/subnet-{{{project_0.startup_script.secondary_region | Region}}}]. NAME REGION NETWORK RANGE subnet-{{{project_0.startup_script.secondary_region | Region}}} {{{project_0.startup_script.secondary_region | Region}}} taw-custom-network 10.1.0.0/16

3. Créez "subnet-" avec un préfixe IP :

gcloud compute networks subnets create subnet-{{{project_0.startup_script.third_region | Region}}} \ --network taw-custom-network \ --region {{{project_0.startup_script.third_region | Region}}} \ --range 10.2.0.0/16

Résultat :

Created [https://www.googleapis.com/compute/v1/projects/cloud-network-module-101/regions/{{{project_0.startup_script.third_region | Region}}}/subnetworks/subnet-{{{project_0.startup_script.third_region | Region}}}]. NAME REGION NETWORK RANGE subnet-{{{project_0.startup_script.secondary_region | Region}}} {{{project_0.startup_script.secondary_region | Region}}} taw-custom-network 10.2.0.0/16

4. Affichez la liste de vos réseaux :

gcloud compute networks subnets list \ --network taw-custom-network

Si vous avez créé un réseau de sous-réseaux automatique dans la section précédente, ceux-ci seront également listés.

Résultat :

NAME REGION NETWORK RANGE subnet-{{{project_0.startup_script.third_region | Region}}} {{{project_0.startup_script.third_region | Region}}} taw-custom-network 10.1.0.0/16 subnet-{{{project_0.startup_script.secondary_region | Region}}} {{{project_0.startup_script.secondary_region | Region}}} taw-custom-network 10.2.0.0/16 subnet-{{{project_0.startup_script.primary_region | Region}}} {{{project_0.startup_script.primary_region | Region}}} taw-custom-network 10.0.0.0/16

À ce stade, le réseau dispose de routes vers Internet et vers les instances que vous êtes susceptible de créer. Il ne possède toutefois aucune règle de pare-feu autorisant l'accès aux instances, même depuis d'autres instances. Pour autoriser l'accès, vous devez créer des règles de pare-feu.

Tâche 5 : Ajouter des règles de pare-feu

Pour autoriser l'accès aux instances de VM, vous devez appliquer des règles de pare-feu. Nous allons effectuer cette action à l'aide d'un tag d'instance. Ces règles s'appliqueront à toutes les VM utilisant le même tag d'instance.

Remarque : Les réseaux et pare-feu utilisent les tags d'instance pour appliquer certaines règles de pare-feu aux instances de VM taguées. Par exemple, si plusieurs instances effectuent la même tâche (telle que desservir un site Web volumineux), vous pouvez leur attribuer un tag sous la forme d'un mot ou terme partagé, que vous pouvez ensuite utiliser pour autoriser l'accès HTTP à ces instances via une règle de pare-feu.

Et comme les tags s'appliquent également au serveur de métadonnées, vous pouvez les utiliser pour les applications en cours d'exécution sur vos instances.

• Tout d'abord, configurez le pare-feu de façon à autoriser les requêtes Internet HTTP. Vous allez ensuite ajouter d'autres règles. Vous pouvez créer ces règles de pare-feu à l'aide de la console ou de Cloud Shell.

Ajouter des règles de pare-feu à l'aide de la console

1. Dans la console, accédez à Réseaux VPC depuis le menu, puis cliquez sur le réseau taw-custom-networking :

2. Cliquez sur l'onglet Pare-feu, puis sur Ajouter une règle de pare-feu.

3. Saisissez les informations suivantes :

Champ	Valeur	Commentaires
Nom	nw101-allow-http	Nom de la nouvelle règle
Cibles	Tags cibles spécifiés	Instances auxquelles s'applique la règle de pare-feu
Tags cibles	http	Tag que nous avons créé
Filtre source	Plages IPv4	Nous allons ouvrir le pare-feu à toutes les adresses IP provenant d'Internet.
Plages IPv4 sources	0.0.0.0/0	Vous allez ouvrir le pare-feu à toutes les adresses IP provenant d'Internet.
Protocoles et ports	Sélectionnez Protocoles et ports spécifiés, cochez la case tcp, puis saisissez 80.	HTTP uniquement

Votre écran ressemblera à ceci :

4. Cliquez sur Créer et laissez la commande s'exécuter. Vous allez ensuite créer les règles de pare-feu supplémentaires dont vous avez besoin.

Ajouter des règles de pare-feu à l'aide de Cloud Shell

Remarque : Si vous venez de créer un réseau à partir de la console, n'effectuez pas le même exercice à l'aide de Cloud Shell. Recommencez plutôt l'atelier depuis le début pour apprendre à utiliser la ligne de commande gcloud.

• Pour créer des règles de pare-feu dans Cloud Shell, exécutez la commande suivante :

gcloud compute firewall-rules create nw101-allow-http \ --allow tcp:80 --network taw-custom-network --source-ranges 0.0.0.0/0 \ --target-tags http

Résultat :

Créer des règles de pare-feu supplémentaires

Ces règles de pare-feu supplémentaires vont autoriser les connexions ICMP, SSH, RDP ainsi que les communications internes. Vous pouvez les créer à l'aide de la console ou de Cloud Shell. Veillez à utiliser une méthode ou l'autre pour chaque type de règle de pare-feu : vous ne pouvez pas employer les deux à la fois.

• ICMP

Champ	Valeur	Commentaires
Nom	nw101-allow-icmp	Nom de la nouvelle règle
Cibles	Tags cibles spécifiés	À sélectionner dans la liste déroulante "Cibles"
Tags cibles	règles	tag
Filtre source	Plages IPv4	Nous allons ouvrir le pare-feu à toutes les adresses IP de cette liste.
Plages IPv4 sources	0.0.0.0/0	Nous allons ouvrir le pare-feu à toutes les adresses IP provenant d'Internet.
Protocoles et ports	Sélectionnez Protocoles et ports spécifiés, Autres protocoles, puis saisissez icmp.	Protocoles et ports auxquels s'applique le pare-feu

(Commandes Cloud Shell)

gcloud compute firewall-rules create "nw101-allow-icmp" --allow icmp --network "taw-custom-network" --target-tags rules

• Communications internes

Champ	Valeur	Commentaires
Nom	nw101-allow-internal	Nom de la nouvelle règle
Cibles	Toutes les instances du réseau	À sélectionner dans la liste déroulante "Cibles"
Filtre source	Plages IPv4	Filtre permettant d'appliquer la règle à des sources de trafic spécifiques
Plages IPv4 sources	10.0.0.0/16, 10.1.0.0/16, 10.2.0.0/16	Nous allons ouvrir le pare-feu à toutes les adresses IP provenant d'Internet.
Protocoles et ports	Sélectionnez Protocoles et ports spécifiés, puis tcp, et saisissez 0-65535 ; cochez la case udp, saisissez 0-65535 ; cochez la case Autres protocoles, puis saisissez icmp.	Autorise Tcp:0-65535, udp:0-65535 et ICMP

(Commandes Cloud Shell)

gcloud compute firewall-rules create "nw101-allow-internal" --allow tcp:0-65535,udp:0-65535,icmp --network "taw-custom-network" --source-ranges "10.0.0.0/16","10.2.0.0/16","10.1.0.0/16"

• SSH

Champ	Valeur	Commentaires
Nom	nw101-allow-ssh	Nom de la nouvelle règle
Cibles	Tags cibles spécifiés	ssh
Tags cibles	ssh	Instances auxquelles vous appliquez la règle de pare-feu
Filtre source	Plages IPv4	Filtre permettant d'appliquer la règle à des sources de trafic spécifiques
Plages IPv4 sources	0.0.0.0/0	Nous allons ouvrir le pare-feu à toutes les adresses IP provenant d'Internet.
Protocoles et ports	Sélectionnez Protocoles et ports spécifiés, cochez la case tcp, puis saisissez 22.	Autorise tcp:22

(Commandes Cloud Shell)

gcloud compute firewall-rules create "nw101-allow-ssh" --allow tcp:22 --network "taw-custom-network" --target-tags "ssh"

• RDP

Champ	Valeur	Commentaires
Nom	nw101-allow-rdp	Nom de la nouvelle règle
Cibles	Toutes les instances du réseau	À sélectionner dans la liste déroulante "Cibles"
Filtre source	Plages IPv4	Filtrer les adresses IP
Plages IPv4 sources	0.0.0.0/0	Nous allons ouvrir le pare-feu à toutes les adresses IP provenant d'Internet.
Protocoles et ports	Sélectionnez Protocoles et ports spécifiés, cochez la case tcp, puis saisissez 3389.	Autorise tcp:3389

(Commandes Cloud Shell)

gcloud compute firewall-rules create "nw101-allow-rdp" --allow tcp:3389 --network "taw-custom-network"

• Sur la console, vérifiez les règles de pare-feu de votre réseau. Votre écran devrait ressembler à ceci :

Remarque : Qu'en est-il des routes visibles dans la console réseau ?

Les fonctionnalités de mise en réseau Google Cloud utilisent des routes pour rediriger les paquets entre les sous-réseaux et vers Internet. Lorsqu'un sous-réseau est créé (ou précréé) dans votre réseau, des routes sont automatiquement générées dans chaque région pour permettre aux paquets de circuler entre les sous-réseaux. Ces routes ne peuvent pas être modifiées.

Vous pouvez créer des routes supplémentaires afin d'envoyer du trafic à une instance, à une passerelle VPN ou à une passerelle Internet par défaut. Ces routes peuvent être modifiées de façon à s'adapter à l'architecture réseau souhaitée. Les routes et les pare-feu fonctionnent ensemble pour s'assurer que votre trafic atteint la bonne destination.

Cliquez sur Vérifier ma progression pour valider l'objectif.

Créer un réseau personnalisé, des sous-réseaux et des règles de pare-feu

Tâche 6 : Accéder à vos VM d'atelier et vérifier la latence

• Dans le menu de gauche, cliquez sur Réseaux VPC pour afficher l'ensemble de votre réseau. Le réseau "taw-custom-network" dispose de trois sous-réseaux, et vos règles de pare-feu ont été appliquées.

Votre écran devrait ressembler à ceci :

Vous allez maintenant créer une VM dans chaque sous-réseau et vous assurer que vous pouvez vous y connecter.

Créer une VM dans chaque zone

Dans cette section de l'atelier, vous allez travailler dans Cloud Shell.

1. Exécutez cette commande pour créer une instance nommée us-test-01 dans le sous-réseau "subnet-" :

gcloud compute instances create us-test-01 \ --subnet subnet-{{{project_0.startup_script.primary_region | Region}}} \ --zone {{{project_0.startup_script.primary_zone | ZONE}}} \ --machine-type e2-standard-2 \ --tags ssh,http,rules

Veillez à bien noter l'adresse IP externe : elle vous servira plus tard au cours de cet atelier.

Résultat :

Created [https://www.googleapis.com/compute/v1/projects/cloud-network-module-101/zones/{{{project_0.startup_script.primary_zone | ZONE}}}/instances/us-test-01]. NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS us-test-01 {{{project_0.startup_script.primary_zone | ZONE}}} e2-standard-2 10.0.0.2 104.198.230.22 RUNNING

2. Vous allez maintenant créer les VM "us-test-02" et "us-test-03" dans les sous-réseaux correspondants :

gcloud compute instances create us-test-02 \ --subnet subnet-{{{project_0.startup_script.secondary_region | REGION}}} \ --zone {{{project_0.startup_script.secondary_zone | ZONE}}} \ --machine-type e2-standard-2 \ --tags ssh,http,rules gcloud compute instances create us-test-03 \ --subnet subnet-{{{project_0.startup_script.third_region | REGION}}} \ --zone {{{project_0.startup_script.third_zone | ZONE}}} \ --machine-type e2-standard-2 \ --tags ssh,http,rules

Cliquez sur Vérifier ma progression pour valider l'objectif.

Créer trois instances dans les zones spécifiées pour procéder aux tests Traceroute et de performance

Vérifier la connexion à votre VM

Vous allez maintenant effectuer quelques exercices pour tester la connexion à vos VM.

1. Revenez à la console et accédez à Compute Engine.

2. Cliquez sur le bouton SSH correspondant à l'instance us-test-01. Cette action entraînera l'ouverture d'une connexion SSH vers l'instance dans une nouvelle fenêtre.

3. Dans la fenêtre SSH de l'instance us-test-01, saisissez la commande suivante pour lancer un écho ICMP vers us-test-02, en ajoutant dans la ligne l'adresse IP externe de la VM :

ping -c 3 <us-test-02-external-ip-address> Remarque : Vous pouvez identifier l'adresse IP externe de vos machines virtuelles dans le champ Adresse IP externe de l'onglet du navigateur Compute Engine.

Vos adresses IP seront différentes de celles de l'image.

4. Exécutez cette commande pour lancer un écho ICMP vers us-test-03, en ajoutant dans la ligne l'adresse IP externe de la VM :

ping -c 3 <us-test-03-external-ip-address>

Exemple de résultat :

PING 35.187.149.67 (35.187.149.67) 56(84) bytes of data. 64 bytes from 35.187.149.67: icmp_seq=1 ttl=76 time=152 ms 64 bytes from 35.187.149.67: icmp_seq=2 ttl=76 time=152 ms 64 bytes from 35.187.149.67: icmp_seq=3 ttl=76 time=152 ms

5. Vérifiez maintenant que la connexion SSH vers les instances us-test-02 et us-test-03 fonctionne également. Lancez un écho ICMP vers us-test-01.

Utiliser une commande ping pour mesurer la latence

Utilisez une commande ping pour mesurer la latence entre les instances dans l'ensemble des régions.

• Pour observer la latence depuis la région Centre des États-Unis jusqu'à la région Europe de l'Ouest, ouvrez une fenêtre SSH sur l'instance us-test-01, puis exécutez la commande suivante :

ping -c 3 us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}}

Résultat de la commande :

PING us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}}.c.cloud-network-module-101.internal (10.2.0.2) 56(84) bytes of data. 64 bytes from us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}}.c.cloud-network-module-101.internal (10.2.0.2): icmp_seq=1 ttl=64 time=105 ms 64 bytes from us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}}.c.cloud-network-module-101.internal (10.2.0.2): icmp_seq=2 ttl=64 time=104 ms 64 bytes from us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}}.c.cloud-network-module-101.internal (10.2.0.2): icmp_seq=3 ttl=64 time=104 ms

La latence obtenue correspond au "délai aller-retour" (DAR), indiquant le temps que le paquet met à se rendre d'us-test-01 à us-test-02.

La commande ping teste la connectivité à l'aide de messages ICMP de requête d'écho et de réponse d'écho.

Remarque : Questions à se poser

Quelle est la latence observée entre les régions ? Quel résultat attendriez-vous dans des conditions idéales ? Quelle est la particularité de la connexion entre "us-test-02" et "us-test-03" ? Remarque : Concernant le DNS interne : Comment le DNS est-il fourni pour les instances de VM ?

Chaque instance dispose d'un serveur de métadonnées faisant également office de résolveur DNS pour cette instance. Les résolutions DNS sont effectuées pour les noms d'instance. Le serveur de métadonnées, quant à lui, stocke toutes les informations DNS pour le réseau local et interroge les serveurs DNS publics de Google concernant les adresses situées en dehors du réseau local.

Le nom de domaine complet interne d'une instance est au format "hostName.[ZONE].c.[PROJECT_ID].internal".

Vous pouvez toujours vous connecter d'une instance à une autre en utilisant ce nom de domaine complet. Si vous voulez vous connecter à une instance en utilisant, par exemple, uniquement le nom d'hôte (hostName), vous avez besoin des informations fournies par le résolveur DNS interne qui est intégré à Compute Engine.

Tâche 7 : Exécuter les tests Traceroute et de performances

Exercice facultatif

Traceroute est un outil permettant de retracer le chemin entre deux hôtes. Un traceroute peut s'avérer très utile pour identifier initialement de nombreux types de problèmes réseau. C'est pour cette raison que les ingénieurs réseau et les techniciens d'assistance vous demandent souvent d'exécuter ce type de test pour diagnostiquer des problèmes réseau.

Remarque : Fonctionnalités

Traceroute affiche l'ensemble des sauts de la couche 3 (couche de routage) entre les hôtes. Pour ce faire, l'outil envoie des paquets à l'emplacement distant en augmentant progressivement la valeur TTL (Time To Live), qui commence à 1. Le champ TTL est un champ du paquet IP dont la valeur se voit réduite de 1 à chaque routeur rencontré. Lorsque la valeur TTL atteint zéro, le paquet est supprimé et un message ICMP "TTL exceeded" (Valeur TTL dépassée) est renvoyé à l'expéditeur. Cette opération permet d'éviter les boucles de routage : comme le champ TTL atteint zéro au bout d'un certain temps, les paquets ne peuvent pas emprunter une boucle infinie. Par défaut, le système d'exploitation définit une valeur TTL élevée (64, 128, 255 ou une valeur semblable). Celle-ci ne devrait donc être atteinte que dans une situation anormale.

L'outil traceroute envoie donc d'abord des paquets dotés d'une valeur TTL correspondant à 1, puis 2, etc. Ceux-ci expirent au premier routeur rencontré, puis au deuxième, et ainsi de suite. L'outil affiche ensuite le nom/l'adresse IP du saut intermédiaire en utilisant l'adresse IP/l'hôte source du message "TTL exceeded" (Valeur TTL dépassée) qui est renvoyé. Lorsque la valeur TTL est suffisamment élevée, le paquet atteint sa destination, qui répond à son tour.

Le type de paquet envoyé varie selon la mise en œuvre. Sous Linux, des paquets UDP sont envoyés vers un port élevé inutilisé. La destination finale renvoie donc un message "ICMP Port Unreachable" (Port ICMP injoignable). Par défaut, Windows et l'outil MTR transmettent des requêtes d'écho ICMP (comme des commandes ping). La destination finale renvoie donc une réponse d'écho ICMP.

Essayez cette procédure en configurant un traceroute sur l'une de vos machines virtuelles.

1. Pour cette étape, reprenez les VM us-test-01 et us-test-02, et connectez-vous en SSH à chacune d'elles.

2. Installez les outils de performances dans la fenêtre SSH de l'instance us-test-01 :

sudo apt-get update sudo apt-get -y install traceroute mtr tcpdump iperf whois host dnsutils siege traceroute www.icann.org

3. Essayez quelques autres destinations et testez également d'autres sources :

   • Machines virtuelles de la même région ou d'une autre région (eu1-vm, asia1-vm, w2-vm)
   • www.wikipedia.org
   • www.adcash.com
   • bad.horse (donne de meilleurs résultats si vous augmentez la valeur TTL maximale, par exemple traceroute -m 255 bad.horse)
   • Toute autre source à laquelle vous pourriez penser

4. Pour arrêter le traceroute, appuyez sur les touches Ctrl+C dans la fenêtre SSH et revenez à la ligne de commande.

Remarque : Questions à se poser

Qu'avez-vous remarqué dans les différents traceroutes ?

Tâche 8 : Tester les performances à l'aide de l'outil iPerf

Entre deux hôtes

Exercice facultatif

Lorsque vous testez les performances entre deux hôtes à l'aide d'iperf, l'un de ces deux hôtes doit être configuré en tant que serveur iPerf pour accepter les connexions.

Remarque : Les commandes ci-dessous entraînent le transfert de plusieurs gigaoctets de trafic entre diverses régions. Ces données vous sont facturées conformément aux tarifs de sortie Internet. Gardez cela à l'esprit lorsque vous utilisez ces commandes. Si votre projet ne figure pas sur la liste d'autorisation ou si vous n'êtes pas en période d'essai, vous pouvez passer cette étape ou vous contenter de la survoler. (Les coûts ne devraient pas s'élever à plus de 1 USD.)

Effectuez un test très simple :

1. Connectez-vous en SSH à us-test-02 et installez les outils de performances :

sudo apt-get update sudo apt-get -y install traceroute mtr tcpdump iperf whois host dnsutils siege

2. Connectez-vous en SSH à us-test-01, puis exécutez la commande suivante :

iperf -s #run in server mode

3. Dans la fenêtre SSH de l'instance us-test-02, exécutez la commande iperf suivante :

iperf -c us-test-01.{{{project_0.startup_script.primary_zone | ZONE}}} #run in client mode

Le résultat devrait ressembler à ceci :

Client connecting to eu-vm, TCP port 5001 TCP window size: 45.0 KByte (default) [ 3] local 10.20.0.2 port 35923 connected with 10.30.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 298 MBytes 249 Mbits/sec

4. Lorsque vous avez terminé, appuyez sur les touches Ctrl+C sur l'instance us-test-01 pour arrêter la session côté serveur.

Entre les VM d'une même région

Exercice facultatif

Vous allez maintenant déployer une autre instance (us-test-04) dans une zone différente de celle où se trouve us-test-01. Vous verrez que, dans cette région, la bande passante est limitée par un seuil de sortie de 2 Gbit/s par cœur.

1. Dans Cloud Shell, créez l'instance us-test-04 :

gcloud compute instances create us-test-04 \ --subnet subnet-{{{project_0.startup_script.primary_region | REGION}}} \ --zone {{{project_0.startup_script.primary_zone_1 | ZONE}}} \ --tags ssh,http

2. Connectez-vous en SSH à us-test-04 et installez les outils de performances :

sudo apt-get update sudo apt-get -y install traceroute mtr tcpdump iperf whois host dnsutils siege

Vous atteindrez des limites bien plus faibles entre plusieurs régions, principalement à cause des limites appliquées à la taille de la fenêtre TCP et aux performances en flux unique. Vous pouvez augmenter la bande passante entre les hôtes en utilisant d'autres paramètres, tels que le paramètre UDP.

3. Dans la fenêtre SSH de l'instance us-test-02, exécutez la commande suivante :

iperf -s -u #iperf server side

4. Dans la fenêtre SHH de l'instance us-test-01, exécutez la commande suivante :

iperf -c us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}} -u -b 2G #iperf client side - send 2 Gbits/s

Vous devriez alors atteindre une vitesse supérieure entre l'Europe et les États-Unis. Vous pouvez encore l'améliorer en exécutant d'autres commandes iPerf TCP en parallèle. Faisons le test.

5. Dans la fenêtre SSH de l'instance us-test-01, exécutez la commande suivante :

iperf -s

6. Dans la fenêtre SSH de l'instance us-test-02, exécutez la commande suivante :

iperf -c us-test-01.{{{project_0.startup_script.primary_zone | ZONE}}} -P 20

La bande passante combinée devrait s'approcher de la bande passante maximale possible.

7. Essayez d'autres combinaisons. Si vous utilisez Linux sur votre ordinateur portable, vous pouvez également effectuer des tests avec celui-ci. (Vous pouvez aussi essayer l'outil iPerf3, qui est compatible avec de nombreux systèmes d'exploitation. Cet outil sort toutefois du cadre de cet atelier.)

Comme vous pouvez le constater, l'exécution d'un seul flux TCP (tel qu'une copie de fichier) ne permet pas d'atteindre la bande passante maximale. Vous devez ouvrir plusieurs sessions TCP en parallèle. Ce phénomène est dû à des paramètres TCP, comme la taille de la fenêtre, et à certaines fonctions telles que le démarrage lent.

Pour en savoir plus sur ce point et sur d'autres sujets liés à TCP/IP, consultez TCP/IP Illustrated.

Des outils comme bbcp peuvent vous aider à copier des fichiers le plus rapidement possible en lançant des transferts simultanés et en utilisant une taille de fenêtre configurable.

Tâche 9 : Tester vos connaissances

Terminer l'atelier

Une fois l'atelier terminé, cliquez sur Terminer l'atelier. Votre compte et les ressources utilisées sont alors supprimés de la plate-forme d'atelier.

Si vous le souhaitez, vous pouvez noter l'atelier. Sélectionnez un nombre d'étoiles, saisissez un commentaire, puis cliquez sur Envoyer.

Voici à quoi correspond le nombre d'étoiles que vous pouvez attribuer à un atelier :

• 1 étoile = très insatisfait(e)
• 2 étoiles = insatisfait(e)
• 3 étoiles = ni insatisfait(e), ni satisfait(e)
• 4 étoiles = satisfait(e)
• 5 étoiles = très satisfait(e)

Si vous ne souhaitez pas donner votre avis, vous pouvez fermer la boîte de dialogue.

Pour soumettre des commentaires, suggestions ou corrections, veuillez accéder à l'onglet Assistance.

Atelier suivant

Poursuivez votre apprentissage sur la mise en réseau dans Cloud avec plusieurs réseaux VPC, ou consultez ces suggestions :

• Premiers pas avec Cloud KMS
• Orchestrer le cloud avec Kubernetes

Lorsque vous serez prêt, essayez la quête Networking fundamentals in Google Cloud.

Formations et certifications Google Cloud

Les formations et certifications Google Cloud vous aident à tirer pleinement parti des technologies Google Cloud. Nos cours portent sur les compétences techniques et les bonnes pratiques à suivre pour être rapidement opérationnel et poursuivre votre apprentissage. Nous proposons des formations pour tous les niveaux, à la demande, en salle et à distance, pour nous adapter aux emplois du temps de chacun. Les certifications vous permettent de valider et de démontrer vos compétences et votre expérience en matière de technologies Google Cloud.

Dernière mise à jour du manuel : 11 septembre 2023

Dernier test de l'atelier : 11 septembre 2023

Copyright 2024 Google LLC Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms d'entreprises et de produits peuvent être des marques des entreprises auxquelles ils sont associés.