IP Failover et Gateway inutile ?
... / IP Failover et Gateway in...
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
question

IP Failover et Gateway inutile ?

Par
Yann
Créé le 2022-10-07 12:37:46 (edited on 2024-09-04 11:27:30) dans Serveurs dédiés

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 ?


3 réponses ( Latest reply on 2024-02-15 08:31:14 Par
JeremyL32
)

Hello, Interessant...
Par curiosité, tu as créé quoi comme règle (je cite : " j'ai créé une règle de pare-feu sur l'interface LAN ou je force l'utilisation d'une passerelle") ? Il s'agit d'une règle de NAT Outbound ?

Non c'est simplement dans les paramètres avancés d'une règle, on peut forcer la passerelle

Yes je viens de tester avec 2 IPFO et ça fonctionne effectivement..
Merci pour le tips !