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 du 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 extrait 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 la 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 du 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), passerelle et 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

Le rôle common peut fixer le link MTU de l'interface principale indépendamment du modèle netplan, via la variable d'inventaire link_mtu. Lorsqu'elle est définie, elle génère un drop-in netplan (/etc/netplan/999-link-mtu.yaml) sur l'interface principale de l'hôte et l'applique. Cela existe parce que les VM proviennent du modèle VMware/Proxmox avec le MTU que le groupe de ports source a expédié (parfois jumbo/9000), ce qui ne correspond pas au reste du tissu et crée des trous noirs pour les SCTP/SIP surdimensionnés lorsque PMTUD est cassé.

Le drop-in est délibérément nommé 999- afin qu'il soit trié en dernier : netplan fusionne tous les /etc/netplan/*.yaml dans l'ordre lexicographique avec le dernier fichier gagnant par clé, et le provisionnement peut laisser des fichiers concurrents qui définissent mtu sur la même interface (un 80-ansible-config.yaml hérité et le 99-netcfg-vmware.yaml du moteur VMware). Un drop-in numéroté plus bas serait silencieusement remplacé par ceux-ci.

all:
  vars:
    link_mtu: 1500   # fixe le NIC principal de chaque hôte à 1500

Définissez-le dans all.vars pour l'appliquer à l'échelle du site, ou par hôte pour remplacer. Si link_mtu n'est pas défini, le rôle laisse le MTU de l'interface intact.

link_mtu n'est PAS mtu. La variable mtu de niveau supérieur est le MTU de la charge utile GTP/tunnel (par exemple, 1400/1430/1300) consommé par les rôles de cœur de paquet, pas un MTU de lien. Définir le NIC physique sur ces valeurs serait incorrect. Utilisez toujours le link_mtu dédié pour le MTU de l'interface.

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 à l'intérieur de l'entrée IP secondaire (nic_config.mask_cidr), pas à partir d'un mask_cidr de niveau supérieur. Si omise, 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 assigné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 fixer 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 se rend comme /28 parce que 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, des NIC secondaires sont automatiquement créés 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 le 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 retour 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 partenaire 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-homé 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 }}

Depuis 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 diameter pour se lier à sa propre IP publique :

# Dans dra_config.yaml.j2 - utilisez inventory_hostname pour l'hôte actuel
peers:
  - name: external_peer
    # Lier à l'IP publique diameter 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 des 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érifier 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 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