Depuis hier on doit dire « Additional IP » (sûrement du au fait qu'il faut maintenant payer mensuellement cette option), mais cela reste une IPFO ou une IP Failover.
Je me bat depuis quelques jours afin de pouvoir utiliser un bloc /30 (4 IPs) dans une VM pfSense.
Pas de problème pour rattacher ces 4 IPs avec leurs adresses MAC respectives.
Le problème vient au moment de la définition des interfaces WAN.
Exemple d'un bloc 36.58.186.128/30 pour un serveur dédié avec IP 52.215.153.127 (passerelle 52.215.153.254)
- WAN_1 : 36.58.186.128/32
- WAN_2 : 36.58.186.129/32
- WAN_3 : 36.58.186.130/32
- WAN_4 : 36.58.186.131/32
Dans les documentations OVH, il est indiqué d'utiliser la même passerelle que celle du serveur dédié auquel sont rattachés les IP FO, pas de soucis dans pfSense il suffit de cocher l'option « Use non-local gateway » puisque la passerelle n'est pas dans le même sous-réseau ... mais là on se demande déjà comment ça peut fonctionner.
Sauf qu'il n'est possible d'assigner la même passerelle à plusieurs interfaces !
Après plusieurs tests, il semble que notre définition de passerelle soit totalement inutile, car en mettant des passerelles bidons du type:
- WAN_1 : 36.58.186.128/32 avec comme passerelle GW_WAN_1 > 1.1.1.11
- WAN_2 : 36.58.186.129/32 avec comme passerelle GW_WAN_2 > 1.1.1.12
- WAN_3 : 36.58.186.130/32 avec comme passerelle GW_WAN_3 > 1.1.1.13
- WAN_4 : 36.58.186.131/32 avec comme passerelle GW_WAN_4 > 1.1.1.14
Et bien ça fonctionne aussi ...
Pour tester cette configuration, je me met derrière chaque VM pour laquelle j'ai créé une règle de pare-feu sur l'interface LAN ou je force l'utilisation d'une passerelle spécifique et j'effectue un traceroute google.fr pour visualiser la passerelle et un curl ident.me pour voir mon IP publique.
Résultats pour les VM qui ont bien accès à Internet:
- Pour la VM_A mappé sur la passerelle GW_WAN_1:
me@vma:~$ curl ident.me
36.58.186.128
me@vma:~$ traceroute google.fr
traceroute to google.fr (142.250.179.67), 30 hops max, 60 byte packets
1 52.215.153.252 (52.215.153.252)
- Pour la VM_B mappé sur la passerelle GW_WAN_2:
me@vmb:~$ curl ident.me
36.58.186.129
me@vmb:~$ traceroute google.fr
traceroute to google.fr (142.250.179.67), 30 hops max, 60 byte packets
1 52.215.153.252 (52.215.153.252)
- Pour la VM_C mappé sur la passerelle GW_WAN_3:
me@vmc:~$ curl ident.me
36.58.186.130
me@vmc:~$ traceroute google.fr
traceroute to google.fr (142.250.179.67), 30 hops max, 60 byte packets
1 52.215.153.252 (52.215.153.252)
- Pour la VM_D mappé sur la passerelle GW_WAN_4:
me@vmd:~$ curl ident.me
36.58.186.131
me@vmd:~$ traceroute google.fr
traceroute to google.fr (142.250.179.67), 30 hops max, 60 byte packets
1 52.215.153.252 (52.215.153.252)
Donc au final, il semble qu'OVH manipule les paquets pour changer dynamiquement la route.
Est-ce que quelqu'un pourrait me confirmer ce comportement ?
