Project

General

Profile

Demande #28773

eole 2.7.x ne supporte pas les vlans sous leur forme actuelle

Added by Thierry Bertrand 8 months ago. Updated 16 days ago.

Status:
Classée sans suite
Priority:
Normal
Assigned To:
-
Category:
-
Target version:
-
Start date:
07/18/2019
Due date:
% Done:

0%


Description

on a installé un amon 2.7.0 avec 2 interfaces ethernet et une interface vlan supplémentaire (id de vlan: 2).

Il utilise le modèle 2zones de base.

Puis on ajoute une zone supplémentaire avec les paramètres suivants :

  • interface : %%nom_zone_eth1.%%vlan_id_eth1[0]
  • ip variable : %%vlan_id_eth1[0].vlan_ip_eth1
  • netmask variable : %%vlan_id_eth1[0].vlan_netmask_eth1
  • network variable : %%vlan_id_eth1[0].vlan_network_eth1

Toutes ces syntaxes sont utilisées en 2.6.x et fonctionnnet correctement

Après instanciation, le bastion est incapable de pinger une machine du vlan 2
Un ouvre.firewall est fonctionnel.

passage en mode diagnostique :

root@amon-vlan:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp16s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:03:47:ae:42:4a brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.1/24 brd 10.1.1.255 scope global enp16s0
       valid_lft forever preferred_lft forever
3: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 78:e7:d1:85:cc:4a brd ff:ff:ff:ff:ff:ff
    inet a.b.c.d/23 brd 172.26.63.255 scope global enp0s25
       valid_lft forever preferred_lft forever
4: vlan2@enp16s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:03:47:ae:42:4a brd ff:ff:ff:ff:ff:ff
    inet 10.2.1.1/24 brd 10.2.1.255 scope global vlan2
       valid_lft forever preferred_lft forever

On constate que la syntaxe retournée diffère d'un 2.6 qui lui, retourne sous la forme enp6s0f0.210@enp6s0f0

Au niveau d'iptables, une règle semble être correcte au niveau syntaxique :

    0     0 ACCEPT     all  --  enp16s0 enp16s0.2  0.0.0.0/0            0.0.0.0/0

On passe en debug avancé :

root@amon-vlan:~# tcpdump -n -e -i any host 10.2.1.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:53:00.105323 Out 00:03:47:ae:42:4a ethertype IPv4 (0x0800), length 100: 10.2.1.1 > 10.2.1.2: ICMP echo request, id 8872, seq 21, length 64
16:53:00.105576  In 2c:44:fd:69:07:bb ethertype 802.1Q (0x8100), length 104: vlan 2, p 0, ethertype IPv4, 10.2.1.2 > 10.2.1.1: ICMP echo reply, id 8872, seq 21, length 64
16:53:00.105576  In 2c:44:fd:69:07:bb ethertype IPv4 (0x0800), length 100: 10.2.1.2 > 10.2.1.1: ICMP echo reply, id 8872, seq 21, length 64

tcpdump nous indique que le ping se fait bien au niveau des messages icmp mais l'outil ping reste muet

On se dit que, on doit ne pas être cohérent dans le modèle de zone et on apporte la modification suivante :
interface : %%nom_zone_eth1.%%vlan_id_eth1[0] => vlan%%vlan_id_eth1[0]%%nom_zone_eth1@
pour coller à ce que retourne ip addr

Après un bastion regen, pas mieux : l'outil ping ne fonctionne pas mais tcpdump voit les request et reply.

On remodifie le modèle de façon à respecter la syntaxe 2.6.2 :

%%nom_zone_eth1.%%vlan_id_eth1[0]@%%nom_zone_eth1

Le bastion regen explose avec le message suivant :

 iptables-restore v1.6.1: interface name `enp16s0.2@enp16s0' must be shorter than IFNAMSIZ (15)

On revient à la syntaxe d'origine et on change la façon de faire :

analyse sur l'interface physique

root@amon-vlan:~# tcpdump -n -e -i enp16s0 host 10.2.1.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp16s0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:02:20.233786 2c:44:fd:69:07:bb > 00:03:47:ae:42:4a, ethertype 802.1Q (0x8100), length 102: vlan 2, p 0, ethertype IPv4, 10.2.1.2 > 10.2.1.1: ICMP echo reply, id 8872, seq 568, length 64
17:02:21.257836 2c:44:fd:69:07:bb > 00:03:47:ae:42:4a, ethertype 802.1Q (0x8100), length 102: vlan 2, p 0, ethertype IPv4, 10.2.1.2 > 10.2.1.1: ICMP echo reply, id 8872, seq 569, length 64

on constate que les réponses ne se font pas sur le vlan 2 ! Ceci explique que l'outil ping ne fonctionne pas.

on essaye alors d'écouter sur l'interface vlan tel que nous la présente ip addr :

root@amon-vlan:~# tcpdump -n -e -i vlan2@enp16s0 host 10.2.1.2
tcpdump: vlan2@enp16s0: No such device exists
(SIOCGIFHWADDR: No such device)

Curieux !

root@amon-vlan:~# tcpdump -n -e -i enp16s0.2@enp16s0 host 10.2.1.2
tcpdump: enp16s0.2@enp16s0: No such device exists
(SIOCGIFHWADDR: No such device)

Pas moyen de saisir le nom de l'interface que ce soit à la "mode" 2.6 ou 2.7...

Par dépit et à tout hazard,

root@amon-vlan:~# ifconfig
enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.26.63.68  netmask 255.255.254.0  broadcast 172.26.63.255
        ether 78:e7:d1:85:cc:4a  txqueuelen 1000  (Ethernet)
        RX packets 21942  bytes 2307167 (2.3 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 13137  bytes 3751897 (3.7 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 19  memory 0xf0500000-f0520000  

enp16s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.1.1.1  netmask 255.255.255.0  broadcast 10.1.1.255
        ether 00:03:47:ae:42:4a  txqueuelen 1000  (Ethernet)
        RX packets 2117  bytes 264510 (264.5 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1895  bytes 188138 (188.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Boucle locale)
        RX packets 26948  bytes 18488262 (18.4 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 26948  bytes 18488262 (18.4 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vlan2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.2.1.1  netmask 255.255.255.0  broadcast 10.2.1.255
        ether 00:03:47:ae:42:4a  txqueuelen 1000  (Ethernet)
        RX packets 1989  bytes 185956 (185.9 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1895  bytes 180558 (180.5 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Tiens, tiens, un nom différent pour l'interface !

Du coup,

root@amon-vlan:~# tcpdump -n -e -i vlan2 host 10.2.1.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan2, link-type EN10MB (Ethernet), capture size 262144 bytes
17:09:42.601378 00:03:47:ae:42:4a > 2c:44:fd:69:07:bb, ethertype IPv4 (0x0800), length 98: 10.2.1.1 > 10.2.1.2: ICMP echo request, id 8872, seq 1000, length 64
17:09:42.601849 2c:44:fd:69:07:bb > 00:03:47:ae:42:4a, ethertype IPv4 (0x0800), length 98: 10.2.1.2 > 10.2.1.1: ICMP echo reply, id 8872, seq 1000, length 64

Bingo, le nommage des vlans diffère.
Mais l'outil ping ne fonctionne toujours pas ... malgré le request et reply dans le vlan !

Remodification du modèle de façon à satisfaire à cette syntaxe :
interface : vlan%%vlan_id_eth1[0]
Le bastion regen qui s'ensuit fait tout tomber en marche.

Moralité :

  • le nommage des zones diffère en 2.7. Il doit être de la forme vlan%%vlan_id_zone[X]
  • la commande ip a est trompeuse sous cette forme
  • merci ifconfig et tcpdump

La commande ip utilisée en mode complétion nous montre, elle ,l'existence de l'interface vlan2 :

root@amon-vlan:~# ip address show 
dadfailed   deprecated  dev         dynamic     enp0s25     enp16s0     label       lo          permanent   primary     scope       secondary   temporary   tentative   to          up          vlan2       

Related issues

Related to Documentations - Tâche #12449: ERA : Erreur sur la syntaxe à employer pour les alias. Fermé 07/22/2015

History

#1 Updated by Thierry Bertrand 8 months ago

A noter que le passage en 2.7.1 n'a pas résolu le problème.

Bug d'affichage :

[0]

affiche un exposant 0 bleu dans le texte s'il n'est pas protégé.
Pas su le modifier ...

#2 Updated by Daniel Dehennin 8 months ago

  • Description updated (diff)

#3 Updated by Joël Cuissinat 3 months ago

<teebee44> nous on a changé nos modèles en fonction
<teebee44> si tu veux faire à minima, c'est la doc qu'il faut changer

#4 Updated by Joël Cuissinat 3 months ago

  • Related to Tâche #12449: ERA : Erreur sur la syntaxe à employer pour les alias. added

#5 Updated by Thierry Bertrand 16 days ago

  • Status changed from Nouveau to Classée sans suite

Also available in: Atom PDF