18 min de lecture

Objectifs d'apprentissage

À la fin de ce module, vous serez en mesure de:

  • Mettre en place des réseaux LAN à plusieurs niveaux et attacher des cartes réseau de serveur de manière déclarative en utilisant les ressources `ionoscloud_lan` et `ionoscloud_nic` Terraform
  • Configurer l'accès internet sortant pour les réseaux LAN privés avec `ionoscloud_natgateway` et des règles SNAT
  • Établir une connectivité hybride de site à site en utilisant la ressource `ionoscloud_vpn_ipsec_gateway`
  • Gérer les zones et les enregistrements DNS en tant que code avec `ionoscloud_dns_zone` et `ionoscloud_dns_record`
  • Composer des réseaux LAN, des cartes réseau, des NAT et des DNS dans une pile de réseau reproductible à trois niveaux pour l'application TaskBoard

Unité 2.2 : Réseau et connectivité en tant que code

Introduction

Dans l'unité 2.1, vous avez provisionné le niveau de calcul de TaskBoard : un serveur API et un worker, chacun démarré avec cloud-init. Ces serveurs sont inutiles jusqu'à ce qu'ils puissent communiquer entre eux, accéder à Internet pour les mises à jour de packages et résoudre un nom d'hôte qui pointe vers le point de terminaison API. C'est le rôle de la couche réseau, et sur IONOS Cloud, chaque partie de celle-ci est une ressource Terraform.

Cette unité construit la pile réseau sous TaskBoard. Vous segmenterez le trafic en un niveau public, un niveau d'application et un niveau de base de données en utilisant des LAN distincts, connecterez les serveurs à ces LAN avec des cartes réseau, donnerez aux niveaux privés un accès sortant contrôlé via une passerelle NAT, et publierez un enregistrement DNS afin que les clients puissent trouver le API. Chaque ressource est déclarative, chaque dépendance est résolue par le graphique de Terraform, et la topologie entière est reproductible à partir d'un seul terraform apply.

1. LANs pour la segmentation réseau

La ressource ionoscloud_lan est la base de la segmentation réseau à l'intérieur d'un centre de données virtuel. Un LAN est un domaine de diffusion de couche 2 limité à un seul centre de données. Vous créez un LAN par niveau afin que le trafic entre les niveaux doive traverser une limite contrôlée plutôt que de partager un réseau plat.

Le seul argument le plus important est public. Un LAN public est connecté à la passerelle Internet d'IONOS et ses cartes réseau reçoivent une adresse IPv4 publique routable de la part du service DHCP de la plateforme. Un LAN privé (public = false) n'a pas de chemin d'accès à Internet, ce qui est exactement ce que vous voulez pour les niveaux d'application et de base de données.

1.1 Définition des trois niveaux

TaskBoard nécessite trois LAN : un LAN public pour l'entrée, un LAN d'application privé pour le API et le worker, et un LAN de base de données privé. Chaque LAN appartient au centre de données que vous avez provisionné dans le Module 1.

resource "ionoscloud_lan" "public" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-public"
  public        = true
}

resource "ionoscloud_lan" "app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-app"
  public        = false
}

resource "ionoscloud_lan" "db" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-db"
  public        = false
}

Terraform attribue à chaque LAN un ID numérique dans le centre de données une fois créé. Vous référencez ces ID à partir de ressources de carte réseau plutôt que de les coder en dur, ce qui permet de conserver la configuration portable entre les environnements.

1.2 Adresse à l'intérieur d'un LAN

La plateforme alloue à chaque LAN un sous-réseau privé avec une taille de sous-réseau par défaut /24, donc un seul LAN vous donne jusqu'à 254 adresses hôtes utilisables. Les LAN privés utilisent des plages RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). La taille MTU Ethernet standard est de 1500 octets, ce qui est important lorsque vous ajustez les tailles de paquets au niveau de l'application ou les charges utiles VPN plus tard dans cette unité.

Vous n'configurez pas le sous-réseau sur le LAN lui-même. Les adresses sont attribuées au niveau de la carte réseau, soit automatiquement par DHCP, soit sous forme d'adresses IP statiques explicites, ce que la section suivante couvrira.

2. Attacher des serveurs avec des cartes réseau (NICs)

Une ionoscloud_nic connecte un serveur à un LAN. Un serveur peut avoir plusieurs cartes réseau (NICs), et c'est précisément ainsi qu'un hôte participe à plus d'un niveau. Le serveur API de TaskBoard, par exemple, nécessite une carte réseau (NIC) sur le LAN public (pour recevoir les requêtes entrantes) et une carte réseau (NIC) sur le LAN de l'application (pour atteindre les niveaux worker et base de données).

La carte réseau (NIC) est l'endroit où vous décidez si une interface reçoit une adresse attribuée par DHCP ou une adresse statique, et si le pare-feu de la plateforme est actif sur cette interface.

2.1 Adressage DHCP et statique

Définissez dhcp = true pour laisser le service DHCP de la plateforme attribuer une adresse. Sur un LAN public, cela attribue également une adresse IPv4 publique routable automatiquement. Pour les niveaux privés où vous souhaitez des adresses prévisibles, fournissez une liste ips explicite à partir de la plage RFC 1918 du LAN.

# Public-facing NIC on the API server: DHCP-assigned public IP
resource "ionoscloud_nic" "api_public" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  lan           = ionoscloud_lan.public.id
  name          = "api-public"
  dhcp          = true
  firewall_active = true
}

# Private NIC on the API server: static address on the app LAN
resource "ionoscloud_nic" "api_app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  lan           = ionoscloud_lan.app.id
  name          = "api-app"
  dhcp          = false
  ips           = ["10.7.1.10"]
}

Le flag firewall_active active le pare-feu par carte réseau (NIC). Lorsqu'il est activé, le pare-feu de la carte réseau (NIC) bloque tout le trafic entrant par défaut et n'autorise le trafic que sur les ports explicitement activés. Le pare-feu de la carte réseau (NIC) est le contrôle de sécurité par interface ; la configuration détaillée des règles et la Network Security Groups sont couvertes dans l'unité 2.3.

2.2 Serveurs multi-cartes réseau (NICs) et appartenance à un niveau

Le worker n'a besoin d'atteindre les niveaux de l'application et de la base de données, il reçoit donc deux cartes réseau (NICs) privées et aucune interface publique du tout.

resource "ionoscloud_nic" "worker_app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.worker.id
  lan           = ionoscloud_lan.app.id
  name          = "worker-app"
  dhcp          = false
  ips           = ["10.7.1.20"]
}

resource "ionoscloud_nic" "worker_db" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.worker.id
  lan           = ionoscloud_lan.db.id
  name          = "worker-db"
  dhcp          = false
  ips           = ["10.7.2.20"]
}

Puisque Terraform voit que chaque carte réseau (NIC) référence à la fois un serveur et un LAN, il ordonne automatiquement la création : centre de données d'abord, puis réseaux locaux et serveurs, puis cartes réseau (NICs). Vous n'écrivez jamais d'ordre explicite depends_on pour cette chaîne. Sans carte réseau (NIC) publique, le worker est inaccessible depuis Internet, ce qui est l'isolement que vous souhaitez pour un processus backend.

3. Accès sortant avec une passerelle NAT

Un centre de données privé LAN n'a pas de route internet. C'est bon pour la sécurité entrante, mais c'est un problème lorsque votre serveur API a besoin de télécharger des mises à jour du système d'exploitation, de récupérer des dépendances ou d'appeler un SaaS API externe. La ressource ionoscloud_natgateway résout ce problème en fournissant une connectivité sortante contrôlée.

La passerelle NAT est SNAT-only (Source NAT). Elle réécrit l'adresse source du trafic sortant à partir d'hôtes privés vers une adresse IP publique que la passerelle possède, et elle bloque automatiquement tout trafic entrant non sollicité. Une seule passerelle peut servir jusqu'à 6 réseaux privés.

3.1 Provisionnement de la passerelle

La passerelle nécessite une ou plusieurs adresses IPv4 publiques réservées, que vous attribuez sous forme de bloc IP. Attachez la passerelle aux LAN dont les hôtes ont besoin de sortir, et définissez l'adresse IP interne à la passerelle qu'elle utilise sur chaque LAN.

resource "ionoscloud_ipblock" "nat" {
  location = ionoscloud_datacenter.taskboard.location
  size     = 1
  name     = "taskboard-nat-ip"
}

resource "ionoscloud_natgateway" "taskboard" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-nat"
  public_ips    = ionoscloud_ipblock.nat.ips

  lans {
    id           = ionoscloud_lan.app.id
    gateway_ips  = ["10.7.1.1/24"]
  }
}

L'appel sous-jacent API correspond à POST /datacenters/{datacenterId}/natgateways. Comme toutes les opérations de provisionnement IONOS, cela est asynchrone ; le fournisseur Terraform interroge la demande jusqu'à ce qu'elle soit terminée avant de signaler la ressource comme créée.

3.2 Règles SNAT

La passerelle ne transmet pas le trafic jusqu'à ce que vous définissiez des règles. Une règle de passerelle NAT spécifie quelles adresses sources privées sont traduites et sur quel protocole. Les règles correspondent à POST /datacenters/{datacenterId}/natgateways/{natGatewayId}/rules.

resource "ionoscloud_natgateway_rule" "app_egress" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  natgateway_id = ionoscloud_natgateway.taskboard.id
  name          = "app-tier-egress"
  type          = "SNAT"
  protocol      = "ALL"
  source_subnet = "10.7.1.0/24"
  public_ip     = ionoscloud_ipblock.nat.ips[0]
}

Le protocole peut être restreint (par exemple à TCP ou UDP) lorsque vous voulez un contrôle plus strict, mais ALL est approprié pour une règle de sortie générale. Notez que la route par défaut n'est pas injectée automatiquement : les hôtes sur le centre de données privé LAN doivent utiliser l'adresse IP de la passerelle (10.7.1.1 ci-dessus) comme passerelle par défaut, que vous configurez généralement via cloud-init ou des options DHCP sur la carte réseau.

4. Connectivité de site à site avec IPSec VPN

Lorsque TaskBoard doit accéder à une ressource dans votre centre de données local, comme un fournisseur d'identité interne, vous reliez les deux réseaux avec la ressource ionoscloud_vpn_ipsec_gateway. Le VPN Gateway prend en charge IPSec et WireGuard ; cette section utilise IPSec pour un tunnel de site à site classique.

IPSec sur IONOS utilise IKEv2 et authentifie les tunnels avec une clé prépartagée (PSK). Le VPN API est régional : chaque passerelle vit derrière un hôte spécifique à la région, tel que https://vpn.de-fra.ionos.com, avec des passerelles IPSec exposées à la ressource /ipsecgateways et leurs tunnels imbriqués sous /ipsecgateways/{gatewayId}/tunnels.

4.1 Passerelle et tunnel

La passerelle nécessite une adresse IP publique réservée IP et une connexion vers le LAN qu'elle sert. Le tunnel définit le pair distant et les sélecteurs de trafic.

resource "ionoscloud_ipblock" "vpn" {
  location = ionoscloud_datacenter.taskboard.location
  size     = 1
  name     = "taskboard-vpn-ip"
}

resource "ionoscloud_vpn_ipsec_gateway" "hybrid" {
  name       = "taskboard-hybrid"
  location   = "de/fra"
  gateway_ip = ionoscloud_ipblock.vpn.ips[0]

  connections {
    datacenter_id = ionoscloud_datacenter.taskboard.id
    lan_id        = ionoscloud_lan.app.id
    ipv4_cidr     = "10.7.1.5/24"  # the gateway's own host address on the app LAN, not the network address
  }
}

resource "ionoscloud_vpn_ipsec_tunnel" "onprem" {
  gateway_id    = ionoscloud_vpn_ipsec_gateway.hybrid.id
  location      = "de/fra"
  name          = "to-onprem"
  remote_host   = "203.0.113.10"

  auth {
    method = "PSK"
    psk {
      key = var.vpn_psk
    }
  }

  cloud_network_cidrs = ["10.7.1.0/24"]
  peer_network_cidrs  = ["192.168.50.0/24"]
}

Gardez le PSK en dehors du contrôle de source. Déclarez-le comme une variable sensible (variable "vpn_psk" { sensitive = true }) et fournissez-le via une variable d'environnement ou un magasin de secrets, jamais comme une valeur littérale dans le fichier .tf.

4.2 Routage à travers le tunnel

Les cloud_network_cidrs et peer_network_cidrs définissent quels sous-réseaux sont accessibles via le tunnel. Le trafic en provenance de 10.7.1.0/24 destiné à 192.168.50.0/24 est chiffré et transmis ; tout le reste suit la routage normal. Assurez-vous de correspondre exactement à ces CIDRs avec votre configuration sur site, car une erreur de correspondance est la raison la plus courante pour laquelle un tunnel est activé mais ne transporte aucun trafic.

5. DNS as Code

Un ensemble de réseau que personne ne peut trouver est incomplet. Les ressources ionoscloud_dns_zone et ionoscloud_dns_record vous permettent de publier DNS entièrement à partir de Terraform, de sorte que le nom d'hôte pour le API de TaskBoard est versionné aux côtés de l'infrastructure qui le sert. IONOS Cloud DNS est servi à partir d'un réseau Anycast, donc les enregistrements se résolvent à partir du point de présence le plus proche.

5.1 Zones et enregistrements

Créez la zone, puis ajoutez des enregistrements pointant vers le IP public alloué à la carte réseau publique du serveur API.

resource "ionoscloud_dns_zone" "taskboard" {
  name        = "taskboard.example.com"
  description = "TaskBoard application zone"
  enabled     = true
}

resource "ionoscloud_dns_record" "api" {
  zone_id = ionoscloud_dns_zone.taskboard.id
  name    = "api"
  type    = "A"
  content = ionoscloud_nic.api_public.ips[0]
  ttl     = 300
  enabled = true
}

Les valeurs TTL doivent être comprises entre 60 et 604800 secondes. Cloud DNS prend en charge un large éventail de types d'enregistrements, notamment A, AAAA, CNAME, ALIAS, MX, NS, SOA, SRV, TXT, CAA, et HTTPS. Pour créer un enregistrement apex (zone Root), laissez le champ de nom d'enregistrement vide au lieu d'utiliser @.

L'appel correspondant API est publié sur https://dns.<region>.ionos.com/zones pour les zones et sur le chemin /records de la zone pour les enregistrements, par exemple POST https://dns.de-fra.ionos.com/zones/{zoneId}/records.

5.2 Étendue de Cloud DNS et où se situe la bascule automatique

Cloud DNS est un service DNS autoritaire : il publie et résout vos zones et enregistrements. Il ne sonde pas vos backends ni n'effectue de bascule automatique basée sur les vérifications de santé, donc un enregistrement continue de se résoudre vers sa cible configurée, quel que soit l'état de cette cible. Ne vous fiez pas à DNS pour contourner un backend défaillant. Pour une bascule automatique, placez un Load Balancer géré devant vos cibles et pointez l'enregistrement DNS vers le Load Balancer, de sorte que les vérifications de santé et la suppression de cible se produisent au niveau de l'équilibrage de charge introduit dans l'unité 2.3.

API Référence Quick Card

Points de terminaison clés API pour la provision de réseau et de connectivité :

Méthode Point de terminaison Description
POST /datacenters/{datacenterId}/lans Créer un LAN
POST /datacenters/{datacenterId}/servers/{serverId}/nics Attacher une carte réseau à un serveur
POST /datacenters/{datacenterId}/natgateways Créer une passerelle NAT
POST /datacenters/{datacenterId}/natgateways/{natGatewayId}/rules Créer une règle SNAT
POST /ipsecgateways Créer un tunnel IPSec VPN Gateway (hôte régional)
POST /zones Créer une zone DNS (hôte DNS régional)
POST /zones/{zoneId}/records Créer un enregistrement DNS

URL de base (Cloud API) : https://api.ionos.com/cloudapi/v6 Hôte régional DNS : https://dns.de-fra.ionos.com Hôte régional VPN : https://vpn.de-fra.ionos.com Authentification : Authorization: Bearer <token>

Laboratoire de code

Objectif : Construire la pile réseau à trois niveaux de TaskBoard avec Terraform : réseaux LAN publics, d'application et de base de données, cartes réseau de serveur, une passerelle NAT pour la sortie privée, et un enregistrement DNS pour le API. Ensuite, vérifiez la connectivité entre les niveaux.

Prérequis :

  • Compte IONOS Cloud avec jeton API (IONOS_TOKEN exporté)
  • Terraform avec le fournisseur ionoscloud installé
  • Le centre de données TaskBoard et les serveurs de l'unité 2.1 déjà dans l'état

Étape 1 : Définir les trois réseaux LAN

resource "ionoscloud_lan" "public" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-public"
  public        = true
}
resource "ionoscloud_lan" "app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-app"
  public        = false
}
resource "ionoscloud_lan" "db" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-db"
  public        = false
}

Sortie attendue :

Plan: 3 to add, 0 to change, 0 to destroy.

Étape 2 : Attacher les cartes réseau de serveur API

resource "ionoscloud_nic" "api_public" {
  datacenter_id   = ionoscloud_datacenter.taskboard.id
  server_id       = ionoscloud_server.api.id
  lan             = ionoscloud_lan.public.id
  dhcp            = true
  firewall_active = true
}
resource "ionoscloud_nic" "api_app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  lan           = ionoscloud_lan.app.id
  dhcp          = false
  ips           = ["10.7.1.10"]
}

Sortie attendue :

ionoscloud_nic.api_public: Creation complete after 1m12s

Étape 3 : Réserver un bloc IP et créer la passerelle NAT

resource "ionoscloud_ipblock" "nat" {
  location = ionoscloud_datacenter.taskboard.location
  size     = 1
  name     = "taskboard-nat-ip"
}
resource "ionoscloud_natgateway" "taskboard" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-nat"
  public_ips    = ionoscloud_ipblock.nat.ips
  lans {
    id          = ionoscloud_lan.app.id
    gateway_ips = ["10.7.1.1/24"]
  }
}

Sortie attendue :

ionoscloud_natgateway.taskboard: Creation complete after 2m03s

Étape 4 : Ajouter la règle de sortie SNAT

resource "ionoscloud_natgateway_rule" "app_egress" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  natgateway_id = ionoscloud_natgateway.taskboard.id
  name          = "app-tier-egress"
  type          = "SNAT"
  protocol      = "ALL"
  source_subnet = "10.7.1.0/24"
  public_ip     = ionoscloud_ipblock.nat.ips[0]
}

Sortie attendue :

ionoscloud_natgateway_rule.app_egress: Creation complete

Étape 5 : Publier l'enregistrement DNS

resource "ionoscloud_dns_zone" "taskboard" {
  name    = "taskboard.example.com"
  enabled = true
}
resource "ionoscloud_dns_record" "api" {
  zone_id = ionoscloud_dns_zone.taskboard.id
  name    = "api"
  type    = "A"
  content = ionoscloud_nic.api_public.ips[0]
  ttl     = 300
  enabled = true
}

Sortie attendue :

ionoscloud_dns_record.api: Creation complete

Étape 6 : Appliquer et vérifier la sortie d'un hôte privé

terraform apply -auto-approve
# SSH to the API server via its public IP, then test outbound through NAT:
ssh root@$(terraform output -raw api_public_ip)
curl -s https://ifconfig.io   # should return the NAT gateway public IP

Sortie attendue :

<the public IP from ionoscloud_ipblock.nat>

Étape 7 : Vérifier la connectivité entre les niveaux

# From the API server, reach the worker on the app LAN:
ping -c 2 10.7.1.20

Sortie attendue :

2 packets transmitted, 2 received, 0% packet loss

Liste de validation :

  • [ ] Trois réseaux LAN créés (1 public, 2 privés)
  • [ ] Le serveur API possède à la fois une carte réseau publique et une carte réseau de niveau d'application
  • [ ] L'hôte privé atteint Internet via la passerelle NAT publique IP
  • [ ] Le serveur API et le worker communiquent sur le réseau LAN d'application
  • [ ] L'enregistrement DNS A se résout en l'adresse IP publique API

Nettoyage :

terraform destroy -auto-approve

Erreurs courantes

Erreurs de développement à éviter avec la mise en réseau sur IONOS Cloud :

  1. S'attendre à ce que des hôtes LAN privés aient accès à Internet sans une passerelle NAT

    • Problème : Votre serveur API sur un LAN privé ne peut pas apt update ou appeler des API externes, et les connexions expirent simplement.
    • Pourquoi cela se produit-il : Un LAN privé (public = false) n'a pas de route Internet. La route par défaut n'est pas injectée automatiquement même après avoir attaché une passerelle NAT.
    • Correction : Mettre en place un ionoscloud_natgateway avec une règle SNAT, puis définir la passerelle par défaut des hôtes sur la passerelle IP via cloud-init ou les options DHCP :
    lans {
  id          = ionoscloud_lan.app.id
  gateway_ips = ["10.7.1.1/24"]
}

  2. Sélecteurs de trafic VPN non correspondants

    • Problème : Le tunnel IPSec est actif, mais aucun paquet ne le traverse et les hôtes sur site restent inaccessibles.
    • Pourquoi cela se produit-il : Les cloud_network_cidrs et peer_network_cidrs ne correspondent pas exactement aux sous-réseaux configurés sur le pair distant, donc le trafic n'est pas sélectionné pour le chiffrement.
    • Correction : Aligner les CIDR des deux côtés avec précision. Le côté IONOS doit répertorier son propre sous-réseau LAN et le sous-réseau du pair qui reflète la configuration de l'appareil distant :
    cloud_network_cidrs = ["10.7.1.0/24"]
peer_network_cidrs  = ["192.168.50.0/24"]

  3. Utilisation d'un TTL non valide sur un enregistrement DNS

    • Problème : La création d'un enregistrement DNS échoue avec une erreur de validation sur le champ ttl.
    • Pourquoi cela se produit-il : Le TTL est en dehors de la plage autorisée de 60 à 604800 secondes (par exemple un ttl = 30 provenant d'un autre fournisseur).
    • Correction : Limiter le TTL à la plage prise en charge :
    resource "ionoscloud_dns_record" "api" {
  ttl = 300   # valid: 60..604800
}

Résumé

Vous pouvez maintenant créer un réseau segmenté complet pour une application entièrement en code. Les LAN offrent une isolation en plusieurs niveaux, les cartes réseau (NIC) relient les serveurs à un ou plusieurs niveaux avec des adresses statiques ou DHCP, une passerelle NAT permet un accès sortant contrôlé aux hôtes privés, une passerelle IPSec relie les réseaux sur site, et les enregistrements DNS publient le point de terminaison, le tout déclaré dans Terraform et reproductible à la demande. TaskBoard dispose maintenant d'un niveau d'entrée public, d'un niveau d'application privé et d'un niveau de base de données isolé, avec une sortie privée et un nom d'hôte API résolvable.

La pile réseau est le substrat sur lequel repose la REST du Module 2. L'Unité 2.3 ajoute des équilibreurs de charge et des règles de groupe de sécurité réseau sur ces LAN et NIC, et le Module 4 relie le code d'application aux bases de données gérées qui seront hébergées sur le niveau de base de données que vous venez de créer.

Points clés :

  • Une ionoscloud_lan par niveau ; public = true se connecte à la passerelle Internet, public = false isole le niveau
  • Un serveur rejoint plusieurs niveaux en ayant plusieurs ressources ionoscloud_nic, une par LAN
  • Les LAN privés nécessitent une passerelle ionoscloud_natgateway SNAT uniquement pour l'accès sortant, et la route par défaut n'est pas injectée automatiquement
  • L'IPSec VPN utilise IKEv2 avec un PSK et nécessite des sélecteurs de trafic exactement identiques aux deux extrémités
  • Les zones et les enregistrements DNS sont des ressources Terraform avec des TTL limités à 60 à 604800 secondes, servis sur un réseau Anycast

Terminologie importante :

  • LAN : Un domaine de diffusion de couche 2 limité à un VDC, l'unité de segmentation réseau ; provisionné avec ionoscloud_lan.
  • NIC : Une interface réseau reliant un serveur à un LAN ; un serveur avec des NIC sur plusieurs LAN participe à plusieurs niveaux.
  • SNAT (Traduction de source NAT) : La traduction que la passerelle NAT effectue, en réécrivant les adresses source sortantes vers une adresse IP publique tout en bloquant les trafics entrants non sollicités.
  • Sélecteur de trafic : La paire de CIDR cloud et peer sur un tunnel IPSec qui détermine quel trafic est chiffré et acheminé à travers la VPN.
  • Enregistrement Apex : Un enregistrement DNS à la racine de la zone Root, créé dans Cloud DNS en laissant le champ de nom d'enregistrement vide.

Prochaines étapes

Continuer l'apprentissage : Unité 2.3 : Équilibrage de charge et sécurité en tant que code

Sujets connexes :