Demande #28773
Mis à jour par Daniel Dehennin il y a presque 5 ans
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]@* %%nom_zone_eth1.%%vlan_id_eth1[0]
* ip variable : *@%%vlan_id_eth1[0].vlan_ip_eth1@* %%vlan_id_eth1[0].vlan_ip_eth1
* netmask variable : *@%%vlan_id_eth1[0].vlan_netmask_eth1@* %%vlan_id_eth1[0].vlan_netmask_eth1
* network variable : *@%%vlan_id_eth1[0].vlan_network_eth1@*
%%vlan_id_eth1[0].vlan_network_eth1
Toutes ces syntaxes sont utilisées en 2.6.x et fonctionnnet fonctionnenet correctement
Après instanciation, le bastion est incapable de pinger une machine du vlan 2
Un *@ouvre.firewall@* ouvre.firewall est fonctionnel.
passage en mode diagnostique :
<pre>
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
</pre>
On constate que la syntaxe retournée diffère d'un 2.6 qui lui, retourne sous la forme *@enp6s0f0.210@enp6s0f0@* enp6s0f0.210@enp6s0f0
Au niveau d'iptables, une règle semble être correcte au niveau syntaxique :
<pre>
0 0 ACCEPT all -- enp16s0 enp16s0.2 0.0.0.0/0 0.0.0.0/0
</pre>
On passe en debug avancé :
<pre>
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
</pre>
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]@* %%nom_zone_eth1.%%vlan_id_eth1[0] => *@vlan%%vlan_id_eth1[0]@%%nom_zone_eth1@* vlan%%vlan_id_eth1[0]@%%nom_zone_eth1
pour coller à ce que retourne *@ip addr@* ip a
Après un *@bastion regen@*, bastion regen, pas mieux : l'outil mieux
L'outil ping ne fonctionne pas mais tcpdump voit les request et reply. reply
On remodifie le modèle de façon à respecter la syntaxe 2.6.2 :
<pre> 2.6.2 :
%%nom_zone_eth1.%%vlan_id_eth1[0]@%%nom_zone_eth1
</pre>
Le *@bastion regen@* bastion regen explose avec le message suivant :
<pre>
iptables-restore v1.6.1: interface name `enp16s0.2@enp16s0' must be shorter than IFNAMSIZ (15)
</pre>
On revient à la syntaxe d'origine et on change la façon de faire :
faire :
analyse sur l'interface physique
<pre>
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
</pre>
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@* ip a :
<pre>
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)
</pre>
Curieux !
<pre>
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)
</pre>
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,
<pre>
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
</pre>
Tiens, tiens, un nom différent pour l'interface !
Du coup,
<pre>
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
</pre>
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]@* 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]@* vlan%%vlan_id_zone[X]
* la commande *@ip a@* ip a est trompeuse sous cette forme
* merci ifconfig et tcpdump
La commande *@ip@* ip utilisée en mode complétion nous montre, elle ,l'existence de l'interface vlan2 :
<pre>
root@amon-vlan:~# ip address show
dadfailed deprecated dev dynamic enp0s25 enp16s0 label lo permanent primary scope secondary temporary tentative to up vlan2
</pre>
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]@* %%nom_zone_eth1.%%vlan_id_eth1[0]
* ip variable : *@%%vlan_id_eth1[0].vlan_ip_eth1@* %%vlan_id_eth1[0].vlan_ip_eth1
* netmask variable : *@%%vlan_id_eth1[0].vlan_netmask_eth1@* %%vlan_id_eth1[0].vlan_netmask_eth1
* network variable : *@%%vlan_id_eth1[0].vlan_network_eth1@*
%%vlan_id_eth1[0].vlan_network_eth1
Toutes ces syntaxes sont utilisées en 2.6.x et fonctionnnet fonctionnenet correctement
Après instanciation, le bastion est incapable de pinger une machine du vlan 2
Un *@ouvre.firewall@* ouvre.firewall est fonctionnel.
passage en mode diagnostique :
<pre>
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
</pre>
On constate que la syntaxe retournée diffère d'un 2.6 qui lui, retourne sous la forme *@enp6s0f0.210@enp6s0f0@* enp6s0f0.210@enp6s0f0
Au niveau d'iptables, une règle semble être correcte au niveau syntaxique :
<pre>
0 0 ACCEPT all -- enp16s0 enp16s0.2 0.0.0.0/0 0.0.0.0/0
</pre>
On passe en debug avancé :
<pre>
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
</pre>
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]@* %%nom_zone_eth1.%%vlan_id_eth1[0] => *@vlan%%vlan_id_eth1[0]@%%nom_zone_eth1@* vlan%%vlan_id_eth1[0]@%%nom_zone_eth1
pour coller à ce que retourne *@ip addr@* ip a
Après un *@bastion regen@*, bastion regen, pas mieux : l'outil mieux
L'outil ping ne fonctionne pas mais tcpdump voit les request et reply. reply
On remodifie le modèle de façon à respecter la syntaxe 2.6.2 :
<pre> 2.6.2 :
%%nom_zone_eth1.%%vlan_id_eth1[0]@%%nom_zone_eth1
</pre>
Le *@bastion regen@* bastion regen explose avec le message suivant :
<pre>
iptables-restore v1.6.1: interface name `enp16s0.2@enp16s0' must be shorter than IFNAMSIZ (15)
</pre>
On revient à la syntaxe d'origine et on change la façon de faire :
faire :
analyse sur l'interface physique
<pre>
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
</pre>
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@* ip a :
<pre>
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)
</pre>
Curieux !
<pre>
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)
</pre>
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,
<pre>
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
</pre>
Tiens, tiens, un nom différent pour l'interface !
Du coup,
<pre>
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
</pre>
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]@* 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]@* vlan%%vlan_id_zone[X]
* la commande *@ip a@* ip a est trompeuse sous cette forme
* merci ifconfig et tcpdump
La commande *@ip@* ip utilisée en mode complétion nous montre, elle ,l'existence de l'interface vlan2 :
<pre>
root@amon-vlan:~# ip address show
dadfailed deprecated dev dynamic enp0s25 enp16s0 label lo permanent primary scope secondary temporary tentative to up vlan2
</pre>