Le contexte: une collision de réseaux. En gros, un réseau d’administration de switchs est passé de 192.168.9.0/24 à 192.168.1.0/24. Or un des vlans est sur un réseau 192.168.1.0/24 et il faudrait avoir une passerelle pouvant atteindre les deux réseaux.
Situation des cartes: eth0 = LAN, eth1 = extérieur, eth2 = vers les switchs.
[code]boisson@stargate:~$ /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:e0:7d:e2:51:ed
inet adr:192.168.1.2 Bcast:192.168.1.255 Masque:255.255.255.0
adr inet6: fe80::2e0:7dff:fee2:51ed/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4952696 errors:0 dropped:59651 overruns:0 frame:0
TX packets:5019856 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:2314579010 (2.1 GiB) TX bytes:3320753642 (3.0 GiB)
Interruption:20 Adresse de base:0xc000
eth1 Link encap:Ethernet HWaddr 00:13:d3:92:3e:c5
inet adr:81.XX.YYY.55 Bcast:81.XX.YYY.255 Masque:255.255.255.0
adr inet6: fe80::213:d3ff:fe92:3ec5/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3636228 errors:0 dropped:0 overruns:0 frame:0
TX packets:3382063 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:30
RX bytes:2109176466 (1.9 GiB) TX bytes:1089462778 (1.0 GiB)
Interruption:17
eth2 Link encap:Ethernet HWaddr 00:00:e8:76:37:8b
inet adr:192.168.1.4 Bcast:192.168.1.255 Masque:255.255.255.0
adr inet6: fe80::200:e8ff:fe76:378b/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:80 errors:0 dropped:8 overruns:0 frame:0
TX packets:303 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:6598 (6.4 KiB) TX bytes:18813 (18.3 KiB)
Interruption:22 Adresse de base:0xe000
lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:491 errors:0 dropped:0 overruns:0 frame:0
TX packets:491 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:44880 (43.8 KiB) TX bytes:44880 (43.8 KiB)
boisson@stargate:~$
[/code]
Cela ne pose aucun problème lorsque switch à atteindre à une adresse qui n’est pas attribuée sur l’autre réseau, une table de routage simple règle le problème:
Destination Passerelle Genmask Indic Metric Ref Use Iface
0.0.0.0 81.XX.YYY.254 0.0.0.0 UG 0 0 0 eth1
81.XX.YYY.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.1.70 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
root@stargate:~#
root@stargate:~# ping 192.168.1.70
PING 192.168.1.70 (192.168.1.70) 56(84) bytes of data.
64 bytes from 192.168.1.70: icmp_req=1 ttl=255 time=276 ms
64 bytes from 192.168.1.70: icmp_req=2 ttl=255 time=0.854 ms
64 bytes from 192.168.1.70: icmp_req=3 ttl=255 time=0.821 ms
le souci est qu’il y a des collisions ne serait ce que par l’existence de 192.168.1.1 sqerveur principal et aussi switch principal.
Mon idée serait la suivante:
- Un paquet entrant sur eth0 (192.168.1.2) destiné à 192.168.9.70 (par exemple) est marquée par la règle
- Changer ensuite l’adresse de destination
(je n’arrive pas à trouver une règle effectuant un changement de réseau, pas sur que ça soit faisable)
- Fabrication d’une table de routage ad hoc
et la table elle même
et enfin du SNAT sur eth2 pour forcer le retour à passer par la passerelle (la requête viendra d’une machine sur 192.168.1.0/24)
Un telnet 192.168.9.70 sur une machine sur 192.168.1.0/24 montre plusieurs choses:
La règle de marquage du paquet à 9 est utilisée (chouette)
La règle de DNAT changeant 192.168.9.70 en 192.168.1.70 aussi (rechouette)
La règle de NAT sur eth2 n’est pas utilisé (ce qui explique que rien ne sort sur eth2).
Donc le problème est là.
root@stargate:~# ip route show table adhoc
192.168.1.0/24 dev eth2 scope link
root@stargate:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP mode DEFAULT qlen 30
link/ether 00:13:d3:92:3e:c5 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 1000
link/ether 00:e0:7d:e2:51:ed brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether 00:00:e8:76:37:8b brd ff:ff:ff:ff:ff:ff
root@stargate:~# ip rule show
0: from all lookup local
32765: from all fwmark 0x9 lookup adhoc
32766: from all lookup main
32767: from all lookup default
root@stargate:~# ip route show table adhoc
192.168.1.0/24 dev eth2 scope link
root@stargate:~# ip route show
default via 81.XX.YYY.254 dev eth1
81.XX.YYY.0/24 dev eth1 proto kernel scope link src 81.XX.YYY.55
192.168.0.0/24 dev eth0 scope link
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2
1192.168.2.0/24 dev eth0 scope link
root@stargate:~#
En fait je ne sais pas où part le paquet, car en toute logique, si il ne suit pas la table de routage adhoc, il devrait repartir sur eth0 mais tcpdump ne montre rien. Le paquet disparait dans un trou noir semble-t-il.
Si quelqu’u (Pascal?) a une idée…
PS: Je sais que le plus simple serait de modifier l’un des réseaux mais j’ai bêtement mis l’adresse IP au lieu du nom du serveur dans le montage NFS dans /etc/fstab
RePS: En plus je pense que ça devrait marcher.