Demande #28773
eole 2.7.x ne supporte pas les vlans sous leur forme actuelle
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
Demandes liées
Historique
#1 Mis à jour par Thierry Bertrand il y a plus de 4 ans
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 Mis à jour par Daniel Dehennin il y a plus de 4 ans
- Description mis à jour (diff)
#3 Mis à jour par Joël Cuissinat il y a plus de 4 ans
<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 Mis à jour par Joël Cuissinat il y a plus de 4 ans
- Lié à Tâche #12449: ERA : Erreur sur la syntaxe à employer pour les alias. ajouté
#5 Mis à jour par Thierry Bertrand il y a environ 4 ans
- Statut changé de Nouveau à Classée sans suite