Aller au contenu principal

Configuration de Netplan

Vue d'ensemble​

OmniCore peut configurer automatiquement les interfaces réseau sur les VM déployées en utilisant netplan. Cela est utile pour :

  • Configurer l'interface de gestion principale (eth0)
  • Ajouter des interfaces secondaires pour des IP publiques, des connexions de peering ou un trafic dédié
  • Configurer des routes statiques pour des destinations spécifiques

Activation de la configuration Netplan​

Pour activer la configuration automatique de netplan pour un hôte, ajoutez la variable netplan_config pointant vers un modèle Jinja2 dans votre dossier group_vars :

dra:
  hosts:
    <hostname>:
      ansible_host: 10.0.1.100
      gateway: 10.0.1.1
      netplan_config: netplan.yaml.j2

Le modèle sera récupéré à partir de hosts/<customer>/group_vars/netplan.yaml.j2.

Référence de modèle​

Il n'existe pas de netplan.yaml.j2 partagé et canonique. Chaque client crée son propre netplan.yaml.j2 dans hosts/<customer>/group_vars/, et ces modèles divergent - le nom de l'interface principale, le domaine de recherche DNS et la nomination des interfaces secondaires varient selon le client. Lors de l'intégration d'un nouveau client, créez un modèle par client qui correspond à la disposition des interfaces de ce client plutôt que de copier textuellement celui d'un autre client.

Ce qui suit est le modèle d'un client comme exemple. Il est illustratif, pas une spécification - d'autres clients diffèrent. Des commentaires sont ajoutés ici pour explication :

network:
  version: 2
  ethernets:
    # Interface principale - utilise ansible_host et gateway de l'inventaire
    eth0:
      addresses:
      - "{{ ansible_host }}/{{ mask_cidr | default(24) }}"
      nameservers:
        addresses:
{% if 'dns' in group_names %}
        # Si cet hôte EST un serveur DNS, utilisez un DNS externe pour éviter une dépendance circulaire
        - 8.8.8.8
{% else %}
        # Sinon, utilisez les serveurs DNS du groupe 'dns' dans l'inventaire
{% for dns_host in groups['dns'] | default([]) %}
        - {{ hostvars[dns_host]['ansible_host'] }}
{% endfor %}
{% endif %}
        # Domaine de recherche DNS - spécifique au client (varie par client ; certains n'en définissent pas)
        search:
        - customer.example
      routes:
      - to: "default"
        via: "{{ gateway }}"

{% if secondary_ips is defined %}
    # Interfaces secondaires - boucle à travers le dictionnaire secondary_ips de l'inventaire
    # Cet exemple les nomme ens19, ens20, ens21... (18 + loop.index). C'est
    # spécifique au modèle ; voir "Nommer les interfaces" ci-dessous.
{% for nic_name, nic_config in secondary_ips.items() %}
    ens{{ 18 + loop.index }}:
      addresses:
      # Le masque provient du mask_cidr par NIC (par défaut à 24)
      - "{{ nic_config.ip_address }}/{{ nic_config.mask_cidr | default(24) }}"
{% if nic_config.routes is defined %}
      # Routes statiques pour cette interface - chaque route utilise la passerelle de cette interface
      routes:
{% for route in nic_config.routes %}
      - to: "{{ route }}"
        via: "{{ nic_config.gateway }}"
{% endfor %}
{% endif %}
{% endfor %}
{% endif %}

Points clés :

  • ansible_host et gateway proviennent de l'entrée d'inventaire de l'hôte
  • Les serveurs DNS sont récupérés dynamiquement à partir des hôtes dans le groupe dns
  • Le domaine de recherche DNS est spécifique au client (varie ; certains clients l'omettent)
  • La nomination des interfaces secondaires varie selon le client (certains utilisent ens19, ens20, ... ; voir ci-dessous)
  • Chaque IP secondaire peut avoir son propre masque (mask_cidr), sa passerelle et ses routes statiques

Configuration de l'interface principale​

L'interface principale (eth0) est configurée automatiquement en utilisant :

  • ansible_host - L'adresse IP
  • gateway - La passerelle par défaut
  • mask_cidr - Masque réseau (par défaut à 24)

Les serveurs DNS sont automatiquement définis sur :

  • Hôtes dans le groupe dns (utilise leurs IP ansible_host)
  • Revertit à 8.8.8.8 si l'hôte est lui-même un serveur DNS

Interfaces secondaires​

Pour les hôtes nécessitant des interfaces réseau supplémentaires (IP publiques, peering, etc.), utilisez la configuration secondary_ips.

Schéma​

secondary_ips:
  <logical_name>:
    ip_address: <ip_address>
    mask_cidr: <prefix_length>   # Optionnel - masque par NIC, par défaut à 24
    gateway: <gateway_ip>
    host_vm_network: <proxmox_bridge>
    vlanid: <vlan_id>
    nic_name: <interface_name>   # Optionnel - remplacement explicite du nom de l'interface
                                 # (pris en charge par les modèles qui le respectent)
    routes:                      # Optionnel - routes statiques via cette interface
      - '<destination_cidr>'
      - '<destination_cidr>'
    table_routes:                # Optionnel - avancé, spécifique au modèle
      - { to: '<cidr>', via: '<gateway>', table: <table_id> }
    routing_policy:              # Optionnel - avancé, spécifique au modèle
      from: '<source_cidr>'
      via: '<gateway>'
      table: <table_id>
      priority: <priority>       # Optionnel, par défaut à 100

La clé mask_cidr définit la longueur de préfixe pour cette interface secondaire. Elle est lue à partir de l'entrée IP secondaire (nic_config.mask_cidr), et non à partir d'un mask_cidr de niveau supérieur. Si omis, elle par défaut à /24.

table_routes et routing_policy permettent le routage par politique/source mais ne sont rendus que par des modèles qui les implémentent. Le routage avancé est spécifique au modèle — confirmez que le netplan.yaml.j2 du client respecte ces clés avant de les utiliser.

Nommer les interfaces​

La nomination des interfaces secondaires est spécifique au modèle - elle n'est pas standardisée entre les clients :

  • Certains clients nomment les interfaces par index : ens19, ens20, ens21, ... (18 + loop.index). Cela correspond aux noms d'interface attribués par Proxmox lors de l'ajout de NIC supplémentaires à une VM.
  • D'autres clients utilisent un nic_config.nic_name explicite lorsqu'il est défini, revenant à un nom basé sur l'index (par exemple ens(34 + loop.index)) sinon.

Si un modèle respecte nic_name, vous pouvez attribuer une interface secondaire à un nom spécifique en définissant nic_name sur cette entrée IP secondaire ; sinon, le schéma basé sur l'index du modèle s'applique.

Exemple de configuration​

dra:
  hosts:
    <hostname>:
      ansible_host: 10.0.1.100
      gateway: 10.0.1.1
      host_vm_network: "ovsbr1"
      vlanid: "100"
      netplan_config: netplan.yaml.j2
      secondary_ips:
        public_ip:
          ip_address: 192.0.2.50
          mask_cidr: 28
          gateway: 192.0.2.1
          host_vm_network: "vmbr0"
          vlanid: "200"
          routes:
            - '198.51.100.0/24'
            - '203.0.113.0/24'
        peering_ip:
          ip_address: 172.16.50.10
          gateway: 172.16.50.1
          host_vm_network: "ovsbr2"
          vlanid: "300"
          routes:
            - '172.17.0.0/16'

Sortie Netplan générée​

Rendu avec le modèle d'exemple, la configuration ci-dessus génère (le domaine de recherche DNS et la nomination ens19/ens20 sont spécifiques au client) :

network:
  version: 2
  ethernets:
    eth0:
      addresses:
      - "10.0.1.100/24"
      nameservers:
        addresses:
        - 10.0.1.53
        search:
        - customer.example
      routes:
      - to: "default"
        via: "10.0.1.1"
    ens19:
      addresses:
      - "192.0.2.50/28"
      routes:
      - to: "198.51.100.0/24"
        via: "192.0.2.1"
      - to: "203.0.113.0/24"
        via: "192.0.2.1"
    ens20:
      addresses:
      - "172.16.50.10/24"
      routes:
      - to: "172.17.0.0/16"
        via: "172.16.50.1"

L'interface public_ip est rendue comme /28 car son entrée a défini mask_cidr: 28, tandis que peering_ip revient à la valeur par défaut de /24.

Intégration Proxmox​

Lors de l'utilisation du playbook proxmox.yml, les NIC secondaires sont créées automatiquement sur la VM :

  1. Nouvelles VM : Les NIC secondaires sont ajoutées lors du provisionnement initial
  2. VM existantes : Les NIC secondaires sont ajoutées et la VM est redémarrée pour appliquer les changements

La configuration Proxmox utilise :

  • host_vm_network - Le pont auquel attacher la NIC
  • vlanid - Tag VLAN pour l'interface

Comment ça fonctionne​

  1. Les configurations netplan existantes dans /etc/netplan sont sauvegardées (*.bak) puis supprimées pour éviter les conflits
  2. Le modèle Jinja2 du client est rendu dans /etc/netplan/01-netcfg.yaml (mode 0600)
  3. netplan try --timeout 30 applique la configuration avec un rollback automatique si la connectivité est perdue
  4. wait_for_connection confirme que l'hôte est resté accessible
  5. netplan apply valide la configuration

Cas d'utilisation courants​

Diameter Edge Agent (DEA) avec IP publique​

<hostname>:
  ansible_host: 10.0.1.100           # IP de gestion interne
  gateway: 10.0.1.1
  netplan_config: netplan.yaml.j2
  secondary_ips:
    diameter_roaming:
      ip_address: 192.0.2.50         # IP publique pour les partenaires de roaming
      gateway: 192.0.2.1
      host_vm_network: "vmbr0"
      vlanid: "200"
      routes:
        - '198.51.100.0/24'          # Réseau des partenaires de roaming

PGW avec interface S5/S8​

<hostname>:
  ansible_host: 10.0.2.20            # IP interne
  gateway: 10.0.2.1
  netplan_config: netplan.yaml.j2
  secondary_ips:
    s5s8_interface:
      ip_address: 203.0.113.17       # IP publique S5/S8
      gateway: 203.0.113.1
      host_vm_network: "vmbr0"
      vlanid: "50"

Serveur multi-homed avec réseaux de gestion et de données séparés​

<hostname>:
  ansible_host: 10.0.1.100           # Réseau de gestion
  gateway: 10.0.1.1
  netplan_config: netplan.yaml.j2
  secondary_ips:
    data_network:
      ip_address: 10.0.2.100         # Réseau de données
      gateway: 10.0.2.1
      host_vm_network: "ovsbr2"
      vlanid: "200"
    backup_network:
      ip_address: 10.0.3.100         # Réseau de sauvegarde
      gateway: 10.0.3.1
      host_vm_network: "ovsbr3"
      vlanid: "300"

Référencer les IP secondaires dans les modèles​

Vous pouvez référencer les adresses IP secondaires dans d'autres modèles Jinja2 et fichiers de configuration.

Sur le même hôte​

Lors de la configuration d'un service sur le même hôte qui a des IP secondaires, vous pouvez référencer directement ou utiliser inventory_hostname :

# Référence directe (la plus simple)
{{ secondary_ips.diameter_public_ip.ip_address }}

# Ou explicitement via inventory_hostname (même résultat)
{{ hostvars[inventory_hostname]['secondary_ips']['diameter_public_ip']['ip_address'] }}

# Accéder à d'autres propriétés
{{ secondary_ips.diameter_public_ip.gateway }}
{{ secondary_ips.diameter_public_ip.vlanid }}

D'un autre hôte​

Lorsque vous devez référencer une IP secondaire d'un autre hôte (par exemple, configurer une connexion de pair), utilisez hostvars avec le nom d'hôte cible :

# Référence le premier hôte dans le groupe dra
{{ hostvars[groups['dra'][0]]['secondary_ips']['diameter_public_ip']['ip_address'] }}

# Boucle à travers tous les hôtes DRA et obtenez leurs IP publiques
{% for host in groups['dra'] %}
{% if hostvars[host]['secondary_ips'] is defined %}
  - {{ hostvars[host]['secondary_ips']['diameter_public_ip']['ip_address'] }}
{% endif %}
{% endfor %}

Exemple : Configuration de pair DRA​

Configurer un pair de diamètre pour se lier à sa propre IP publique :

# Dans dra_config.yaml.j2 - utilisez inventory_hostname pour l'hôte actuel
peers:
  - name: external_peer
    # Se lier à l'IP publique de diamètre de cet hôte
    local_ip: {{ hostvars[inventory_hostname]['secondary_ips']['diameter_public_ip']['ip_address'] }}
    remote_ip: 198.51.100.50
    port: 3868

Vérifier si les IP secondaires existent​

Vérifiez toujours si la variable existe avant de l'utiliser :

{% if secondary_ips is defined and secondary_ips.diameter_public_ip is defined %}
public_ip: {{ secondary_ips.diameter_public_ip.ip_address }}
{% else %}
public_ip: {{ ansible_host }}
{% endif %}

Dépannage​

Vérifier les noms d'interface​

SSH sur la VM et vérifiez les noms d'interface :

ip link show

Sortie attendue pour une VM avec deux interfaces secondaires :

1: lo: <LOOPBACK,UP,LOWER_UP> ...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
4: ens20: <BROADCAST,MULTICAST,UP,LOWER_UP> ...

Vérifier la configuration de Netplan​

cat /etc/netplan/01-netcfg.yaml

Appliquer Netplan manuellement​

netplan apply

Déboguer Netplan​

netplan --debug apply

Vérifier les routes​

ip route show

Documentation connexe​

Dernière mise à jour le